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 certificates and the end-entities. A chain of trust must have at least one intermediate certificate.
• End-entity: This is the final certificate that is being issued to holders and sent to verifiers when required. It is signed by an intermediate certificate.

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.

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

Document Signer Certificate (DSC)

An intermediate 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).

A single MATTR VII tenant can have multiple DSCs. Different DSCs can have different validity periods and activation status.

To sign an mDoc, a valid and active DSC must be used. If there are multiple valid and active DSCs on the tenant, the most recently created or modified one is used.

The DSC is included in the signed mDoc, so a relying party only needs to retrieve the IACA to verify the credential.

Note that an mDoc expiry date cannot be later than that of the DSC used to sign it.

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.

Mobile Security Object (MSO)

The end-entity. 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.

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. 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.

Consider the example of applying validity life cycles when issuing e-Passports:

• In 2023, an e-Passport issuer creates a root certificate valid for 15 years (until 2038).
• From 2023 to 2028, the issuer uses this root certificate to issue e-Passports valid for 10 years. Depending on their issuance date, these e-Passports will expire between 2033 and 2038 (an e-Passport issued in 2023 would expire in 2033, an e-Passport issued in 2024 would expire in 2034, etc.).
• The latest e-Passport using the current root certificate is issued in 2028 and will expire at the same time the root certificate expires in 2038. This ensure that issued e-Passports are never found invalid due to an expired root certificate.
• In 2028, the issuer creates a new root certificate valid for 15 years (until 2043) and uses it to issue e-Passports from 2028 to 2033. The previous root certificate will still be used to verify e-Passports issued between 2023 and 2028, but will no longer be used to issue new e-Passports.
• The cycle will continue in the same manner, to ensure that new e-Passports never expire before their root certificate does. Note that this means that by design, there are always several root certificates valid and in use at the same time.

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

Additional resources

Guides

API Reference

MATTR Labs tools