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.
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.
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:
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
- 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
TLSfolder with at least one TLS.pem (optionally TLS_1.pem, TLS_2.pem, ...) and at least one CA.pem (optionally CA_1.pem, ...) - One
UPfolder with at least one UP.pem (optionally UP_1.pem, UP_2.pem, ...)
- One
- 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.txtand/orJWKS.txt(DID_1.txt,..., JWKS_1.txt)
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.
The .pem file MUST contain a valid X509 structure in PEM encoding according to RFC 7468. This includes an proper BEGIN and END header.
The TLS certificate is checked for the non existence of intermediate and root certificates, because this one are considered for the CA.pemfiles.
The combination of TLS.pem + CA.pem is checked for a valid chain to ensure the cryptographic correctness.
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.