Overview

Chain of trust

When DTS operators publish trusted lists for relying parties (such as a trusted list of mDoc issuers in the form of a VICAL) they must ensure that relying parties can verify the authenticity and integrity of these lists. This is accomplished using a chain of trust, which is established through a hierarchy of certificates.

The following diagram depicts how MATTR implements the chain of trust model when signing VICALs:

Certificates requirements

The following lists depicts the requirements for DTS certificates used in MATTR VII. Some of the requirements are common across all certificates, while others are specific to the type of certificate (DTS root CA, VSC).

• When using managed DTS certificates, MATTR VII automatically ensures that all certificates meet these requirements.
• When using unmanaged (external) DTS certificates, it is the responsibility of the DTS provider to ensure compliance.

Common certificate requirements

• Certificate format & basic attributes:

  • PEM format must contain a valid X.509 certificate.
  • Version must be v3.
  • Issuer field must be present and valid.
  • Issuer Alternative Name must be present and contain a valid email address or URI.
  • Serial Number:
    • Must be present.
    • Must contain 1-20 digits (Best practice: Use a positive, non-sequential value).

• Subject attributes:

  • Subject field must be present:
    • Country (C): must be present and be a valid ISO 3166-1 alpha-2 code.
    • Common Name (CN): must be present and non-empty.
    • Organization (O): must be present and non-empty.

• Public Key requirements:

  • Subject Public Key must be present.

• Extensions:

  • Certificate must include extensions.
  • Duplicate extensions are not allowed (No more than one extension with the same extnID).
  • Mandatory extensions:
    • Subject Key Identifier: Must be present and non-empty.
    • Key Usage:
      • Must be present.
      • Must match the intended use of the certificate (e.g. DTS root CA, VSC).

• Validity period:

  • NotAfter must be after NotBefore.
  • NotAfter cannot be in the past (expired certificates are invalid).
  • Future dated certificates are valid (e.g. notBefore can be in the future).
  • Must be within allowed limits for certificate type:
    • VSC: Maximum 1187 days from issuance.

• Certificate Revocation List (CRL):

  • If a CRL is provided, it must be valid and signed by the DTS root CA.
  • The CRL must be accessible via a valid URI.

DTS root CA specific requirements

• Must include the keyCertSign and cRLSign key usages.
• Basic constraints must be present and CA must be set to TRUE.
• Issuer Alternative Name must be present and contain a valid email address or URI.
• Signature must be self-signed and verifiable.
• Public key must use one of the supported Elliptic Curves (EC) as defined in ISO/IEC 18013-5:2021 B.3:
  • P-256
  • P-384
  • P-521
  • brainpoolP256r1
  • brainpoolP320r1
  • brainpoolP384r1
  • brainpoolP512r1

VSC specific requirements

• Must be signed by a valid DTS root CA.
• Common name must differ from parent/root DTS root CA.
• Issuer field must be present and must match the exact binary value of the DTS root CA certificate subject.
• Must include the nonRepudiation key usage exclusively.
• Extended key usage must be present and include the correct OID:
  • 1.0.18013.5.1.8.
• Signature must be verifiable against the DTS root CA.
• Authority Key Identifier must be present and match the DTS root CA's Subject Key Identifier.
• Must not exceed parent DTS root CA's validity period (i.e. notBefore and notAfter must be within the DTS root CA's validity period).
• Public key must match the CSR provided during VICAL Signer creation.

Example DTS certificates

See an example of valid certificates parsed using the MATTR Labs X.509 certificate decoder:

• DTS root CA
• VSC