| Internet-Draft | MTC Landmark Distribution | November 2026 |
| Gray, et al. | Expires 6 May 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://johngray-dev.github.io/mtc-ldp/draft-gray-plants-mtc-ldp.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-gray-plants-mtc-ldp/.¶
Discussion of this document takes place on the PKI, Logs, And Tree Signatures Working Group mailing list (mailto:plants@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/plants. Subscribe at https://www.ietf.org/mailman/listinfo/plants/.¶
Source for this draft and an issue tracker can be found at https://github.com/johngray-dev/mtc-ldp.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.ietf-plants-merkle-tree-certs].¶
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.¶
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.¶
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.¶
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.¶
Landmarks are reusable across verifications for many certificates, and the infrastructure that serves them may cache the landmarks. This makes distribution much more efficient.¶
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.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the TLS presentation language defined in [RFC8446]. The
structures in this document use the HashValue type and the hash function of
the MTC issuance log, as defined in [I-D.ietf-plants-merkle-tree-certs].¶
The terms landmark, landmark subtree, relying party, checkpoint, and subtree consistency proof have the meanings given in [I-D.ietf-plants-merkle-tree-certs].¶
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.¶
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 [RFC5280]. The extension MUST be non-critical.¶
The extension is defined as follows:¶
id-pe-ldpBaseURIs OBJECT IDENTIFIER ::= { id-pe TBD }
LandmarkDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF
LandmarkDistributionPoint
LandmarkDistributionPoint ::= IA5String
ext-ldpBaseURIs EXTENSION ::= {
SYNTAX LandmarkDistributionPoints
IDENTIFIED BY id-pe-ldpBaseURIs
CRITICALITY FALSE
}
¶
Each LandmarkDistributionPoint MUST be an absolute HTTPS URI, as defined by
[RFC3986]. A base URI MUST NOT contain a query component or fragment. Its path
identifies the LDP resource to which the request parameters in Section 5.1 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.¶
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 [RFC3986]:¶
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:¶
https://ldp.example/mtc?st=4096&ed=4352¶
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 [I-D.ietf-plants-merkle-tree-certs].¶
The relying party MUST NOT consider the returned checkpoint or requested subtree authenticated until all verification requirements in Section 6 have succeeded.¶
A LandmarkSubtreeProof proves that a source subtree is consistent with a
larger target tree. It is defined using the TLS presentation language as
follows:¶
struct {
uint48 source_start;
uint48 source_end;
HashValue source_root;
uint48 target_tree_size;
HashValue target_root;
HashValue consistency_proof<0..2^16-1>;
} 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 [I-D.ietf-plants-merkle-tree-certs].¶
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.¶
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:¶
struct {
opaque landmarks<1..2^24-1>;
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 [I-D.ietf-plants-merkle-tree-certs], 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.¶
The checkpoint carries a complete-tree hash and cosignatures over that tree. It is defined using the TLS presentation language:¶
struct {
uint48 tree_size;
HashValue root_hash;
uint64 timestamp;
Cosignature signatures<1..2^24-1>;
} LandmarkCheckpoint;
¶
Cosignature is defined in Section 6.2 of
[I-D.ietf-plants-merkle-tree-certs]. 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.¶
A relying party validating an MTC certificate with no locally trusted subtree
for its MTCProof MUST perform the following steps:¶
Validate the certificate path from the MTC issuer’s CA certificate to a configured trust anchor according to [RFC5280]. Validate the MTC-specific certificate fields and proof according to [I-D.ietf-plants-merkle-tree-certs].¶
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.¶
Retrieve the LDP URI list from ldpBaseURIs and send a request containing
only st and ed as specified in Section 5.1.¶
Parse exactly one LandmarkDistributionResponse. Reject malformed
encodings, trailing data, oversized vectors, or a proof source range that
differs from the requested range.¶
Parse the active-landmark list according to Section 6.4.3 of
[I-D.ietf-plants-merkle-tree-certs]. Confirm that [start, end) is an
active landmark subtree for the certificate's MTC issuance tree. Reject the
certificate otherwise.¶
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.¶
Verify every subtree consistency proof in proof_set in order, using the
procedure in Section 4.4.3 of
[I-D.ietf-plants-merkle-tree-certs]. 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.¶
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.¶
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.¶
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 [I-D.ietf-plants-merkle-tree-certs], 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.¶
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.¶
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 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.¶
Thanks to David Benjamin, Bas Westerbaan, Mike Ounsworth, Rich Salz and Kris Kwiatkowski for their feedback during the design of this draft.¶