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	Mandatory files Group/Domain folder name	-	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 DCC, IPS-PILGRIMAGE,DICVP,PH4H 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.