Establishing trust with DTS providers

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.

Certificate chains of trust comprise three parts:

• Root certificate: This digital certificate belongs to the Certificate Authority (CA), and as its name implies, is at the root of the trust chain. Any certificate along the chain of trust must be linked to the root certificate. In the context of a DTS this would be the DTS root CA certificate.
• Intermediate certificate: This digital certificate is linked to the root certificate and acts as an intermediary between the root certificate and the end-entity, or between other intermediate certificates. The final certificate in the chain of certificates is referred to as a leaf certificate or an end-entity certificate, and is being used to sign the end-entity. When signing a VICAL, this would be a VICAL Signer Certificate (VSC).
• End-entity: This is the final object that is being signed and is later verified by relying parties. It is signed by the leaf/end-entity certificate (the last certificate in the chain of certificates). In the DTS context, this would be a VICAL.

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

Internal vs external (unmanaged) certificates

MATTR VII offers a robust out-of-the-box solution for Digital Trust Service (DTS) certificate management. This includes generation, storage, and usage of signing certificates, where all the associated private and public keys managed securely within MATTR’s Key Management System (KMS).

However, some DTS providers prefer (or are required to) manage their own certificates required for operating the DTS. Using external DTS certificates offers flexibility for organizations with specific Public Key Infrastructure (PKI) requirements. It preserves the integrity of the DTS trust chain while giving DTS providers full control over their cryptographic materials.

The following table depicts the differences between managed and unmanaged certificates in MATTR VII:

In both models, MATTR VII must be able to associate and understand:

• Who is performing the signing: This is the VICAL Signer, an internal MATTR entity that represents a signer. It contains the signer’s unique identifier and (if managed) the private key in the KMS.
• What certificate is associated with that signer: This is the VICAL Signer Certificate (VSC), which is an X.509 certificate that links the signer’s public key to its identity. In the external (unmanaged) certificate flow, the DTS provider is responsible for creating and uploading this certificate to MATTR VII, so it can be associated with the corresponding signer entities.

The VICAL Signer is like a digital “signing machine” within MATTR, whereas The VSC is the official “license” issued by a trusted authority (e.g., DTS root CA) stating the signer is valid and authorized.

Whenever a VICAL is signed, the signing process involves the use of the entire certificate chain, from the root CA down to the specific VSC used for signing. This ensures that the VICAL can be verified against the established chain of trust. MATTR VII will automatically select active and valid certificates from the chain.

• When using managed DTS certificates, if no valid certificates exist, MATTR VII automatically creates new ones as needed.
• When using unmanaged DTS certificates, it is the responsibility of the DTS provider to ensure valid certificates are available before commencing the signing operation. If no valid certificates exist, the signing operation will fail.

Enabling external (unmanaged) DTS certificates

The following steps outline how to enable and use external DTS certificates in MATTR VII:

1. DTS root CA certificate generation: The DTS provider generates a private/public key pair and uses the private key to sign a self-signed root certificate. This is the DTS root CA.
2. External DTS root CA registration: The DTS provider uses a MATTR VII endpoint to register the external DTS root CA by providing it in PEM format, which includes the public key and other necessary information. This certificate is not managed by MATTR VII, meaning MATTR will not store the private key or handle its lifecycle. An DTS root CA identifier is generated by MATTR VII and is used to reference this external DTS root CA in subsequent operations.
3. VICAL Signer creation: The DTS provider uses a MATTR VII endpoint to create a VICAL Signer which references the external DTS root CA identifier. Attempts to provide a managed DTS root CA identifier for manual VICAL Signer creation will result in an error.
4. Certificate Signing Request (CSR): When a VICAL Signer is created, MATTR VII generates a new private/public key pair:
   • The private key is stored in the MATTR KMS and used to sign a CSR.
   • The public key is included in the CSR, alongside all necessary information to enable the DTS provider to issue a valid certificate that meets MATTR’s requirements (subject fields, extensions).
5. VSC generation: The DTS provider uses the CSR to generate and sign a VICAL Signer Certificate (VSC) which meets the following requirements:
   • Must include the public key from the CSR.
   • Must be signed by the DTS root CA’s private key.
   • Must match the structure and values expected by MATTR, as described in the CSR.
6. Certificate upload: After the VSC is signed, the DTS provider uses a MATTR VII endpoint to upload it in PEM format and associate it with the VICAL Signer.
7. Certificate validation: MATTR VII will validate the uploaded certificate to ensure it is signed by the expected DTS root CA, contains the correct public key, and includes the necessary X.509 extensions and usages. See certificate requirements below for more details.
8. Signer and DTS root CA activation: Once the certificate is validated, the VICAL Signer, followed by the registered external DTS root CA, can be activated, allowing them to be used when signing VICALs. MATTR VII will not select any VICAL Signers if their referenced external DTS root CA is not active.
9. Signing VICALs: MATTR VII uses the uploaded VSC and the corresponding private key stored in its KMS to sign the VICAL. This process ensures the VICAL is signed by the correct VICAL Signer and maintains the chain of trust.
10. VICAL signature verification: When a relying party attempts to verify the signed VICAL, they will ensure the VSC is valid, trace the VSC back to the registered root certificate (DTS root CA) and check each certificate’s signature and validity along the chain of trust.
11. Certificate lifecycle management: The DTS provider is responsible for managing the lifecycle of the external certificates, including renewal and revocation. MATTR VII will not automatically handle these tasks for external DTS certificates.

Certificates requirements

The following lists depicts the requirements for 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 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 certificates

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

• DTS root CA 
• VSC 

Certificates rotation

To support certificates rotation, a single MATTR VII tenant can manage multiple DTS root CA certificates. This approach allows issuers to distribute new DTS root CAs in advance, ensuring seamless continuity of relying party reliance over their DTS.

The process involves creating a new DTS root CA certificate without activating it, which means it will not be used by MATTR VII to sign new VSCs. However, this inactive DTS root CA can be shared with relying parties ahead of its activation. When ready, the issuer can activate the new DTS root CA and then deactivate the old one. After this switch, new VSCs will be signed using the new DTS root CA, and relying parties will be able to verify VICALs signed by these VSCs immediately, as the DTS root CA was pre-distributed to them.

DTS root CA rotation should be performed as follows:

1. Identify that the current active DTS root CA (DTS root CA #1) must be rotated as it is about to expire.
2. Create a new DTS root CA #2.
3. Distribute DTS root CA #2 to all relying parties.

4. Set DTS root CA #2 to active.

Additional resources

Guides

API Reference

MATTR Labs tools