Merkle Tree Certificates With Tiled Transparency Logs

This document defines a profile of Merkle Tree Certificates (MTCs) that uses tiled transparency logs.

Conventions used in this document §

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.

Parameters §

An MTC CA following this profile has, in addition to CA parameters defined in the MTC specification, one or more CA prefix URLs. Each CA prefix URL determines a set of serving URLs for the CA's issuance logs, as described below.

When such a CA is represented as an X.509 certificate, the certificate has a non-critical X.509 extension with OID 1.3.6.1.4.1.64829.2.2 and syntax a SEQUENCE OF IA5String, as defined below. Each IA5String's contents are one of the CA prefix URLs. Presence of this extension indicates that the certificate subject follows this specification.

id-mtcTlogPrefixURLs OBJECT IDENTIFIER ::= {
    iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) C2SP(64829)
    mtc-tlog(2) 2 }

MTCTlogPrefixURLs ::= SEQUENCE SIZE (1..MAX) OF IA5String

ext-mtcTlogPrefixURLs EXTENSION ::= {
    SYNTAX MTCTlogPrefixURLs
    IDENTIFIED BY id-mtcTlogPrefixURLs
    CRITICALITY FALSE
}

Tiled transparency logs are currently only defined with SHA-256, so MTC CAs following this profile MUST use SHA-256 as the hash algorithm.

Representing Trust Anchor IDs §

MTC entities are named using trust anchor IDs. This section defines how to map these to log origins and cosigner names. A trust anchor ID is represented as the concatenation of:

The 16-byte ASCII string oid/1.3.6.1.4.1., including the trailing period
The trust anchor ID's ASCII representation

This is equivalent to the concatenation of:

The four-byte ASCII string oid/
The trust anchor ID as a full OID, in dotted decimal notation

For example, the trust anchor ID 32473.1 is represented as oid/1.3.6.1.4.1.32473.1.

Serving Issuance Logs §

MTC CAs following this profile MUST serve issuance logs as tiled transparency logs. Each log's prefix URLs are determined by concatenating the log number, encoded as an ASCII decimal integer with no additional leading zeros, to each CA prefix URL:

<CA prefix URL>/<log number>

Each issuance log’s origin is its log ID represented as described above. For example, log 42 of a CA with ID 32473.2 has a log ID of 32473.2.0.42 and a log origin of oid/1.3.6.1.4.1.32473.2.0.42.

Each issuance log MUST serve a checkpoint that includes a signature from its CA cosigner, formatted as a note signature. The CA cosigner is mapped to a transparency log cosigner as described below. Issuance logs MAY serve additional cosignatures, including ones from cosigners that are not MTC cosigners.

Relying parties SHOULD set restrictions on pruning, such as requiring that the log's minimum index be at most the minimum trusted index in up-to-date copies of the relying party's trust anchors.

For each CA prefix URL, an issuance log with a landmark sequence MUST publish active landmarks at the following URL:

<CA prefix URL>/<log number>/landmarks

The content type MUST be text/plain; charset=utf-8.

Most deployments obtain landmark-relative certificates directly from the CA. Alternatively, a party holding a standalone certificate can construct the corresponding landmark-relative certificate by following the generic construction procedure. The landmark sequence is available at the URL above, and the required inclusion proof hashes are available from the log's Merkle Tree tiles.

Cosigners §

An MTC cosigner is mapped to a transparency log cosigner as follows:

The cosigner name is derived from the MTC cosigner’s ID as described above. For example, an MTC cosigner with ID 32473.3 has name oid/1.3.6.1.4.1.32473.3.
The MTC cosigner MUST generate cosignatures with ML-DSA-44, defined in RFC 9881. The transparency log cosigner is then an ML-DSA-44 cosigner, which is compatible with the MTC signature format. This MAY be extended to future MTC-compatible, subtree-capable cosigners.

Conversely, a witness, mirror, or other transparency log cosigner whose subtree cosignatures are used in standalone certificates MUST have a cosigner name satisfying the above requirements. It SHOULD implement the sign-subtree endpoint for CAs to request subtree signatures.

An MTC CA’s CA cosigner has the same ID as the CA, so a CA with ID 32473.2 has a cosigner name of oid/1.3.6.1.4.1.32473.2. Note this is different from the log origin.

An MTC CA operates a series of issuance logs, switching to the next log number as needed for failure recovery. Witnesses and other non-CA cosigners SHOULD be configured to accept the next few unused log numbers.