Overview

Chain of trust

When verifiers request digital credentials, holders need a way to confirm the verifier’s identity and decide whether to trust them with their information. This is accomplished using a chain of trust, a hierarchy of certificates that proves the verifier’s authenticity.

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

Certificate requirements

The following lists depicts the requirements for external certificates used in MATTR VII. Some of the requirements are common across all certificates, while others are specific to the type of certificate (Verifier root CA, VRSC).

• When using managed verifier certificates, MATTR VII automatically ensures that all certificates meet these requirements.
• When using unmanaged verifier certificates, it is the responsibility of the verifier 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.

• 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. Verifier root CA, VRSC).

• 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:
    • VRSC: Maximum 1187 days from issuance.

• Certificate Revocation List (CRL):

  • If a CRL is provided, it must be valid and signed by the verifier root CA.
  • The CRL must be accessible via a valid URI.

Verifier 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

VRSC specific requirements

• Must be signed by a valid Verifier root CA.
• Common name must differ from parent/root Verifier root CA.
• Issuer field must be present and must match the exact binary value of the Verifier root CA certificate subject.
• Must include the digitalSignature key usage exclusively.
• Must include the Subject Alternative Name extension with a value that matches the requirement in the CSR.
• Extended key usage must be present and include the correct OID:
  • 1.0.18013.5.1.6.
• Signature must be verifiable against the Verifier root CA.
• Authority Key Identifier must be present and match the Verifier root CA's Subject Key Identifier.
• Must not exceed parent Verifier root CA's validity period (i.e. notBefore and notAfter must be within the Verifier root CA's validity period).
• Public key must match the CSR provided during Verification Request Signer creation.

Example certificates

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

• Verifier root CA
• VRSC