]> Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

Bundesdruckerei GmbH

Kommandantenstr. 18 Berlin 10969 Germany jan.klaussner@bdr.de

UK National Cyber Security Centre

United Kingdom luke.t2@ncsc.gov.uk

Nokia

kondtir@gmail.com

Security PKI, Logs, And Tree Signatures Merkle Tree Certificate Landmark Distribution Point PKI This document specifies a mechanism for a relying party to retrieve Merkle-tree subtree consistency proofs needed to validate a landmark-relative Merkle Tree Certificate (MTC). An X.509 certificate extension identifies one or more Landmark Distribution Points (LDPs). A relying party requests a proof set from an LDP and validates the proof chain against a trusted, signed target checkpoint. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the PKI, Logs, And Tree Signatures Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A landmark-relative Merkle Tree Certificate (MTC) carries an inclusion proof but omits signatures. It can be verified when the relying party has trusted the corresponding landmark subtree. A relying party that does not have the required subtree locally can obtain consistency proofs that connect it to a newer, trusted checkpoint. The MTC format and the subtree consistency proof algorithm are defined in . This document defines an X.509 extension for discovering Landmark Distribution Point (LDP) servers, a request format, a response format, and the validation procedure for proof sets returned by those servers. LDP responses are untrusted input: acceptance depends on successful proof verification and on the relying party's existing trust policy.

LDP mechanism use cases

Private PKI Deployment without Transparency Logs In large enterprise/private PKI settings, certificate transparency may not be a requirement. In these environments, an LDP can provide the landmark and proof-distribution function for an MTC deployment. It does not replace the MTC issuance log or any cosigner and monitoring requirements.

Distribution of landmarks If a relying party is not part of the browser-based web PKI ecosystem, and it is presented with a landmark-relative certificate, it will need a way to obtain the appropriate landmarks so it can verify the inclusion proof in the certificate. The LDP mechanism defined in this document gives a certificate issuer a way to indicate where those landmarks can be obtained.

Long-lived or intermittently connected devices The validity period of certificates may last for a long time. An LDP lets a verifier retrieve the landmark data it needs at validation time, without requiring that data to arrive with the certificate.

Cached Landmark distribution at scale Landmarks are reusable across verifications for many certificates, and the infrastructure that serves them may cache the landmarks. This makes distribution much more efficient.

Constrained certificate environments The LDP allows information to be stored separately from the certificate and retrieved at validation time using a simple lookup mechanism. This is useful when certificate size, handshake size, bandwidth or storage is constrained.

Operational resilience Specifying more than one LDP improves resilience during service disruptions. In summary, the Landmark Distribution Point (LDP) provides a mechanism for separating the distribution of landmarks from the certificates and proofs that depend upon them. This separation is particularly useful for large-scale PKI deployments, constrained environments, and long-lived devices that do not use certificate transparency. For example, a device may receive a certificate through one protocol while obtaining the corresponding landmark through a separately operated distribution service. Landmark Distribution Points therefore provide a common discovery and distribution mechanism without requiring the mechanism used to deliver certificates to also distribute the landmarks required to validate them.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document uses the TLS presentation language defined in . The structures in this document use the HashValue type and the hash function of the MTC issuance log, as defined in . The terms landmark, landmark subtree, relying party, checkpoint, and subtree consistency proof have the meanings given in .

Overview An MTC certificate's MTCProof contains start, end, and an inclusion proof. The pair [start, end) identifies the certificate's source subtree. If the relying party does not have this subtree in its trusted-subtree store, it obtains the LDP URI from the certificate's ldpBaseURIs extension and sends a request containing only st and ed, corresponding to start and end. Those values identify a source subtree and allow the relying party to compute its hash. The relying party can then request a proof set from an LDP. The proof set connects that source subtree through zero or more intermediate tree states to a target checkpoint that the relying party can authenticate under its normal MTC policy. The relying party MUST authenticate the target checkpoint using its normal MTC policy. Proofs and intermediate roots returned by the LDP do not establish trust by themselves. Each proof establishes subtree consistency with its stated target root; the final target root MUST match the authenticated checkpoint.

Landmark Distribution Point Extension The ldpBaseURIs extension is included in an MTC certificate by its issuer. It contains one or more base URIs at which the issuer makes LDP resources available. The relying party MUST process the extension as an X.509 certificate extension in accordance with . The extension MUST be non-critical. The extension is defined as follows: Each LandmarkDistributionPoint MUST be an absolute HTTPS URI, as defined by . A base URI MUST NOT contain a query component or fragment. Its path identifies the LDP resource to which the request parameters in are appended. A client MAY try the listed URIs in order until it obtains a valid response. A client MUST NOT accept a proof solely because it came from a URI in this extension.

LDP Request and Response

Request The relying party constructs an HTTP GET request to a LandmarkDistributionPoint URI. The request identifies the subtree represented by the certificate's MTCProof. It appends the following query parameters, encoded using the URI query syntax in :

• st: the start value from the certificate's MTCProof.
• ed: the end value from the certificate's MTCProof.

Each value MUST be encoded as an unsigned decimal integer in its shortest form (no leading zeroes, except for the value zero). Each parameter MUST appear exactly once. The endpoint MUST reject a request with a missing, duplicated, or malformed parameter. An example request URI is: For an MTCProof having start equal to 4096 and end equal to 4352, an example request URI is: The st and ed values MUST be copied from the MTCProof. The relying party MUST reject a request it constructs if the range is not a valid subtree as defined by . The relying party MUST NOT consider the returned checkpoint or requested subtree authenticated until all verification requirements in have succeeded.

Landmark Subtree Proof A LandmarkSubtreeProof proves that a source subtree is consistent with a larger target tree. It is defined using the TLS presentation language as follows: ; } LandmarkSubtreeProof; struct { LandmarkSubtreeProof proofs<1..2^16-1>; } LandmarkSubtreeProofSet; ]]> source_start and source_end identify the source subtree. source_root is its Merkle Tree hash. target_tree_size and target_root identify the target tree. consistency_proof is a subtree consistency proof as defined in Section 4.4 of . The first proof in a LandmarkSubtreeProofSet MUST identify the certificate subtree: its source_start and source_end MUST equal the MTCProof's start and end, and its source_root MUST equal the root reconstructed by evaluating the MTCProof inclusion proof. Each subsequent proof MUST use the preceding proof's target tree as its source. Its source_start MUST be zero, source_end MUST equal the preceding target_tree_size, and source_root MUST equal the preceding target_root. Each subsequent target_tree_size MUST be greater than the preceding target tree size. For every proof, source_start MUST be less than source_end, and source_end MUST be less than or equal to target_tree_size. Successful verification of each proof MUST demonstrate that all entries in the source subtree are included in the target tree with their original order and contents. The final proof's target tree size and root MUST match the checkpoint carried in the response.

Response Format A successful response MUST have HTTP status 200 and Content-Type application/octet-stream. The body contains exactly one LandmarkDistributionResponse, encoded using the TLS presentation language: ; opaque checkpoint<1..2^24-1>; LandmarkSubtreeProofSet proof_set; } LandmarkDistributionResponse; ]]> landmarks contains the UTF-8 active-landmark list defined in Section 6.4.3 of , including its required newline terminators. checkpoint contains an MTC checkpoint, including the cosignatures needed to authenticate its tree root under the relying party's MTC policy. It is encoded as specified below. The proof set MUST terminate at the tree size and root in that checkpoint. The response MUST NOT contain trailing data. The LDP server MUST return a proof set whose first proof matches the requested st and ed values. It MUST NOT return a set that does not verify. A server SHOULD return a 4xx status for a malformed request and MAY return a 5xx status if it cannot fulfill a valid request. A relying party MUST treat any non-success response as a failed retrieval and MUST NOT accept the certificate on the basis of an incomplete response.

Checkpoint Format The checkpoint carries a complete-tree hash and cosignatures over that tree. It is defined using the TLS presentation language: ; } LandmarkCheckpoint; ]]> Cosignature is defined in Section 6.2 of . Each signature is computed over the MTC CosignedSubtree structure defined in Section 5.3.1 of that document, with start set to zero, end set to tree_size, subtree_hash set to root_hash, and timestamp set to the value in LandmarkCheckpoint. log_origin MUST identify the MTC issuance tree containing the certificate. The checkpoint timestamp MUST be nonzero, and all signatures in this structure MUST use that timestamp. The relying party MUST verify the checkpoint signatures against its configured MTC cosigner policy. The checkpoint timestamp MUST be acceptable under local freshness policy.

Verifier Procedure A relying party validating an MTC certificate with no locally trusted subtree for its MTCProof MUST perform the following steps:

1. Validate the certificate path from the MTC issuer’s CA certificate to a configured trust anchor according to . Validate the MTC-specific certificate fields and proof according to .
2. Extract start and end from the certificate's MTCProof. Validate that [start, end) is a valid subtree and evaluate the MTCProof inclusion proof to produce its subtree root. If either check fails, reject the certificate.
3. Retrieve the LDP URI list from ldpBaseURIs and send a request containing only st and ed as specified in .
4. Parse exactly one LandmarkDistributionResponse. Reject malformed encodings, trailing data, oversized vectors, or a proof source range that differs from the requested range.
5. Parse the active-landmark list according to Section 6.4.3 of . Confirm that [start, end) is an active landmark subtree for the certificate's MTC issuance tree. Reject the certificate otherwise.
6. Verify LandmarkCheckpoint signatures using the relying party's configured MTC cosigner policy. Verify that log_origin identifies the same MTC issuance tree as the certificate, and that the checkpoint timestamp is sufficiently recent under local policy. Reject the response if these checks fail.
7. Verify every subtree consistency proof in proof_set in order, using the procedure in Section 4.4.3 of . The first proof MUST be verified against the subtree root from the MTCProof. Each later proof MUST be verified against the root reconstructed by the preceding proof.
8. Confirm that the final proof's target_tree_size and target_root equal the authenticated checkpoint's tree size and root. Reject the certificate if they differ.
9. Accept the certificate only if all MTC, certificate path, and application validation checks succeed.

A relying party that already has the source subtree in its trusted-subtree store uses the normal MTC verification procedure and does not need to contact an LDP server. Retrieval failure does not weaken certificate validation and MUST NOT cause the relying party to accept an otherwise unverifiable certificate.

Cached Landmarks and Incremental Updates A relying party MAY cache a successfully authenticated landmark. If a cached authenticated landmark is sufficient to validate a subsequent MTC certificate according to the normal verification procedure in , the relying party does not need to contact an LDP server. An implementation MAY also periodically obtain more recent signed landmarks and consistency proofs from the LDP server. Such retrieval allows a relying party to advance its cached authenticated landmark state without requiring certificate validation to begin with knowledge of a particular target tree size. Landmark consistency proofs MAY be generated and cached by the LDP server when new landmarks are published. An LDP server MAY additionally maintain skip-link proofs between landmarks to reduce the number of consistency proofs required to connect an older subtree or landmark to a more recent signed landmark. Retrieval failure MUST NOT weaken MTC certificate validation. A relying party MUST NOT accept a certificate for which the required cryptographic relationship to an authenticated landmark cannot be established.

Proof Generation and Efficiency Without consistency proofs, a relying party catching up from an old landmark might need to retrieve and authenticate every intermediate landmark. A LandmarkSubtreeProofSet permits the LDP to connect the requested source subtree to a checkpoint the relying party can authenticate, reducing repeated checkpoint-signature verification. The final checkpoint remains independently authenticated by the relying party. An LDP MAY generate a direct consistency proof from the source subtree to the selected checkpoint. When it retains proofs between landmarks, the LDP SHOULD use skip links to bound the number of proofs required to connect older and newer landmarks. A skip link structure can limit a proof chain to O(logN) proofs, where N is the number of landmarks. For example, a system that issued a landmark every hour for 10 years would have 87,600 landmarks. When landmark 87,601 is created, only 17 landmark proofs will need to be created. It would also reduce the LandmarkSubtreeProofSet from O(N) to O(logN), greatly reducing bandwidth requirements! The precise skip-link layout is an implementation choice; all returned proofs MUST satisfy the chaining and verification rules in this document.

Security Considerations The LDP server is not a trust anchor. A malicious or compromised server can withhold, corrupt, or replay data, causing validation to fail or consume resources. It cannot cause acceptance of an invalid certificate without breaking the MTC hash function, the authenticated checkpoint, or the subtree consistency proof algorithm. A relying party MUST authenticate the checkpoint and verify every proof locally; it MUST NOT trust the LDP's assertions about proof validity. The ldpBaseURIs extension is included in the MTC TBSCertificate contents and is covered by the MTC inclusion proof. Relying parties MUST validate the certificate issuer and MTC proof before using the extension. Implementations SHOULD impose limits on URI length, response size, proof count, and retrieval time to limit resource-exhaustion attacks. The st and ed query values reveal which subtree a relying party is verifying. Deployments should consider this disclosure in their privacy policies. HTTPS protects the request parameters and response from observation or modification in transit, but does not replace cryptographic proof validation. Availability depends on the LDP service and network.

IANA Considerations IANA is requested to allocate an object identifier for id-pe-ldpBaseURIs under the PKIX id-pe arc. The assigned value will replace TBD in this document.

Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Google LLC Apple Inc. Cloudflare Cloudflare Geomys This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to existing X.509 constructions and Certificate Transparency. Merkle Tree certificates additionally admit an optional size optimization that avoids signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments Thanks to David Benjamin, Bas Westerbaan, Mike Ounsworth, Rich Salz and Kris Kwiatkowski for their feedback during the design of this draft.