Merkle Tree Certificates

2.1. Terminology and Roles

This document discusses the following roles:¶

Authenticating party:

The party that authenticates itself in the protocol. In TLS, this is the side sending the Certificate and CertificateVerify message.¶

Certification authority (CA):

The service that issues certificates to the authenticating party, after performing some validation process on the certificate contents.¶

Relying party:

The party whom the authenticating party presents its identity to. In TLS, this is the side receiving the Certificate and CertificateVerify message.¶

Monitor:

Parties who watch logs for certificates of interest, analogous to the role in Section 8.2 of [RFC9162].¶

Issuance log:

A log, maintained by the CA, of everything issued by that CA.¶

Cosigner:

A service that signs views of an issuance log, to assert correct operation and other properties about the entries.¶

Additionally, there are several terms used throughout this document to describe this proposal. This section provides an overview. They will be further defined and discussed in detail throughout the document.¶

Checkpoint:

A description of the complete state of the log at some time.¶

Entry:

An individual element of the log, describing information which the CA has validated and certified.¶

Subtree:

A smaller Merkle Tree over a portion of the log, defined by an interior node of some snapshot of the log. Subtrees can be efficiently shown to be consistent with the whole log.¶

Inclusion proof:

A sequence of hashes that efficiently proves some entry is contained in some checkpoint or subtree.¶

Consistency proof:

A sequence of hashes that efficiently proves a checkpoint or subtree is contained within another checkpoint.¶

Cosignature:

A signature from either the CA or other cosigner, over some checkpoint or subtree.¶

Landmark checkpoint:

One of an infrequent subset of checkpoints that can be used to predistribute trusted subtrees to relying parties for signatureless certificates.¶

Landmark subtree:

A subtree determined by a landmark checkpoint. Landmark subtrees are common points of reference between relying parties and signatureless certificates.¶

Full certificate:

A certificate containing an inclusion proof to some subtree, and several cosignatures over that subtree.¶

Signatureless certificate:

An optimized certificate containing an inclusion proof to a landmark subtree, and no signatures.¶

4.1. Definition of a Subtree

Given an ordered list of n inputs, D_n = {d[0], d[1], ..., d[n-1]}, Section 2.1.1 of [RFC9612] defines the Merkle Tree via the Merkle Tree Hash MTH(D_n).¶

A subtree of this Merkle Tree is defined by two integers, start and end, such that:¶

• 0 <= start < end <= n¶

• If k is the largest power of 2 that is greater than or equal to end - start, start must be a multiple of k¶

Note that, if start is zero, the second condition is always true.¶

A subtree is itself a Merkle Tree, defined by MTH(D[start:end]). In the context of a single Merkle Tree, the subtree defined by start and end is denoted by half-open interval [start, end). It contains the entries whose indices are in that half-open interval.¶

The size of the subtree is end - start. If the subtree's size is a power of 2, it is said to be full, otherwise it is said to be partial.¶

If a subtree is full, then it is directly contained in the tree of hash operations in MTH(D_n) for n >= end.¶

If a subtree is partial, it is directly contained in MTH(D_n) only if n = end.¶

4.2. Subtree Inclusion Proofs

Subtrees are Merkle Trees, so entries can be proven to be contained in the subtree. A subtree inclusion proof for entry index of the subtree [start, end). is a Merkle inclusion proof, as defined in Section 2.1.3.1 of [RFC9162], where m is index - start and the tree inputs are D[start:end]. A subtree inclusion proof can be verified with the procedure in Section 2.1.3.2 of [RFC9162], where leaf_index is index - start and tree_size is end - start.¶

4.3. Subtree Consistency Proofs

A subtree [start, end) can be efficiently proven to be consistent with the full Merkle Tree. That is, given MTH(D[start:end]) and MTH(D_n), the proof demonstrates that the input D[start:end] to the subtree hash was equal to the corresponding elements of the input D_n to the Merkle Tree hash.¶

SUBTREE_PROOF(start, end, D_n) =
    SUBTREE_SUBPROOF(start, end, D_n, true)

SUBTREE_SUBPROOF(0, n, D_n, true) = {}
SUBTREE_SUBPROOF(0, n, D_n, false) = {MTH(D_n)}

SUBTREE_PROOF(0, end, D_n) = PROOF(end, D_n)

SUBTREE_PROOF(start, start + 1, D_n) = PATH(start, D_n)

4.4. Arbitrary Intervals

Not all [start, end) intervals of a Merkle tree are valid subtrees. This section describes how, for any start < end, to determine up to two subtrees that efficiently cover the interval. The subtrees are determined by the following Python procedure:¶

def find_subtrees(start, end):
    """ Returns a list of one or two subtrees that efficiently
    cover [start, end). """
    assert start < end
    if end - start < 2:
        return [(start, end),]
    last = end - 1
    # Find where start and last's tree paths diverge. The two
    # subtrees will be on either side of the split.
    split = (start ^ last).bit_length() - 1
    mask = (1 << split) - 1
    mid = last & ~mask
    # Maximize the left endpoint. This is just before start's
    # path leaves the right edge of its new subtree.
    left_split = (~start & mask).bit_length()
    left = start & ~((1 << left_split) - 1)
    return [(left, mid), (mid, end)]

[[TODO: Write this up in prose too.]]¶

When the procedure returns a single subtree, the subtree is [start, end). When it returns two subtrees, left and right, the subtrees satisfy the following properties:¶

1. left.end = right.start. That is, the two subtrees cover adjacent intervals.¶

2. left.start <= start and end = right.end. That is, the two subtrees together cover the entire target interval, possibly with some extra entries before start left, but not after end.¶

3. left.end - left.start < 2 * (end - start) and right.end - right.start <= end - start. That is, the two subtrees efficiently cover the interval.¶

4. left is full, while right may be partial.¶

Figure 1 shows the subtrees which cover [5, 13) in a Merkle Tree of 13 elements. The two subtrees selected are [4, 8) and [8, 13). Note that the subtrees cover a slightly larger interval than [5, 13).¶

Two subtrees are needed because a single subtree may not be able to efficiently cover an interval. Figure 2 shows the smallest subtree that contains [7, 9) in a 9-element tree. The smallest single subtree that contains the interval is [0, 9) but this is the entire tree. Using two subtrees, the interval can be described by [7, 8) and [8, 9).¶

5.1. Log Parameters

An issuance log has the following parameters:¶

• A log ID, which uniquely identifies the log. See Section 5.2.¶

• A collision-resistant cryptographic hash function. SHA-256 [SHS] is RECOMMENDED.¶

• A minimum index, which is the index of the first log entry which is available. See Section 5.6.1. This value changes over the lifetime of the log.¶

Throughout this document, the hash algorithm in use is referred to as HASH, and the size of its output in bytes is referred to as HASH_SIZE.¶

5.2. Log IDs

Each issuance log is identified by a log ID, which is a trust anchor ID [I-D.ietf-tls-trust-anchor-ids].¶

An issuance log's log ID determines an X.509 distinguished name (Section 4.1.2.4 of [RFC5280]). The distinguished name has a single relative distinguished name, which has a single attribute. The attribute has type id-rdna-trustAnchorID, defined below:¶

id-rdna-trustAnchorID OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 TBD1 TBD2}

[[TODO: Fill in TBD1 from the PKIX rdna arc in [I-D.draft-ietf-lamps-x509-alg-none], once allocated.]]¶

The attribute's value is a RELATIVE-OID containing the trust anchor ID's ASN.1 representation. For example, the distinguished name for a log named 32473.1 would be represented in syntax of [RFC4514] as:¶

1.3.6.1.5.5.7.TBD1.TBD2=#0d0481fd5901

For initial experimentation, early implementations of this design will use the OID 1.3.6.1.4.1.44363.47.1 instead of id-rdna-trustAnchorID.¶

5.3. Log Entries

Each entry in the log is a MerkleTreeCertEntry, defined with the TLS presentation syntax below. A MerkleTreeCertEntry describes certificate information that the CA has validated and certified.¶

struct {} Empty;

enum {
    null_entry(0), tbs_cert_entry(1), (2^16-1)
} MerkleTreeCertEntryType;

struct {
    MerkleTreeCertEntryType type;
    select (type) {
       case null_entry: Empty;
       case tbs_cert_entry: opaque tbs_cert_entry_data[N];
       /* May be extended with future types. */
    }
} MerkleTreeCertEntry;

When type is tbs_cert_entry, N is the number of bytes needed to consume the rest of the input. A MerkleTreeCertEntry is expected to be decoded in contexts where the total length of the entry is known.¶

tbs_cert_entry_data contains the DER [X.690] encoding of a TBSCertificateLogEntry, defined below:¶

TBSCertificateLogEntry  ::=  SEQUENCE  {
      version             [0]  EXPLICIT Version DEFAULT v1,
      issuer                   Name,
      validity                 Validity,
      subject                  Name,
      subjectPublicKeyInfoHash OCTET STRING,
      issuerUniqueID      [1]  IMPLICIT UniqueIdentifier OPTIONAL,
      subjectUniqueID     [2]  IMPLICIT UniqueIdentifier OPTIONAL,
      extensions          [3]  EXPLICIT Extensions OPTIONAL }

The version, issuer, validity, subject, issuerUniqueID, subjectUniqueID, and extensions fields have the corresponding semantics as in Section 4.1.2 of [RFC5280], with the exception of subjectPublicKeyInfoHash. subjectPublicKeyInfoHash contains the hash of subject's public key as a SubjectPublicKeyInfo (Section 4.1.2.7 of [RFC5280]). The hash uses the log's hash function (Section 5.1) and is computed over the SubjectPublicKeyInfo's DER [X.690] encoding. The issuer field MUST be the issuance log's log ID as an X.509 distinguished name, as described in Section 5.2.¶

When type is null_entry, the entry does not represent any information. The entry at index zero of every issuance log MUST be of type null_entry. Other entries MUST NOT use null_entry. null_entry exists to avoid zero serial numbers in the certificate format (Section 6.1).¶

MerkleTreeCertEntry is an extensible structure. Future documents may define new values for MerkleTreeCertEntryType, with corresponding semantics. See Section 5.5 and Section 12.5 for additional discussion.¶

5.4. Cosigners

This section defines a log cosigner. A cosigner is a class of role that follows some append-only view of the log and signs subtrees (Section 4) consistent with that view. The signatures generated by a cosigner are known as cosignatures. The cosigner is responsible for ensuring that all subtrees it signs are consistent with each other. The cosigner may be external to the log, in which case it might ensure consistency by checking consistency proofs as it updates its internal state. The cosigner may be operated together with the log, in which case it can trust its log state.¶

Different cosigners may perform different roles. When a cosigner signs a subtree, it can additionally make cosigner-specific assertions about the log state described by the subtree. This document defines one concrete cosigner role, a CA cosigner (Section 5.5), to authenticate the log and certify entries. Other documents and specific deployments may define other cosigner roles, to perform different functions in a PKI. For example, [TLOG-WITNESS] defines a cosigner that only checks the log is append-only, and [TLOG-MIRROR] defines a cosigner that mirrors a log.¶

Each cosigner has a public key and a cosigner ID, which uniquely identifies the cosigner. The cosigner ID is a trust anchor ID [I-D.ietf-tls-trust-anchor-ids]. By identifying the cosigner, the cosigner ID specifies both the public key and the role-specific assertions made by the cosigner's signatures. If a single operator performs multiple cosigner roles in an ecosystem, each role MUST use a distinct cosigner ID and SHOULD use a distinct key.¶

A single cosigner, with a single cosigner name and public key, MAY generate cosignatures for multiple logs. In this case, signed subtrees only need to be consistent with others for the same log.¶

opaque HashValue[HASH_SIZE];

/* From Section 4.1 of draft-ietf-tls-trust-anchor-ids */
opaque TrustAnchorID<1..2^8-1>;

struct {
    TrustAnchorID log_id;
    uint64 start;
    uint64 end;
    HashValue hash;
} MTCSubtree;

struct {
    uint8 label[16] = "mtc-subtree/v1\n\0";
    TrustAnchorID cosigner_id;
    MTCSubtree subtree;
} MTCSubtreeSignatureInput;

5.5. Certification Authority Cosigners

A CA cosigner is a cosigner (Section 5.4) that certifies the contents of a log.¶

When a CA cosigner signs a subtree, it provides the additional guarantee that it has certified the contents of each entry in the subtree. For example, a domain-validating CA would be held responsible for having performed domain validation for all such entries, at some time consistent with the validity dates in each entry.¶

Entries are extensible, so each entry type determines the semantics of what the CA is certifying:¶

• To certify an entry of type null_entry is a no-op. A CA MAY freely certify null_entry without being held responsible for any validation.¶

• To certify an entry of type tbs_cert_entry is to certify the TBSCertificateLogEntry, as defined in Section 5.3.¶

Future documents MAY define type values and what it means to certify them. A CA MUST NOT sign a subtree if it contains an entry with type that it does not recognize. Doing so would certify that the CA has validated the information in some not-yet-defined entry format. Section 12.5 further discusses security implications of new formats.¶

A CA operator MAY operate multiple CA cosigners that all certify the same log in parallel. This may be useful when, e.g., rotating CA keys. In this case, each CA instance MUST have a distinct name. The CA operator's ACME server can return all CA cosignatures together in a single certificate, with TLS negotiation sending the right ones to each client.¶

If the CA operator additionally operates a traditional X.509 CA, that CA key MUST be distinct from any Merkle Tree CA cosigner keys.¶

5.6. Publishing Logs

[[NOTE: This section is written to avoid depending on a specific serving protocol. The current expectation is that a Web PKI deployment would derive from [TLOG-TILES], to match the direction of Certificate Transparency and pick up improvements made there.¶

For now, we avoid a normative reference on [TLOG-TILES] and also capture the fact that the certificate construction is independent of the choice of protocol. Similar to how the CT ecosystem is migrating to a tiled interface, were someone to improve on [TLOG-TILES], a PKI could migrate to that new protocol without impacting certificate verification.¶

That said, this is purely a starting point for describing the design. We expect the scope of this document, and other related documents to adapt as the work evolves across the IETF, C2SP, Certificate Transparency, and other communities.]]¶

Issuance logs are intended to be publicly accessible in some form, to allow monitors to detect misissued certificates.¶

The access method does not affect certificate interoperability, so this document does not prescribe a specific protocol. An individual issuance log MAY be published in any form, provided other parties in the PKI are able to consume it. Relying parties SHOULD define log serving requirements, including the allowed protocols and expected availability, as part of their policies on which CAs to support. See also Section 10.3.¶

For example, a log ecosystem could use [TLOG-TILES] to serve logs. [TLOG-TILES] improves on [RFC6962] and [RFC9162] by exposing the log as a collection of cacheable, immutable "tiles". This works well with a variety of common HTTP [RFC9110] serving architectures. It also allows log clients to request arbitrary tree nodes, so log clients can fetch the structures described in Section 4.¶

6.1. Certificate Format

The information is encoded in an X.509 Certificate [RFC5280] as follows:¶

The TBSCertificate's version, issuer, validity, subject, issuerUniqueID, subjectUniqueID, and extensions MUST match the corresponding fields of the TBSCertificateLogEntry. Per Section 5.3, this means issuer MUST be the issuance log's log ID as an X.509 distinguished name, as described in Section 5.2.¶

The TBSCertificate's serialNumber MUST contain the zero-based index of the TBSCertificateLogEntry in the log. Section 4.1.2.2 of [RFC5280] forbids zero as a serial number, but Section 5.3 defines a null_entry type for use in entry zero, so the index will be positive. This encoding is intended to avoid implementation errors by having the serial numbers and indices off by one.¶

The TBSCertificate's subjectPublicKeyInfo contains the specified public key. Its hash MUST match the TBSCertificateLogEntry's subjectPublicKeyInfoHash.¶

The TBSCertificate's signature and the Certificate's signatureAlgorithm MUST contain an AlgorithmIdentifier whose algorithm is id-alg-mtcProof, defined below, and whose parameters is omitted.¶

id-alg-mtcProof OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 TBD}

For initial experimentation, early implementations of this design will use the OID 1.3.6.1.4.1.44363.47.0 instead of id-alg-mtcProof.¶

The signatureValue contains an MTCProof structure, defined below using the TLS presentation language (Section 3 of [RFC8446]):¶

opaque HashValue[HASH_SIZE];

struct {
    TrustAnchorID cosigner_id;
    opaque signature<0..2^16-1>;
} MTCSignature;

struct {
    uint64 start;
    uint64 end;
    HashValue inclusion_proof<0..2^16-1>;
    MTCSignature signatures<0..2^16-1>;
} MTCProof;

start and end MUST contain the corresponding parameters of the chosen subtree. inclusion_proof MUST contain a subtree inclusion proof (Section 4.2) for the log entry and the subtree. signatures contains the chosen subtree signatures. In each signature, cosigner_id contains the cosigner ID (Section 5.4) in its binary representation (Section 3 of [I-D.ietf-tls-trust-anchor-ids]), and signature contains the signature value as described in Section 5.4.1.¶

The MTCProof is encoded into the signatureValue with no additional ASN.1 wrapping. The most significant bit of the first octet of the signature value SHALL become the first bit of the bit string, and so on through the least significant bit of the last octet of the signature value, which SHALL become the last bit of the bit string.¶

6.2. Full Certificates

A full certificate is a Merkle Tree certificate which contains sufficient signatures to allow a relying party to trust the choice of subtree, without any predistributed information beyond the cosigner(s) parameters. Full certificates can be issued without significant processing delay.¶

When issuing a certificate, the CA first adds the TBSCertificateLogEntry to its issuance log. It then schedules a job to construct a checkpoint and collect cosignatures. The job proceeds as follows:¶

1. The CA signs the checkpoint with its key(s) (Section 5.5).¶

2. Using the procedure in Section 4.4, the CA determines the two subtrees that cover the entries added between this checkpoint and the most recent checkpoint.¶

3. The CA signs each subtree with its key(s) (Section 5.4).¶

4. The CA requests sufficient checkpoint cosignatures (Section 5.4) from external cosigners to meet relying party requirements (Section 7.3).¶

5. The CA requests subtree cosignatures (Appendix B.3) from the cosigners above.¶

6. For each certificate in the interval, the CA constructs certificates (Section 6.1) using the covering subtree.¶

Steps 4 and 5 are analogous to requesting SCTs from CT logs in Certificate Transparency, except that a single run of this job collects signatures for many certificates at once. The CA MAY request signatures from a redundant set of cosigners and select the ones that complete first.¶

This document does not prescribe the specific cosigner roles, or a particular protocol for requesting cosignatures. Protocols for cosigners MAY vary depending on the needs for that cosigner. A consistency-only cosigner, such as [TLOG-WITNESS], might only require a checkpoint signature and consistency proof, while a mirroring cosigner, such as [TLOG-MIRROR] might require the full log contents.¶

A cosigner MAY expose a private interface for the CA, to reduce denial-of-service risk, or a cosigner MAY expose a public interface for other parties to request additional cosignatures. The latter may be useful if a relying party requires a cosigner that the CA does not communicate with. In this case, an authenticating party MAY request cosignatures and add them to the certificate. However, it is RECOMMENDED that the CA collect cosignatures for the authenticating party. This simplifies deployment, as relying party policies change over time.¶

This document does not place any requirements on how frequently this job runs. More frequent runs results in lower issuance delay, but higher signing overhead. It is RECOMMENDED that CAs run at most one instance of this job at a time, starting the next instance after the previous one completes. A single run collects signatures for all entries since the most recent checkpoint, so there is little benefit to overlapping them. Less frequent runs may also aid relying parties that wish to directly audit signatures, as described in Section 5.2 of [AuditingRevisited], though this document does not define such a system.¶

6.3. Signatureless Certificates

A signatureless certificate is a Merkle Tree certificate which contains no signatures and instead assumes the relying party had predistributed information about which subtrees were trusted. Signatureless certificates are an optional size optimization. They require a processing delay to construct, and only work in a sufficiently up-to-date relying party. Authenticating parties thus SHOULD deploy a corresponding full certificate alongside any signatureless certificate, and use some application-protocol-specific mechanism to select between the two. Section 8 discusses such a mechanism for TLS [RFC8446].¶

6.4. Size Estimates

The inclusion proofs in full and signatureless certificates scale logarithmically with the size of the subtree. These sizes can be estimated with the CA's issuance rate. The byte counts below assume the issuance log's hash function is SHA-256.¶

Some organizations have published statistics which can be used to estimate this rate for the Web PKI. As of June 9th, 2025:¶

• [LetsEncrypt] reported around 558,000,000 active certificates for a single CA¶

• [MerkleTown] reported around 2,100,000,000 unexpired certificates in CT logs, across all CAs¶

• [MerkleTown] reported an issuance rate of around 444,000 certificates per hour, across all CAs¶

The current issuance rate across the Web PKI may not necessarily be representative of the Web PKI after a transition to short-lived certificates. Assuming a certificate lifetime of 7 days, and that subscribers will update their certificates 75% of the way through their lifetime (see Section 10.4), every certificate will be reissued every 126 hours. This gives issuance rate estimates of around 4,400,000 certificates per hour and 17,000,000 certificates per hour, for the first two values above. Note the larger estimate is across all CAs, while subtrees would only span one CA.¶

Using the per-CA short lifetime estimate, if the CA mints a checkpoint every 2 seconds, full certificate subtrees will span around 2,500 certificates, leading to 12 hashes in the inclusion proof, or 384 bytes. Full certificates additionally must carry a sufficient set of signatures to meet relying party requirements.¶

If a new landmark checkpoint is allocated every hour, signatureless certificate sutrees will span around 4,400,000 certificates, leading to 23 hashes in the inclusion proof, giving an inclusion proof size of 736 bytes, with no signatures. This is significantly smaller than a single ML-DSA-44 signature, 2,420 bytes, and almost ten times smaller than the three ML-DSA-44 signatures necessary to include post-quantum SCTs.¶

The proof sizes grow logarithmically, so 32 hashes, or 1024 bytes, is sufficient for subtrees of up to 2^32 (4,294,967,296) certificates.¶

7.1. Trust Anchors

In order to accept certificates from a Merkle Tree CA, a relying party MUST be configured with:¶

• The log ID (Section 5.2)¶

• A set of supported cosigners, as pairs of cosigner ID and public key¶

• A policy on which combinations of cosigners to accept in a certificate (Section 7.3)¶

• An optional list of trusted subtrees that are known to be consistent with the relying party's cosigner requirements (Section 7.4)¶

• A list of revoked ranges of indices (Section 7.5)¶

[[TODO: Define some representation for this. In a trust anchor, there's a lot of room for flexibility in what the client stores. In principle, we could even encode some of this information in an X.509 intermediate certificate, if an application wishes to use this with a delegation model with intermediates, though the security story becomes more complex. Decide how/whether to do that.]]¶

7.2. Verifying Certificate Signatures

When verifying the signature on an X.509 certificate (Step (a)(1) of Section 6.1.3 of [RFC5280]) whose issuer is a Merkle Tree CA, the relying party performs the following procedure:¶

1. Let index be the certificate's serial number. Check that start <= index < end, and that [start, end) describes a subtree per Section 4.1. If either check fails, abort this process and fail verification.¶

2. If index is contained in one of the relying party's revoked ranges (Section 7.5), abort this process and fail verification.¶

3. Construct a TBSCertificateLogEntry as follows:¶

   1. Copy the version, issuer, validity, subject, issuerUniqueID, subjectUniqueID, and extensions fields from the TBSCertificate.¶

   2. Set subjectPublicKeyInfoHash to the hash of the DER encoding of subjectPublicKeyInfo.¶

4. Construct a MerkleTreeCertEntry of type tbs_cert_entry with contents the TBSCertificateLogEntry.¶

5. Evaluate inclusion_proof against the MerkleTreeCertEntry to compute the expected subtree hash¶

6. If the subtree is a trusted subtree (Section 7.4), check that the hash matches. Return success if it matches and failure if it does not.¶

7. Otherwise, check that signatures contain a sufficient set of valid signatures from cosigners to satisfy the relying party's cosigner requirements (Section 7.3). Unrecognized cosigners MUST be ignored. Signatures are verified as described in Section 5.4.1.¶

This procedure only replaces the signature verification portion of X.509 path validation. The relying party MUST continue to perform other checks, such as checking expiry.¶

7.3. Trusted Cosigners

A relying party's cosigner policy determines the sets of cosigners that must sign a view of the issuance log before it is trusted.¶

This document does not prescribe a particular policy, but gives general guidance. Relying parties MAY implement policies other than those described below, and MAY incorporate cosigners acting in roles not described in this document.¶

In picking trusted cosigners, relying party SHOULD ensure the following security properties:¶

Authenticity:

The relying party only accepts entries certified by the CA¶

Transparency:

The relying party only accepts entries that are publicly accessible, so that monitors, particularly the subject of the certificate, can notice any unauthorized certificates¶

Relying parties SHOULD ensure authenticity by requiring a signature from the most recent CA cosigner key. If the CA is transitioning from an old to new key, the relying party SHOULD accept both until certificates that predate the new key expire. This is analogous to the signature in a traditional X.509 certificate.¶

While a CA signature is sufficient to prove a subtree came from the CA, this is not enough to ensure the certificate is visible to monitors. A misbehaving CA might not operate the log correctly, either presenting inconsistent versions of the log to relying parties and monitors, or refuse to publish some entries.¶

To mitigate this, relying parties SHOULD ensure transparency by requiring a quorum of signatures from additional cosigners. At minimum, these cosigners SHOULD enforce a consistent view of the log. For example, [TLOG-WITNESS] describes a lightweight "witness" cosigner role that checks this with consistency proofs. This is not sufficient to ensure durable logging. Section 7.5 discusses mitigations for this. Alternatively, a relying party MAY require cosigners that serve a copy of the log, in addition to enforcing a consistent view. For example, [TLOG-MIRROR] describes a "mirror" cosigner role.¶

Relying parties MAY accept the same set of additional cosigners across issuance logs.¶

Cosigner roles are extensible without changes to certificate verification itself. Future specifications and individual deployments MAY define other cosigner roles to incorporate into relying party policies.¶

Section 10.2 discusses additional deployment considerations in cosigner selection.¶

7.4. Trusted Subtrees

As an optional optimization, a relying party MAY incorporate a periodically updated, predistributed list of active landmark subtrees, determined as described in Section 6.3.1. The relying party configures these as trusted subtrees, allowing it to accept signatureless certificates (Section 6.3) constructed against those subtrees.¶

Before configuring the subtrees as trusted, the relying party MUST obtain assurance that each subtree is consistent with checkpoints observed by a sufficient set of cosigners (see Section 5.4) to meet its cosigner requirements. It is not necessary that the cosigners have generated signatures over the specific subtrees, only that they are consistent.¶

This criteria can be checked given:¶

• Some reference checkpoint that contains the latest landmark checkpoint¶

• For each cosigner, either:¶

  • A cosignature on the reference checkpoint¶

  • A cosigned checkpoint containing the referenced checkpoint and a valid Merkle consistency proof (Section 2.1.4 of [RFC9162]) between the two¶

• For each subtree, a valid subtree consistency proof (Section 4.3) between the subtree and the reference checkpoint¶

[[TODO: The subtree consistency proofs have many nodes in common. It is possible to define a single "bulk consistency proof" that verifies all the hashes at once, but it's a lot more complex.]]¶

This document does not prescribe how relying parties obtain this information. A relying party MAY, for example, use an application-specific update service, such as the services described in [CHROMIUM] and [FIREFOX]. If the relying party considers the service sufficiently trusted (e.g. if the service provides the trust anchor list or certificate validation software), it MAY trust the update service to perform these checks.¶

The relying party SHOULD incorporate its trusted subtree configuration in application-protocol-specific certificate selection mechanisms, to allow an authenticating party to select a signatureless certificate. The trust anchor IDs of the landmark checkpoints may be used as efficient identifiers in the application protocol. Section 8 discusses how to do this in TLS [RFC8446].¶

7.5. Revocation by Index

For each supported Merkle Tree CA, the relying party maintains a list of revoked ranges of indices. This allows a relying party to efficiently revoke entries of an issuance log, even if the contents are not necessarily known. This may be used to mitigate the security consequences of misbehavior by a CA, or other parties in the ecosystem.¶

When a relying party is first configured to trust a CA, it SHOULD be configured to revoke all entries from zero up to but not including the first available unexpired certificate at the time. This revocation SHOULD be periodically updated as entries expire and logs are pruned (Section 5.6.1). In particular, when CAs prune entries, relying parties SHOULD be updated to revoke all newly unavailable entries. This gives assurance that, even if some unavailable entry had not yet expired, the relying party will not trust it. It also allows monitors to start monitoring a log without processing expired entries.¶

A misbehaving CA might correctly construct a globally consistent log, but refuse to make some entries or intermediate nodes available. Consistency proofs between checkpoints and subtrees would pass, but monitors cannot observe the entries themselves. Relying parties whose cosigner policies (Section 7.3) do not require durable logging (e.g. via [TLOG-MIRROR]) are particularly vulnerable to this. In this case, the indices of the missing entries will still be known, so relying parties can use this mechanism to revoke the unknown entries, possibly as an initial, targeted mitigation before a complete CA removal.¶

When a CA is found to be untrustworthy, relying parties SHOULD remove trust in that CA. To minimize the compatibility impact of this mitigation, index-based revocation can be used to only distrust entries after some index, while leaving existing entries accepted. This is analogous to the [SCTNotAfter] mechanism used in some PKIs.¶

10.1. Operational Costs

While Merkle Tree certificates expects CAs to operate logs, the costs of these logs are expected to be much lower than a CT log from [RFC6962] or [RFC9162]:¶

Section 5.6 does not constrain the API to the one defined in [RFC6962] or [RFC9162]. If the PKI uses a tile-based protocol, such as [TLOG-TILES], the issuance log benefits from the improved caching properties of such designs.¶

Unlike a CT log, an issuance log does not have public submission APIs. Log entries are only added by the CA directly. The costs are thus expected to scale with the CA's own operations.¶

A CA only needs to produce a digital signature for every checkpoint, rather than for every certificate. The lower signature rate requirements could allow more secure and/or economical key storage choices.¶

Individual entries are kept small and do not scale with public key or signature sizes. This mitigates growth from post-quantum algorithms. Public keys in entries are replaced with fixed-sized hashes. There are no signatures in entries themselves, and only signatures on the very latest checkpoint are retained. Every new checkpoint completely subsumes the old checkpoint, so there is no need to retain older signatures. Likewise, a subtree is only signed if contained in another signed checkpoint.¶

Log pruning (Section 5.6.1) allows a long-lived log to serve only the more recent entries, scaling with the size of the retention window, rather than the log's total lifetime.¶

Mirrors of the log can also reduce CA bandwidth costs, because monitors can fetch data from mirrors instead of CAs directly. In PKIs that deploy mirrors as part of cosigner policies, relying parties could set few availability requirements on CAs, as described in Section 10.3.¶

The costs of cosigners vary by cosigner role. A consistency-checking cosigner, such as [TLOG-WITNESS], requires very little state and can be run with low cost.¶

A mirroring cosigner, such as [TLOG-MIRROR], performs comparable roles as CT logs, but several of the above cost-saving properties also apply: improved protocols, smaller entries, less frequent signatures, and log pruning. While a mirror does need to accommodate another party's (the CA's) growth rate, it grows only from new issuances from that one CA. If one CA's issuance rate exceeds the mirror's capacity, that does not impact the mirror's copies of other CAs. Mirrors also do not need to defend against a client uploading a large number of existing certificates all at once. Submissions are also naturally batched and serialized.¶

10.2. Choosing Cosigners

In selecting trusted cosigners and cosigner requirements (Section 7.3), relying parties navigate a number of trade-offs:¶

A consistency-checking cosigner, such as [TLOG-WITNESS], is very cheap to run, but does not guarantee durable logging, while a mirroring cosigner is more expensive and may take longer to cosign structures. Requiring a mirror signature provides stronger guarantees to the relying party, which in turn can reduce the requirements on CAs (see Section 10.3), however it may cause certificate issuance to take longer. That said, mirrors are comparable to CT logs, if not cheaper (see Section 10.1), so they may be appropriate in PKIs where running CT logs is already viable.¶

Relying parties that require larger quorums of trusted cosigners can reduce the trust placed in any individual cosigner. However, these larger quorums result in larger, more expensive full certificates. The cost of this will depend on how frequently the signatureless optimization occurs in a given PKI. Conversely, relying parties that require smaller quorums have smaller full certificates, but place more trust in their cosigners.¶

Relying party policies also impact monitor operation. If a relying party accepts any one of three cosigners, monitors SHOULD check the checkpoints of all three. Otherwise, a malicious CA may send different split views to different cosigners. More generally, monitors SHOULD check the checkpoints in the union of all cosigners trusted by all supported relying parties. This is an efficient check because, if the CA is operating correctly, all cosigners will observe the same tree. Thus the monitor only needs to check consistency proofs between the checkpoints, and check the log contents themselves once. Monitors MAY also rely on other parties in the transparency ecosystem to perform this check.¶

10.3. Log Availability

CAs and mirrors are expected to serve their log contents over HTTP. It is possible for the contents to be unavailable, either due to temporary service outage or because the log has been pruned (Section 5.6.1). If some resources are unavailable, they may not be visible to monitors.¶

As in CT, PKIs which deploy Merkle Tree certificates SHOULD establish availability policies, adhered to by trusted CAs and mirrors, and enforced by relying party vendors as a condition of trust. Exact availability policies for these services are out of scope for this document, but this section provides some general guidance.¶

Availability policies SHOULD specify how long an entry must be made available, before a CA or mirror is permitted to prune the entry. It is RECOMMENDED to define this using a retention period, which is some time after the entry has expired. In such a policy, an entry could only be pruned if it, and all preceding entries, have already expired for the retention period. Policies MAY opt to set different retention periods between CAs and mirrors. Permitting limited log retention is analogous to the CT practice of temporal sharding [CHROME-CT], except that a pruned issuance log remains compatible with older, unupdated relying parties.¶

Such policies impact monitors. If the retention period is, e.g. 6 months, this means that monitors are expected to check entries of interest within 6 months. It also means that a new monitor may only be aware of a 6 month history of entries issued for a particular domain.¶

If historical data is not available to verify the retention period, such as information in another mirror or a trusted summary of expiration dates of entries, it may not be possible to confirm correct behavior. This is mitigated by the revocation process described in Section 7.5: if a CA were to prune a forward-dated entry and, in the 6 months when the entry was available, no monitor noticed the unusual expiry, an updated relying party would not accept it anyway.¶

The log pruning process simply makes some resources unavailable, so availability policies SHOULD constrain log pruning in the same way as general resource availability. That is, if it would be a policy violation for the log to fail to serve a resource, it should also be a policy violation for the log to prune such that the resource is removed, and vice versa.¶

PKIs that require mirror cosignatures (Section 7.3) can impose minimal to no availability requirements on CAs, all without compromising transparency goals. If a CA never makes some entry available, mirrors will be unable to update. This will prevent relying parties from accepting the undisclosed entries. However, a CA which is persistently unavailable may not offer sufficient benefit to be used by authenticating parties or trusted by relying parties.¶

However, if a mirror's interface becomes unavailable, monitors may be unable to check for unauthorized issuance, if the entries are not available in another mirror. This does compromise transparency goals. As such, availability policies SHOULD set availability expectations on mirrors. This can also be mitigated by using multiple mirrors, either directly enforced in cosigner requirements, or by keeping mirrors up-to-date with each other.¶

In PKIs that do not require mirroring cosigners, the CA's serving endpoint is more crucial for monitors. Such PKIs thus SHOULD set availability requirements on CAs.¶

In each of these cases, availability failures can be mitigated by revoking the unavailable entries by index, as described in Section 7.5, likely as a first step in a broader distrust.¶

10.4. Certificate Renewal

When an authenticating party requests a certificate, the signatureless certificate will not be available until the next landmark checkpoint is ready. From there, the signatureless certificate will not be available until relying parties receive new trusted subtrees.¶

To maximize coverage of the signatureless certificate optimization, authenticating parties performing routine renewal SHOULD request a new Merkle Tree certificate some time before the previous Merkle Tree certificate expires. Renewing around 75% into the previous certificate's lifetime is RECOMMENDED. Authenticating parties additionally SHOULD retain both the new and old certificates in the certificate set until the old certificate expires. As the new subtrees are delivered to relying parties, certificate negotiation will transition relying parties to the new certificate, while retaining the old certificate for relying parties that are not yet updated.¶

The above also applies if the authenticating party is performing a routine key rotation alongside the routine renewal. In this case, certificate negotiation would pick the key as part of the certificate selection. This slightly increases the lifetime of the old key but maintains the size optimization continuously.¶

If the service is rotating keys in response to a key compromise, this option is not appropriate. Instead, the service SHOULD immediately discard the old key and request a full certificate and the revocation of the previous certificate. This will interrupt the size optimization until the new signatureless certificate is available and relying parties are updated.¶

10.5. Multiple CA Keys

The separation between issuance logs and CA cosigners gives CAs additional flexibility in managing keys. A CA operator wishing to rotate keys, e.g. to guard against compromise of older key material, or upgrade to newer algorithms, could retain the same issuance log and sign its checkpoints and subtrees with both keys in parallel, until relying parties are all updated. Older relying parties would verify the older signatures, while newer relying parties would verify the newer signatures. A cosignature negotiation mechanism in the application protocol (see Section 8) would avoid using extra bandwidth for the two signatures.¶

12.1. Authenticity

A key security requirement of any PKI scheme is that relying parties only accept assertions that were certified by a trusted certification authority. Merkle Tree certificates achieve this by ensuring the relying party only accepts authentic subtree hashes:¶

• In full certificates, the relying party's cosigner requirements (Section 7.3) are expected to include some signature by the CA's cosigner. The CA's cosigner (Section 5.5) is defined to certify the contents of every checkpoint and subtree that it signs.¶

• In signatureless certificates, the cosigner requirements are checked ahead of time, when the trusted subtrees are predistributed (Section 7.4).¶

Given such a subtree hash, computed over entries that the CA certified, it then must be computationally infeasible to construct an entry not on this list, and some inclusion proof, such that inclusion proof verification succeeds. This requires using a collision-resistant hash in the Merkle Tree construction.¶

Log entries contain public key hashes, so it must additionally be computationally infeasible to compute a public key whose hash matches the entry, other than the intended public key. This also requires a collision-resistant hash.¶

12.2. Transparency

The transparency mechanisms in this document do not prevent a CA from issuing an unauthorized certificate. Rather, they provide comparable security properties as Certificate Transparency [RFC9162] in ensuring that all certificates are either rejected by relying parties, or visible to monitors and, in particular, the subject of the certificate.¶

Compared to Certificate Transparency, some of the responsibilities of a log have moved to the CA. All signatures generated by the CA in this system are assertions about some view of the CA's issuance log. However, a CA does not need to function correctly to ensure transparency properties. Relying parties are expected to require a quorum of additional cosigners, which together enforce properties of the log (Section 7.3) and prevent or detect CA misbehavior:¶

A CA might violate the append-only property of its log and present different views to different parties. However, each individual cosigner will only follow a single append-only view of the log history. Provided the cosigners are correctly operated, relying parties and monitors will observe consistent views between each other. Views that were not cosigned at all may not be detected, but they also will not be accepted by relying parties.¶

If the CA sends one view to some cosigners and another view to other cosigners, it is possible that multiple views will be accepted by relying parties. However, in that case monitors will observe that cosigners do not match each other. Relying parties can then react by revoking the inconsistent indices (Section 7.5), and likely removing the CA. If the cosigners are mirrors, the underlying entries in both views will also be visible.¶

A CA might correctly construct its log, but refuse to serve some unauthorized entry, e.g. by feigning an outage or pruning the log outside the retention policy (Section 10.3). If the relying party requires cosignatures from trusted mirrors, the entry will either be visible to monitors in the mirrors, or have never reached a mirror. In the latter case, the entry will not have been cosigned, so the relying party would not accept it. If the relying party accepts log views without a trusted mirror, the unauthorized entry may not be available. However, the existence of some entry at that index will be visible, so monitors will know the CA is failing to present an entry. Relying parties can then react by revoking the undisclosed entries by index (Section 7.5), and likely removing the CA.¶

12.3. Public Key Hashes

Unlike Certificate Transparency, the mechanisms in this document do not provide the subject public keys, only the hashed values. This is intended to reduce log serving costs, particularly with large post-quantum keys. As a result, monitors look for unrecognized hashes instead of unrecognized keys. Any unrecognized hash, even if the preimage is unknown, indicates an unauthorized certificate.¶

This optimization complicates studies of weak public keys, e.g. [SharedFactors]. Such studies will have to retrieve the public keys separately, such as by connecting to the TLS servers, or fetching from the CA if it retains the unhashed key. This document does not define a mechanism for doing this, or require that CAs or mirrors retain unhashed keys. The transparency mechanisms in this protocol are primarily intended to allow monitors to observe certificate issuance.¶

12.4. Non-Repudiation

When a monitor finds an unauthorized certificate issuance in a log or mirror, it must be possible to prove the CA indeed certified the information in the entry. However, only the latest checkpoint signature is retained by the transparency ecosystem, so it may not be possible to reconstruct the exact certificate seen by relying parties.¶

However, per Section 5.5, any checkpoint signature is a binding assertion by the CA that it has certified every entry in the checkpoint. Thus, given any signed checkpoint that contains the unauthorized entry, a Merkle inclusion proof (Section 2.1.3 of [RFC9162]) is sufficient to prove the CA issued the entry. This is analogous to how, in Section 3.2.1 of [RFC9162], CAs are held accountable for signed CT precertificates.¶

The transparency ecosystem does not retain unhashed public keys, so it also may not be possible to construct a complete certificate from the checkpoint signature and inclusion proof. However, if the log entry's subjectPublicKeyInfoHash does not correspond to an authorized key for the subject of the certificate, the entry is still unauthorized. A Merkle Tree CA is held responsible for all log entries it certifies, whether or not the preimage of the hash is known.¶

12.5. New Log Entry Types

MerkleTreeCertEntry (Section 5.3) is extensible and permits protocol extensions to define new formats for the CA to certify. This means older CAs, cosigners, relying parties, and monitors might interact with new entries:¶

Section 5.3 and Section 5.5 forbid a CA from logging or signing entries that it does not recognize. A CA cannot faithfully claim to certify information if it does not understand it. This is analogous to how a correctly-operated X.509 can never sign an unrecognized X.509 extension.¶

External cosigners may or may not interact with the unrecognized entries. [TLOG-MIRROR] and [TLOG-WITNESS] describe cosigners whose roles do not interpret the contents of log entries. New entry types MAY be added without updating them. If a cosigner role does interpret a log entry, it MUST define how it interacts with unknown ones.¶

If a relying party trusts an issuance log, but the issuance log contains an unrecognized entry, the entry will not cause it to accept an unexpected certificate. In Section 7.2, the relying party constructs the MerkleTreeCertEntry that it expects. The unrecognized entry will have a different type value, so the proof will never succeed, assuming the underlying hash function remains collision-resistant.¶

If a monitor observes an entry with unknown type, it may not be able to determine if it is of interest. For example, it may be unable to tell whether it covers some relevant DNS name. Until the monitor is updated to reflect the current state of the PKI, the monitor may be unable to detect all misissued certificates.¶

This situation is analogous to the addition of a new X.509 extension. When relying parties add support for log entry types or new X.509 extensions, they SHOULD coordinate with monitors to ensure the transparency ecosystem is able to monitor the new formats.¶

14.1. Normative References

[FIPS186-5]

"Digital Signature Standard (DSS)", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.186-5, February 2023, <https://doi.org/10.6028/nist.fips.186-5>.

[FIPS204]

"Module-lattice-based digital signature standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.204, August 2024, <https://doi.org/10.6028/nist.fips.204>.

[I-D.draft-ietf-lamps-x509-alg-none]

Benjamin, D., "Unsigned X.509 Certificates", Work in Progress, Internet-Draft, draft-ietf-lamps-x509-alg-none-07, 11 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-x509-alg-none-07>.

[I-D.ietf-tls-trust-anchor-ids]

Beck, R., Benjamin, D., O'Brien, D., and K. Nekritz, "TLS Trust Anchor Identifiers", Work in Progress, Internet-Draft, draft-ietf-tls-trust-anchor-ids-01, 14 May 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-trust-anchor-ids-01>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3629]

Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/rfc/rfc3629>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/rfc/rfc8555>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[RFC9612]

Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, "Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs)", RFC 9612, DOI 10.17487/RFC9612, July 2024, <https://www.rfc-editor.org/rfc/rfc9612>.

[SHS]

"Secure hash standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.180-4, 2015, <https://doi.org/10.6028/nist.fips.180-4>.

[X.690]

ITU-T, "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8824-1:2021 , February 2021.

14.2. Informative References

[APPLE-CT]

Apple, "Apple's Certificate Transparency policy", 5 March 2021, <https://support.apple.com/en-us/HT205280>.

[AuditingRevisited]

Heimberger, L., Patton, C., and B. Westerbaan, "Private SCT Auditing, Revisited", 25 April 2025, <https://eprint.iacr.org/2025/556.pdf>.

[CABF-153]

CA/Browser Forum, "Ballot 153 – Short-Lived Certificates", 11 November 2015, <https://cabforum.org/2015/11/11/ballot-153-short-lived-certificates/>.

[CABF-SC081]

CA/Browser Forum, "Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods", 11 April 2025, <https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/>.

[CHROME-CT]

Google Chrome, "Chrome Certificate Transparency Policy", 17 March 2022, <https://googlechrome.github.io/CertificateTransparency/ct_policy.html>.

[CHROMIUM]

Chromium, "Component Updater", 3 March 2022, <https://chromium.googlesource.com/chromium/src/+/main/components/component_updater/README.md>.

[FIREFOX]

Mozilla, "Firefox Remote Settings", 20 August 2022, <https://wiki.mozilla.org/Firefox/RemoteSettings>.

[LetsEncrypt]

Let's Encrypt, "Let's Encrypt Stats", 7 March 2023, <https://letsencrypt.org/stats/>.

[MerkleTown]

Cloudflare, Inc., "Merkle Town", 7 March 2023, <https://ct.cloudflare.com/>.

[RFC4514]

Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, June 2006, <https://www.rfc-editor.org/rfc/rfc4514>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[SCTNotAfter]

Adrian, D., "How to distrust a CA without any certificate errors", March 2025, <https://dadrian.io/blog/posts/sct-not-after/>.

[SharedFactors]

Våge, H. F. and University of Bergen, "Finding shared RSA factors in the Certificate Transparency logs", 13 May 2022, <https://bora.uib.no/bora-xmlui/bitstream/handle/11250/3001128/Masters_thesis__for_University_of_Bergen.pdf>.

[SIGNED-NOTE]

C2SP, "Note", April 2025, <https://c2sp.org/signed-note>.

[STH-Discipline]

Barnes, R., "STH Discipline & Security Considerations", 3 March 2017, <https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV56EchBIT9r4c/>.

[TLOG-CHECKPOINT]

C2SP, "Transparency Log Checkpoints", March 2024, <https://c2sp.org/tlog-checkpoint>.

[TLOG-MIRROR]

Benjamin, D., "Transparency Log Mirrors (DRAFT)", June 2025, <https://github.com/davidben/C2SP/blob/tlog-mirror/tlog-mirror.md>.

[TLOG-TILES]

C2SP, "Tiled Transparency Logs", June 2025, <https://c2sp.org/tlog-tiles>.

[TLOG-WITNESS]

C2SP, "Transparency Log Witness Protocol", June 2025, <https://c2sp.org/tlog-witness>.

B.1. Pruning a Tiled Transparency Log

https://github.com/C2SP/C2SP/pull/138 describes how to support pruning in tlogs but, as of writing, is not part of [TLOG-TILES] yet.¶

[TLOG-MIRROR] is also updated to add a minimum index parameter to each mirror and apply the above changes to its monitoring interface. The first step of the recommended update procedure in [TLOG-MIRROR] is updated to say, "Let mirror_size be the tree size of the mirror checkpoint, or the mirror's minimum index if the mirror has not copied the log yet."¶

A mirror MAY use the origin log's current minimum index to initialize its starting minimum index, but it is not required to reflect subsequent pruning. A mirror MAY initialize its minimum index to some higher value than the origin, if it does not intend to log some entries. It MAY initialize its minimum index to a lower value, if the pruned resources are available from some other source, e.g., another mirror.¶

B.2. Subtree Signed Note Format

A subtree, with signatures, can be represented as a signed note [SIGNED-NOTE]. Trust anchor IDs can be converted into log origins and cosigner names by concatenating the ASCII string oid/1.3.6.1.4.1. and the ASCII representation of the trust anchor ID. For example, the checkpoint origin for a log named 32473.1 would be oid/1.3.6.1.4.1.32473.1.¶

The note body is a sequence of the following lines, each terminated by a newline character (U+000A):¶

• The log origin¶

• Two space-separated, non-negative decimal integers, <start> <end>¶

• The subtree hash, as single hash encoded in base64¶

Each note signature has a key name of the cosigner name. The signature's key ID is computed using the reserved signature type in [SIGNED-NOTE], and a fixed string, as follows:¶

key ID = SHA-256(key name || 0x0A || 0xFF || "mtc-subtree/v1")[:4]

A subtree whose start is zero can also be represented as a checkpoint [TLOG-CHECKPOINT]. A corresponding subtree signature can be represented as a note signature using a key ID computed as follows:¶

key ID = SHA-256(key name || 0x0A || 0xFF || "mtc-checkpoint/v1")[:4]

The only difference between the two forms is the implicit transformation from the signed note text to the MTCSubtree structure.¶

B.3. Requesting Subtree Signatures

This section defines the sign-subtree cosigner HTTP endpoint for clients to obtain subtree signatures from non-CA cosigners, such as mirrors and witnesses. It may be used by the CA when assembling a certificate, or by an authenticating party to add a cosignature to a certificate that the CA did not themselves obtain.¶

The cosigner MAY expose this endpoint publicly to general authenticating parties, or privately to the CA. The latter is sufficient if the CA is known to automatically request cosignatures from this cosigner when constructing certificates. If private, authenticating the CA is out of scope for this document.¶

Clients call this endpoint as POST <prefix>/sign-subtree, where prefix is some URL prefix. For a mirror or witness, the URL prefix is the submission prefix. The client's request body MUST be a sequence of:¶

• The requested subtree as a signed note (Appendix B.2), with zero or more signatures. The endpoint MAY require signatures from the CA as a DoS mitigation, as described below.¶

• A blank line¶

• A checkpoint, signed by the requested cosigner. The checkpoint's tree size must be at least end.¶

• A blank line¶

• Zero or more subtree consistency proof (Section 4.3) lines. Each line MUST encode a single hash in base64 [RFC4648]. The client MUST NOT send more than 63 consistency proof lines.¶

Each line MUST terminate in a newline character (U+000A).¶

The cosigner performs the following steps:¶

1. Check that the checkpoint contains signatures from itself¶

2. Check that the subtree consistency proof proves consistency between the subtree hash and the checkpoint¶

3. If all checks pass, cosign the subtree, as described in Section 5.4¶

On success, the response body MUST be a sequence of one or more note signature lines [SIGNED-NOTE], each starting with an em dash character (U+2014) and ending with a newline character (U+000A). The signatures MUST be cosignatures from the cosigner key(s) on the subtree.¶

Instead of statelessly validating checkpoints by signature, the cosigner MAY statefully check the requested checkpoint against internal witness or mirror state. In this case, if the cosigner needs a newer checkpoint, it responds with a "409 Conflict" with its latest signed checkpoint. In this case, the subtree cosigning SHOULD remember and accept the last few signed checkpoints, to minimize conflicts.¶

If operating statefully, the subtree cosigner process only needs read access to the mirror or witness state and can freely operate on stale state without violating any invariants.¶

Mirrors MAY choose to check subtree hashes by querying their log state, instead of evaluating proofs.¶

Publicly-exposed subtree cosigning endpoints MAY mitigate DoS in a variety of techniques:¶

• Only cosigning recent subtrees, as old subtrees do not need to be co-signed¶

• Caching subtree signatures¶

• Requiring a CA signature on the subtree; CAs are only expected to sign two subtrees (Section 4.4) for each checkpoint¶

• Rate-limiting requests¶

Since draft-davidben-tls-merkle-tree-certs-00

• Simplify hashing by removing the internal padding to align with block size. #72¶

• Avoid the temptation of floating points. #66¶

• Require lifetime to be a multiple of batch_duration. #65¶

• Rename window to validity window. #21¶

• Split Assertion into Assertion and AbridgedAssertion. The latter is used in the Merkle Tree and HTTP interface. It replaces subject_info by a hash, to save space by not serving large post-quantum public keys. The original Assertion is used everywhere else, including BikeshedCertificate. #6¶

• Add proper context to every node in the Merkle tree. #32¶

• Clarify we use a single CertificateEntry. #11¶

• Clarify we use POSIX time. #1¶

• Elaborate on CA public key and signature format. #27¶

• Miscellaneous changes.¶

Since draft-davidben-tls-merkle-tree-certs-01

• Minor editorial changes¶

Since draft-davidben-tls-merkle-tree-certs-02

• Replace the negotiation mechanism with TLS Trust Anchor Identifiers.¶

Since draft-davidben-tls-merkle-tree-certs-03

• Switch terminology from "subscriber" to "authenticating party".¶

• Use <1..2^24-1> encoding for all certificate types in the CertificateEntry TLS message¶

• Clarify discussion and roles in transparency ecosystem¶

• Update references¶

Since draft-davidben-tls-merkle-tree-certs-04

Substantially reworked the design. The old design was essentially the landmark checkpoint and CA-built logs ideas, but targeting only the optimized and slow issuance path, and with a more bespoke tree structure:¶

In both draft-04 and draft-05, a CA looks like today’s CAs except that they run some software to publish what they issue and sign tree heads to certify certificates in bulk.¶

In draft-04, the CA software publishes certificates in a bunch of independent Merkle trees. This is very easy to do as a collection of highly cacheable, immutable static files because each tree is constructed independently, and never appended to after being built. In draft-05, the certificates are published in a single Merkle tree. The [TLOG-TILES] interface allows such trees to also use highly cacheable, immutable static files.¶

In draft-04, there only are hourly tree heads. Clients are provisioned with tree heads ahead of time so we can make small, inclusion-proof-only certificates. In draft-05, the ecosystem must coordinate on defining "landmark" checkpoints. Clients are provisioned with subtrees describing landmark checkpoints ahead of time so we can make small, inclusion-proof-only certificates.¶

In draft-04, each tree head is independent. In draft-05, each landmark checkpoint contains all the previous checkpoints.¶

In draft-04, the independent tree heads were easily prunable. In draft-05, we define how to prune a Merkle tree.¶

In draft-04, there is no fast issuance mode. In draft-05, frequent, non-landmark checkpoints can be combined with inclusion proofs and witness signatures for fast issuance. This is essentially an STH and inclusion proof in CT.¶