Chain of trust

mDocs are verified based on a chain of trust model. In this model, each mDoc is linked to its issuer via a series of certificates, all of which must be validated for the mDoc to be verified.

Chains of trust comprise three parts:

• Root certificate: This digital certificate belongs to the issuing 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.
• 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.
• End-entity: This is the final object that is being issued to holders and sent to verifiers when required. It is signed by is signed by the leaf/end-entity certificate (the last certificate in the chain of certificates).

This model offers the following advantages:

• Scalability: It allows trust to be extended from a trusted authority down to other entities or components. For example, a root certificate authority (CA) can delegate trust to intermediate CAs, which can further delegate trust to end-user certificates. This makes it easier to manage trust across a large network or ecosystem of trust relationships.
• Security: It implements multiple layers of security, with each layer depending on the security of the previous one. This approach can deter attackers and provide more opportunities to detect and mitigate breaches. If one component fails or is compromised, the impact can be isolated, thereby minimizing the impact and preventing further spread of the breach.
• Transparency and auditability: Every step in the chain is typically documented and can be audited, which makes it easier to track where trust was delegated and to ensure that trust relationships have been correctly established and maintained. This transparency is crucial for compliance and security audits.
• Interoperability: The chain of trust is a well-understood and widely adopted model in various security standards, such as SSL/TLS for web security, PKI (Public Key Infrastructure) for digital certificates, and blockchain technologies. This makes it easier to integrate with other systems and ensures compatibility across different platforms.

Overall, the chain of trust model provides a robust, scalable, and manageable way to establish and maintain trust across various components of a digital ecosystem, making it a cornerstone of modern security architectures.

mDocs chain of trust

The following diagram depicts how mDocs implement the chain of trust model:

Issuing Authority Certificate Authority (IACA)

The root certificate, operated by or on behalf of an issuing authority. The IACA is a X.509 certificate used to identify an mDoc issuer and verify the mDocs they issue. An IACA is used to sign Document Signer Certificates (DSCs), which are then in turn used to sign Mobile Security Objects (MSO) in mDocs.

There can be only one IACA per MATTR VII tenant. The private key linked to the certificate is stored and managed in the highly secure and reliable Key Management System (KMS).

IACAs can be valid for up to 20 years.

Once an IACA is created on a MATTR VII tenant, it can be retrieved via an API request. This endpoint is publicly available by design, as it enables a relying party to use the IACA to verify a signed mDoc. This endpoint can be obtained by querying the tenant’s /.well-known/openid-credential-issuer endpoint and inspecting the mdoc_iacas_uri property in the response.

Each IACA includes the following elements:

• Signature: As the IACA is the root certificate, it is self-signed and verified against its own public key also in the certificate.
• Public key: Used to verify the IACA’s certificate signature, as well as the DSC signature.
• Validity information: When the certificate becomes valid or expires, as well as information about how to check its revocation status.

IACAs can be distributed via different mechanisms, for example using a Verified Issuer Certificate Authority List (VICAL).

Document Signer Certificate (DSC)

The end-entity certificate. The DSC is a X.509 certificate used to digitally sign Mobile Security Objects (MSOs) in mDocs. The DSC itself must be issued and signed by the root certificate, which is the Issuing Authority Certificate Authority (IACA).

To sign an mDoc, a valid and active DSC must be used. Note that an mDoc expiry date cannot be later than that of the DSC used to sign it. The DSC is included in the signed mDoc, so a relying party only needs to retrieve the IACA to verify an mDOC.

A single MATTR VII tenant can have multiple DSCs, with different validity periods and activation status. When there are multiple valid and active DSCs on the tenant, the most recently created or modified one is used.

The ISO/IEC 18013:5 standard determines that a chain of certificates that is used to sign an mDL can only include one IACA and one end-entity certificate, which is the DSC. Other mDocs do not have that limitation and can have more than one intermediate certificate, linking the IACA to the end-entity certificate.

Each DSC includes the following elements:

• Signature: DSCs are signed by the IACA, and this signature is verified against the IACA’s public key.
• Public key: Used to verify the MSO signature.
• Validity information: When the certificate becomes valid or expires, as well as information about how to check its revocation status.

Mobile Security Object (MSO)

The end-entity of the chain of trust, which is the issued signed data. mDocs include an IssuerAuth data structure, as defined in the ISO/IEC 18013-5:2021 standard. It contains the MSO payload, which comprises metadata and salted hashed claims.

Each MSO includes the following elements:

• Signature: MSOs are signed by the DSC. Their signature is checked against the DSC public key, and the DSC is validated all the way up to the IACA.
• Public key: Used to verify the signature of the device the mDoc was issued to, enabling device authentication.
• Validity information: When the MSO becomes valid or expires, as well as information about how to check its revocation status.

Certificates Validity

The concept of certificates validity is of paramount importance in the context of mDocs. For an mDoc to be verified, all the certificates within its chain of trust must be valid. If during the verifications process any of the certificates have expired, the mDoc cannot be verified:

Careful analysis must be conducted before determining the certificates life cycle. IACAs are usually created with long expiry dates, some as long as 10-15 years, while DSCs tend to have shorter validity periods. There are a variety of trade offs in making this duration longer or shorter.

Shorter expiration periods enable things like faster key rotation intervals and provide the opportunity to change the cryptographic algorithms being used if required.

On the other hand, short expiration periods come with increased deployment overhead. Whenever a new IACA is issued, the certificate must be distributed to all verifiers that verify mDocs from that issuer.

Understanding the unique needs and requirements of ecosystems is crucial to applying correct certificates validity periods.

Additional resources

Guides

API Reference

MATTR Labs tools