PKI and key management

As a verifier, PKI works in two directions, and they are separate concerns: the trust you establish in the issuers whose credentials you accept, and the trust wallets place in the requests you send.

Who you trust

You decide which issuers you accept credentials from by trusting their IACAs. Your verifier validates that a presented credential's signature chains back to a trusted root. You can trust issuer roots directly, or by consuming a VICAL that aggregates them, and MATTR's managed trust lists keep those roots current for you. For how to configure trusted issuers, see Establish trust with issuers.

Who trusts you

Wallets trust that verification requests come from you because those requests are signed by a certificate that chains to your own Verifier root CA. MATTR VII can manage that hierarchy and its keys for you, or you can supply your own externally managed certificates and retain control of the chain. Either way, this lets wallets identify and trust any verification request you send to them. For the certificates involved, see the verification certificates pages.

This page gives a cross-capability overview of MATTR's PKI and key management.

What is PKI at MATTR?

Public Key Infrastructure (PKI) is how MATTR VII establishes trust in the artifacts it signs. An artifact, such as an mDoc, a verification request, or a wallet attestation, is signed with a private key. Anyone who holds the matching trust anchor can then verify that signature back through a chain of trust, without contacting the signer at the time of verification. This is what lets a relying party confirm that a signed artifact traces back to a recognized authority, offline and at scale.

MATTR VII provides a fully managed PKI: it generates and maintains the certificates that make up each chain of trust and the keys that sign them, and rotates signer certificates for you. This is the focus of this page. If you already run your own PKI, you can supply unmanaged (external) certificates instead.

Signing credentials as an issuer is the most common use of PKI today, but it is not the only one. The same chain-of-trust model establishes trust across every part of the credential lifecycle, from issuance and verification to holding and the Digital Trust Service. The trust directions specific to each capability are covered at the top of that capability's PKI page.

Because the chain-of-trust model is shared, the concepts on this page apply across all of these areas. The certificate types differ by role, and each has its own detailed reference, linked in Certificate types by capability at the end of this page.

Key protection options

Private keys are the most sensitive part of any PKI, so choosing how they are protected is one of the key decisions when planning a deployment. In a managed PKI, MATTR VII protects keys through its Key Management System (KMS), which offers more than one protection approach, based on the assurance level a deployment requires:

The choice sets the balance between how strongly a key is protected and how readily it can sign. The software SSM needs no hardware and suits most deployments. An HSM adds dedicated tamper-resistant hardware for higher assurance, and the offline and online variants sit at opposite ends of the trade-off: an offline HSM gives the strongest protection but requires a deliberate ceremony to sign, so it suits keys used rarely, such as root keys, while an online HSM stays available for frequent, automated signing, so it suits operational signer keys, such as the private keys behind Document Signer Certificates (DSCs). The section below explains how the offline and online HSM are combined in a managed PKI.

How the offline and online HSM work together

The pairing below is the common deployment model, and the one MATTR recommends, because it protects each key according to how it is used. In a managed PKI, MATTR VII places each key in the HSM that matches how often it is used and how much protection it needs. Root keys are the most valuable and the least frequently used, so they are held offline and protected under the strictest controls. Operational signer keys are used constantly, so they are held online where they can sign on demand. The architecture supports other combinations if your requirements differ, which we can discuss with you.

The offline HSM holds the roots of the chain of trust. Because a root key underpins every certificate beneath it, it is kept offline and is brought into use only for scheduled operations such as issuing or rolling over a signer certificate, or responding to a compromise. Those operations are performed as formal ceremonies that require several trusted people to act together, so that no single person can use a root key alone. Between ceremonies the offline HSM is deactivated.

The online HSM holds the operational signer keys that sign day-to-day. When MATTR VII issues an mDoc, publishes a status list, or signs a trusted list, it uses a signer key in the online HSM. In a managed PKI, MATTR VII also creates and renews these signer certificates for you. For example, if a signer certificate is about to expire, or would not cover the validity of the object it needs to sign, MATTR VII can issue a new one automatically. This is what lets issuance and status publishing run automatically and at volume, while the root keys that authorize those signers stay protected offline.

Both HSM tiers are covered by documented backup and restoration procedures so that key material can be recovered under controlled conditions as part of business continuity planning.

Architecture

A MATTR VII PKI is arranged as a hierarchy. A self-signed root certificate anchors trust, one or more signer certificates chain to it, and the signed artifact (an mDoc, a status list, a wallet attestation, or a trusted list) sits at the end of the chain. A verifier or consumer validates the signature on the artifact up through the signer to the root, and only needs the trusted root's public key to do so.

Trust anchors are distributed to relying parties in different ways depending on the ecosystem. When a root certificate is published directly, it is the root's public key that is shared. The private key is never exposed. A relying party uses the public key to validate signatures, and a signer holds the corresponding private key to create them. Root certificates can be published directly, retrieved from an issuer's metadata endpoint, or distributed at scale through a managed trusted list such as a VICAL for issuers or a RICAL for readers. MATTR also publishes managed trust lists so that verifiers can stay current as issuers join or rotate certificates.

Most hierarchies are two-tier, where a root CA signs signer certificates directly. DTS also supports a three-tier hierarchy that inserts an intermediate CA between the root and the signer. See DTS certificate models for how the two-tier and three-tier models compare.

Managed and unmanaged certificates

MATTR VII provides a fully managed PKI by default, and that is the focus of this page. For organizations that already run their own PKI, it also supports supplying externally managed certificates, and you can choose the method per deployment:

• Managed certificates. MATTR VII generates and maintains the root and signer certificates and their private keys on your behalf, and rotates signer certificates automatically. This is the simplest option and suits most deployments.
• Unmanaged (external) certificates. You supply your own externally managed root certificate in PEM format and remain responsible for generating, protecting, and rotating the associated keys. This gives you full control of the certificate chain and suits organizations with an existing PKI.

Here, managed and unmanaged describe who controls the root CA certificate and its private key, not whether you use MATTR VII as a managed service. In the unmanaged (external) model, MATTR VII does not store the root CA private key. Depending on the workflow, MATTR VII may still generate and hold signer keys in its KMS. A deployment can use unmanaged certificates and still run within MATTR VII's managed service. For the details of the unmanaged model, including certificate requirements and rotation responsibilities, see external certificates.

Considerations

When planning a PKI deployment, weigh the following:

• Certificate validity and rotation. Set each certificate's validity period to the shortest duration that remains practical for your ecosystem. Shorter periods limit the impact of a key compromise but increase the overhead of rotating and redistributing certificates, which matters most for root certificates that relying parties must hold. See certificate validity and certificate rotation.
• Managed against unmanaged. Managed certificates remove operational burden and rotate signer certificates for you. Unmanaged certificates give full control and let you align with an existing enterprise PKI, at the cost of managing key protection and rotation yourself.
• Key protection level. Match the protection option to the sensitivity of the key. Root keys benefit from the strongest protection, such as an offline HSM, while operational signer keys need to balance protection with availability.
• Revocation. Plan how revocation will be published and consumed. Revoked signer certificates are published in a Certificate Revocation List (CRL) referenced by the issuing CA certificate, which may be a root CA or, in a three-tier hierarchy, an intermediate CA. Relying parties must retrieve and honor it. See revoke signing certificates.
• Interoperability. Where credentials are consumed by third-party wallets and verifiers, choose algorithms and curves that are widely supported. Managed issuance certificates (IACA and DSC) use ECDSA with the P-256 curve for maximum compatibility.

Certificate types by capability

The certificates involved differ by capability, whether they are managed by MATTR VII or supplied as unmanaged (external) certificates. Each links to its detailed requirements and lifecycle guidance. All are X.509 v3 certificates and follow the algorithm, curve, and validity requirements described in the referenced pages, aligned with ISO/IEC 18013-5:2021.

Issuance

Verification

Holding

Digital Trust Service

Frequently asked questions

Do I have to bring my own PKI?

No. MATTR VII can provide a fully managed PKI, generating and maintaining the root and signer certificates and their keys for you. If you have an existing enterprise PKI, you can instead use unmanaged (external) certificates and retain full control of the chain.

What is the difference between an offline and an online HSM?

An offline HSM protects root key material that is used rarely, such as an IACA or DTS root CA. It is kept offline and activated only for a scheduled ceremony under multi-person control, then deactivated. An online HSM is network-attached and holds the operational signer keys that sign frequently and automatically, such as Document Signer Certificates signing mDocs, within the regional cloud. In a managed PKI, MATTR VII uses both together: roots offline, signers online.

Which keys can be protected by an HSM?

Both root key material and operational signer keys can be HSM-protected. In a managed PKI, root keys (the private keys behind the IACA and DTS root CA) are held in the offline HSM for the highest assurance, and operational signer keys (the private keys behind the DSC, SLSC, VRSC, WASC, and DTS VSC/RSC signer certificates) are held in the online HSM so they remain available for routine signing. The software-based SSM is included with MATTR VII for deployments that do not require an HSM.

How are root keys protected during signing?

Root keys stay in the offline HSM and are used only for scheduled operations, such as issuing or rolling over a signer certificate. Those operations are performed as formal ceremonies that require several trusted people to act together under split knowledge and multi-person control, so that no single person can use a root key alone. Between ceremonies the offline HSM is deactivated. Both HSM tiers are covered by documented backup and restoration procedures for business continuity.

How is trust distributed to relying parties?

Trust anchors can be published directly, retrieved from an issuer's metadata endpoint, or distributed through a managed trusted list. For issuers, a VICAL distributes trusted IACA certificates. For readers, a RICAL distributes trusted verifier certificates. MATTR also publishes managed trust lists of verified issuer certificates.

How does revocation work?

Revoked signer certificates are published in a Certificate Revocation List (CRL) referenced by the issuing CA certificate, which may be a root CA or, in a three-tier hierarchy, an intermediate CA. Relying parties retrieve the CRL and treat a revoked certificate, and anything it signed, as invalid. Revocation support varies by capability and management model. Where MATTR VII manages the issuing CA, it can publish the CRL for you. For unmanaged certificates, you revoke directly with the CA that issued the certificate.

Which standards does the PKI align with?

The mDoc chain of trust and certificate profiles align with ISO/IEC 18013-5:2021. Certificates are X.509 v3, and the supported algorithms and curves are listed on the certificate reference pages linked above.