Introduction

This repository contains the current onboarded key material in DEV environment for the Smart Trust Network. To be part of it, follow the instructions below.

Procedure

To be part of the Smart Trust Network, copy/fork at first the template repository and send an onboarding/participation request to tng-support@who.int After verification of your request your repository will be linked with this one and your onboarding information is replicated to the environment.

For creating new certificates for test/uat, follow the helper guidelines here.

More information about DID usage can be found here.

A checklist is prepared here.

QA Checks

Due to quality reasons the incoming content will be checked for certain quality critiera. This ensures that all certificates are following the rules defined in the Smart Trust Certificate Governance document

The incoming content needs to be checked for the following rules:

Common Checks

Checks Description Further info Reference
Valid Folder Structure - Reference
Certificates Unique Certificates must be present only in one of the onboarding repositories/environments. This ensures that the same keypair cannot be onboarded (1) to DEV, UAT and PROD environments, (2) by multiple parties and (3) multiple times n the same environment by the same party

Country specific checks

Checks Description Further info Reference
Country attribute The country flag (C value) must be set to the correct country code Must match folder name after bot pull
Oversea Territory OU Some overseas territories require special values in their OU attribute

Certificate Checks

Checks Description Further info Reference
Correct PEM The certificates will be checked for a correct pem structure Reference
TLS.pem without CA The TLS.pem must be without CA Chain Reference
Chain Check TLS.pem + CA.pem must resolve and verify Reference
Validity Certs must be valid for at least 30 days from today Reference
Validity Range Rules according to certificate Governance Certificate Covernance Reference
Key Usages Rules according to certificate Governance Certificate Covernance Reference
Extended Key Usages Rules according to certificate Governance Certificate Covernance Reference
Basic constraints Rules according to certificate Governance Certificate Covernance Reference
Subject Country attribute must be set in subject Reference

Cryptographic Checks

Checks Description Further info Reference
Key Length The key length should be at minimum 3072 for RSA-PSS, and 256 bit for EC-DSA
Algorithm RSASSA-PSS, ECDSA_P256 or DSA (legacy RSA)
Explicit Parameter Only allowed in ICAO
Debian Weak Keys Key must not match Debian Weak Keys Shall ensure that nobody uses the old Open SSL Lib from Debian

DID Checks

Checks Description Further info Reference
DID Resolvable DID must be resolvable via the Universal Verifier
DID Web Domain Linkage The DID Web domain must contain a DID Configuration
JWK Key Keys must be in JWK format. Public Key Base is not allowed
Verification Method Present At least one Verification Method must be present
Key Unique Check Verification Methods shall not contain the same Public Key
No Private JWK JWK shall not contain private Information

JWKS Checks

Checks Description Further info Reference
JWKS Resolvable JWKS is resolvable
JWKS URI Secure JWKS URI must have a validated Domain
Valid JWKS Format JWKS format must be valid
Key Unique Check Verification Methods shall not contain the same Public Key
No Private JWK JWK shall not contain private Information

Transitive Trust Failure Checks

QA-Rules Explained

Common Checks

Folder structure

  • Under the onboarding folder, there must be exactly one folder for each domain that is to be onboarded
    • See above for list of valid domains
  • Every domain MUST have
    • One TLS folder with at least one TLS.pem (optionally TLS_1.pem, TLS_2.pem, ...) and at least one CA.pem (optionally CA_1.pem, ...)
    • One UP folder with at least one UP.pem (optionally UP_1.pem, UP_2.pem, ...)
  • Every domain MAY have
    • One SCA folder with at least one SCA.pem (optionally SCA_1.pem, ...)
    • One ISSUER folder with one or more DID.txt and/or JWKS.txt (DID_1.txt,..., JWKS_1.txt)

Certificate Checks

Most of the checks following the Certificate Covernance which defines the key length and key usage critiera. Additionally there will be more checks in future refering to ICAO, DIVOC, DDCC and other domains.

Correct PEM

The .pem file MUST contain a valid X509 structure in PEM encoding according to RFC 7468. This includes an proper BEGIN and END header.

TLS.pem without CA

The TLS certificate is checked for the non existence of intermediate and root certificates, because this one are considered for the CA.pemfiles.

Chain Check

The combination of TLS.pem + CA.pem is checked for a valid chain to ensure the cryptographic correctness.

Validity

Validity Range

Key Usages

Extended Key Usages

Basic constraints

Subject

Cryptographic Checks

Transitive Trust Failure Checks

The review process checks for any failure within the transitive trust. If there is no CA.pem or any intermediate extractable a failure file is generated. This is mostly the case when an internal CA is used, and the issuer url is not resolvable.