Skip to content

Member Identity Digital Certificates

The Directory issues X.509 digital certificates to Members that assert Member identity for:

  • Clients: to prove identity when connecting to a server
  • Signing: to sign data at rest, for example, Provenance records

These are collectively referred to as Member certificates. Certificates for server authentication are specified separately.

Member certificates include the Directory URL of an Application in the Subject of the certificate. Applications identify a use of data in the Trust Framework and the Roles the Member is using. The Member's Directory URL and the Roles in use are included as extensions in the certificates.

Member certificates are long-lived, obtained by logging into the Directory, and a Certificate Revocation List must be checked by servers and when signatures are checked.

Dependencies

A Scheme using this specification must also adopt a specification for server certificates that defines how services operated by Members are authenticated within the Trust Framework.

Client certificates

Presentation of a client certificate provides:

  • assurance that the client is operated by a Member of the Trust Framework
  • the Directory URL of the Application, which identifies this use of data in all metadata
  • a subset of the Member's roles (group membership) in their Schemes
  • the Member's Directory URL

Client certificates are valid for 12 months.

  • CN=[Trust Framework] Client CA
    • CN=[Trust Framework] Client Issuer
      • C=[Country code] O=[Client Name] CN=[Application Directory URL], subjectAlternativeName=URI:[Application Directory URL]

See below for the X.509 extensions that are required for the certificates.

Obtaining a client certificate

A Member logs into the Directory, or uses an API, provides a CSR, and requests a client certificate. The Directory generates a certificate which encodes the Application, Member identity and Roles. Only the public key from the CSR is used, all other certificate fields are populated by the Directory.

The client must manually renew the certificate before it expires.

Verifying a client certificate

A server must verify that

  • a client certificate has been presented and it has not expired
  • the client certificate is issued with a certificate chain leading to the Client CA root certificate
  • the client certificate has not been revoked
  • the Roles extension contains the required role to access the API.

Signing certificates

Members sign metadata with signing certificates to prove that they created it at a specified time. The signing certificates and their issuer chain may either be included along with the signed data, or fetched from the Directory using their serial number.

Signing certificates are valid for 12 months.

  • CN=[Trust Framework] Signing CA
    • CN=[Trust Framework] Signing Issuer
      • C=[Country code] O=[Client Name] CN=[Application Directory URL], subjectAlternativeName=URI:[Application Directory URL]

See below for the X.509 extensions that are required for the certificates.

Obtaining a signing certificate

A Member logs into the Directory, or uses an API, provides a CSR, and requests a signing certificate. The Directory generates a certificate which encodes the Application, Member identity and Roles. Only the public key from the CSR is used, all other certificate fields are populated by the Directory.

The client must manually renew the certificate before it expires.

Verifying a signing certificate

A Member verifying signed data must verify that

  • the signing certificate is issued with a certificate chain leading to the Signing CA root certificate
  • the signing certificate has not been revoked
  • the signing certificate was valid at the time of signature
  • if applicable, the Roles extension contains the required role to generate the metadata.

IB1 X.509 extensions

Trust Framework certificates use X.509 extensions defined under IB1's ASN.1 OID prefix, 1.3.6.1.4.1.62329, to provide additional identity information.

ib1Roles (1.3.6.1.4.1.62329.1.1)
One or more Directory URLs of the Member's Roles when acting with this certificate, as an ASN.1 SEQUENCE of UTF-8 strings. This list of Roles may be a subset of the Member's Roles.
ib1Member (1.3.6.1.4.1.62329.1.3)
The Directory URL of the Member, as an ASN.1 UTF-8 string.

Certificate Profiles

CA certificates

The root CA certificates must conform to the Root CA Certificate Profile defined in the version of the CA/Browser Forum Baseline Requirements for TLS Server Certificates in force at the time of creation.

Root CA certificates use ECDSA keys with the secp384r1 (P-384) curve, and have a 9132 day (approx 25 years) validity time. Their private keys are kept offline, and only used to create Issuer certificates.

Issuer certificates

The Issuer certificates must conform to the TLS Subordinate CA Certificate Profile defined in the version of the CA/Browser Forum Baseline Requirements for TLS Server Certificates in force at the time of creation.

Issuer certificates are regularly regenerated. To comply with the RFC5280 Basic Path Validation algorithm, their validity time is the validity time of a Member certificate plus the regeneration period.

They use ECDSA keys with the secp256r1 (P-256) curve.

Member certificates

Member certificates must conform to the Subscriber (End-Entity) Certificate Profile defined in the version of the CA/Browser Forum Baseline Requirements for TLS Server Certificates in force at the time of issue.

They use ECDSA keys with the secp256r1 (P-256) curve.

Client and Signing certificates must also include the following additional extensions:

  • Subject Alternative Name with the Member URL as a URI type name.
  • ib1Roles
  • ib1Member

Summary of required extensions for Client and Signing certificates

  • Subject Alternative Name (Member URL as URI)
  • ib1Roles
  • ib1Member
  • Subject Key Identifier
  • Authority Key Identifier
  • Basic Constraints
  • Key Usage