Chain of trust

Overview

Certificates are used as a foundation of trust within MATTR’s capabilities. They provide the assurance needed to validate digital artifacts—whether that’s an issued credential, an identity, a verification request, or a trusted list.

These certificates are verified based on a chain of trust model, where each certificate is linked to its issuer via a series of certificates:

• 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.
• 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 signed by the leaf/end-entity certificate (the last certificate in the chain of certificates). For example, when an issuer signs a credential, the end-entity is the credential itself. When a verifier requests a verification of a credential, the end-entity is the verification request.

For example, this is how the chain of trust model is applied to verify the identity of an issuer signing an mDoc:

The root certificate is the Issuer Authority Certificate Authority (IACA). It is used to sign a Document Signer Certificate (DSC), which is the leaf/end-entity certificate. The DSC is then used to sign the Mobile Security Object (MSO) in the issued mDoc, which is the end-entity.

Ket benefits

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.

External certificates

MATTR VII offers a robust out-of-the-box solution for 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 customers prefer (or are required to) manage their own certificates required for different digital credential workflows. External certificates support in MATTR VII offers flexibility to comply with specific Public Key Infrastructure (PKI) requirements. It preserves the integrity of the trust chain while giving customers full control over their cryptographic materials.

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

In both models, in every signing operation MATTR VII must be able to associate and understand:

• Who is performing the signing: This is an internal MATTR entity that represents a signer. It contains the signer’s unique identifier and (if managed) the private key in KMS.
• What certificate is associated with that signer: This is a X.509 certificate that links the signer’s public key to its identity. In the external (unmanaged) certificate flow, the customer is responsible for creating and uploading this certificate to MATTR VII, so it can be associated with the corresponding signer entities.
• What root certificate authority (CA) issued the certificate: This is the root CA that issued the certificate associated with the signer. In the external (unmanaged) certificate flow, the customer is responsible for registering this root CA in MATTR VII, so it can be used to validate the certificate chain of trust.

The signer is like a digital "signing machine" within MATTR, whereas the signer certificate is the official "license" issued by a trusted authority stating the signer is valid and authorized.

Enabling external certificates

The following steps outline the process of enabling and using external certificates in MATTR VII:

1. Root CA certificate generation: The customer generates a private/public key pair and uses the private key to sign a self-signed root certificate.
2. Unmanaged root CA certificate registration: The customer uses a MATTR VII endpoint to register the unmanaged root CA certificate by providing it in PEM format, which includes the public key and other necessary information. This root CA certificate is not managed by MATTR VII, meaning MATTR will not store the private key or handle its lifecycle. A root CA certificate identifier is generated by MATTR VII and is used to reference this unmanaged root CA certificate in subsequent operations.
3. Signer creation: The customer uses a MATTR VII endpoint to create a signer which references the unmanaged root CA certificate identifier.
4. Certificate Signing Request (CSR): When a 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 customer to issue a valid certificate that meets MATTR’s requirements.
5. Signer certificate generation: The customer uses the CSR to generate and sign a signer certificate which meets the following requirements:
   • Must include the public key from the CSR.
   • Must be signed by the root CA certificate private key.
   • Must match the structure and values expected by MATTR, as described in the CSR.
6. Certificate upload: After the signer certificate is signed, the customer uses a MATTR VII endpoint to upload it in PEM format and associate it with the signer.
7. Certificate validation: MATTR VII will validate the uploaded certificate to ensure it is signed by the expected root CA certificate, contains the correct public key, and includes the necessary X.509 extensions and usages.
8. Signer and root CA certificate activation: Once the certificate is validated, the signer, followed by the registered unmanaged root CA certificate, can be activated, allowing them to be used in signing operations. MATTR VII will not select any signers if their referenced root CA certificate is not active.
9. Certificate lifecycle management: The customer is responsible for managing the lifecycle of the external certificates, including renewal and revocation. MATTR VII will not automatically handle these tasks for unmanaged root CA certificates.

Certificates rotation

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

The process involves creating a new root CA certificate without activating it, which means it will not be used by MATTR VII in any sign operations. However, this inactive root CA can be shared with relying parties ahead of its activation. When ready, the customer can activate the new root CA which automatically deactivates the old one. After this switch, new signer certificates will be signed using the new root CA, and relying parties will be able to verify end-entities signed by these signer certificates immediately, as the root CA was pre-distributed to them.

Root CA rotation should be performed as follows:

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

4. Set root CA #2 to active.