How does a DTS chain of trust work and what are the requirements for DTS certificates?

Chain of trust

When DTS operators publish trusted lists (such as a trusted list of mDoc issuers in the form of a VICAL, or a trusted list of verifiers in the form of a RICAL) they must ensure that consumers 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.

Each trusted list is signed by a signer certificate that chains back to a DTS root CA: a VICAL Signer Certificate (VSC) for a VICAL, or a RICAL Signer Certificate (RSC) for a RICAL. The same DTS certificate models and requirements described on this page apply to both.

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

Certificate models: 2-tier and 3-tier

MATTR VII supports two certificate models for signing trusted lists, depending on whether an intermediate CA certificate is included in the chain of trust:

• 2-tier model: The chain consists of a DTS root CA certificate that directly signs the signer certificate (VSC or RSC). This is the default model.
• 3-tier model: The chain includes an additional DTS intermediate CA certificate between the DTS root CA and the signer certificate (VSC or RSC). The DTS root CA signs the intermediate CA, and the intermediate CA signs the signer certificate.

The certificate model is determined by the useIntermediateCa property on the DTS root CA certificate. When set to true, the DTS root CA requires and uses intermediate CA certificates as part of its chain of trust for signing operations.

Choosing a model

Consider the following when deciding between the two models:

• Operational simplicity: The 2-tier model involves fewer certificates to issue, manage, and renew. If you do not have a specific requirement for an intermediate CA, the 2-tier model is simpler to operate.
• Key protection and isolation: The 3-tier model lets you keep the DTS root CA private key offline and use the intermediate CA for day-to-day signing. This reduces exposure of the root key and limits the impact if an intermediate CA is compromised, as you can revoke and replace the intermediate without rotating the root.
• PKI alignment: Choose the 3-tier model if your organization's existing Public Key Infrastructure (PKI) policies require a layered hierarchy with intermediate CAs, or if you need to delegate signing to separate intermediate authorities.
• Management method: The 3-tier model requires unmanaged (external) certificates for both the root and intermediate CA. If you want MATTR VII to manage your DTS root CA, you must use the 2-tier model.

Certificate requirements

The following list describes 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, signer certificate). The signer certificate requirements apply to both the VICAL Signer Certificate (VSC) and the RICAL Signer Certificate (RSC).

• 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, RSC).

• Validity period:

  • NotAfter must be after NotBefore.
  • NotAfter cannot be in the past (expired certificates are invalid).
  • CA certificates (DTS root CA and DTS intermediate CA) can be future dated (notBefore can be in the future).
  • Signer certificates (VSC or RSC) cannot be future dated (notBefore cannot be in the future).
  • Must be within allowed limits for certificate type:
    • Signer certificate (VSC or RSC): 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 public key algorithms and curves as defined in ISO/IEC 18013-5:2021 B.3:
  • ECDSA curves: P-256, P-384, P-521, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
  • EdDSA key types: Ed25519, Ed448

DTS intermediate CA specific requirements

These requirements apply only when using the 3-tier model.

• Must be signed by a valid DTS root CA that has useIntermediateCa set to true.
• Must include the keyCertSign key usage.
• Basic constraints must be present and CA must be set to TRUE.
• Issuer field must be present and must match the exact binary value of the DTS root CA certificate subject.
• Authority Key Identifier must be present and match the DTS root CA's Subject Key Identifier.
• The country must match the country of the DTS root CA certificate.
• Must not exceed the parent DTS root CA's validity period (i.e. notBefore and notAfter must be within the DTS root CA's validity period).
• Signature must be verifiable against the DTS root CA.

Signer certificate specific requirements (VSC and RSC)

These requirements apply to both the VICAL Signer Certificate (VSC) and the RICAL Signer Certificate (RSC).

• Must be signed by a valid signing CA: the DTS root CA in the 2-tier model, or the DTS intermediate CA in the 3-tier model.
• Common name must differ from the parent signing CA.
• Issuer field must be present and must match the exact binary value of the parent signing 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 parent signing CA.
• Authority Key Identifier must be present and match the parent signing CA's Subject Key Identifier.
• Must not exceed the parent signing CA's validity period (i.e. notBefore and notAfter must be within the parent signing CA's validity period).
• Public key must match the CSR provided during signer creation.

Example DTS certificates

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

• DTS root CA
• VSC