TLS Extension for Distributed Revocation Ledger (DRL) Stapling using a Sparse Merkle Tree

Status of This Memo

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 7 January 2027.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction

The Web Public Key Infrastructure (WebPKI) relies heavily on the reliable dissemination of certificate revocation information. Standardized mechanisms show significant limitations:¶

• CRLs [RFC5280] suffer from high issuance latency, massive file sizes, and high bandwidth consumption for clients.¶
• OCSP [RFC6960] introduces a single point of failure, adds blocking latency during the TLS handshake, and leaks privacy by exposing browsing habits to the responder.¶

To address latency and privacy, OCSP Stapling [RFC6066] was introduced, but it still relies on centralized OCSP infrastructure. Proprietary mechanisms like CRLite address privacy and availability but rely on a single trusted aggregator without distributed cryptographic proof.¶

This work is directly inspired by, and builds upon, the Revocation Transparency (RT) proposal of Laurie and Kasper [RevocationTransparency], which first proposed storing certificate revocation status in a Sparse Merkle Tree and stapling a recent proof alongside the certificate. It also builds on the subsequent formalization of Sparse Merkle Trees and their (non-)membership proofs by Dahlberg, Pulls, and Peeters [SMT]. RT deliberately left the trust model out of scope. The novel contribution of this document is twofold: (1) a decentralized trust model in which the ledger root is signed by an M-of-N threshold signature produced by a consortium of CAs operating a consensus with deterministic finality, replacing RT's reliance on an auxiliary transparency log for accountability; and (2) a concrete TLS wire format for stapling the resulting proof.¶

Because the ledger is a Sparse Merkle Tree in which only revoked certificates occupy non-default leaves, a valid certificate is proven by a compact non-membership proof, and CAs need not register valid certificates. The server fetches the proof from a local DRL node and staples it; the client verifies it as a purely local cryptographic operation.¶

2. Related Work

The idea of maintaining certificate revocation status in a Sparse Merkle Tree and serving a recent proof to relying parties originates in Revocation Transparency [RevocationTransparency]. That proposal focuses on transparency, i.e., ensuring that the revocation list a client sees is the same one everyone else sees, and explicitly leaves open the questions of who may revoke and under which trust model. The Sparse Merkle Tree data structure and its secure (non-)membership proofs, including precomputable default digests and node encodings that prevent second-preimage confusion, are formalized in [SMT].¶

DRL Stapling differs from these works by replacing the transparency/auxiliary-log accountability model with an M-of-N threshold signature produced by an identifiable CA consortium under a consensus protocol with deterministic finality, and by specifying an interoperable TLS wire format. It builds on OCSP Stapling [RFC6066] and the Must-Staple concept [RFC7633], and is inspired by Certificate Transparency [RFC6962] [RFC9162]. It is complementary to, and distinct from, Merkle Tree Certificates [I-D.davidben-tls-merkle-tree-certs], which target certificate issuance rather than revocation. Unlike Decentralized PKI (DPKI), DRL retains the existing X.509 trust hierarchy and decentralizes only the dissemination of revocation status among already-trusted CAs.¶

3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

DRL (Distributed Revocation Ledger):

An append-only, cryptographically verifiable ledger of revocations, collectively managed by a consortium of CAs and represented as a Sparse Merkle Tree.¶

Consortium:

The set of CAs that operate as validators of the DRL and collectively produce threshold signatures over the ledger root.¶

Threshold Signature:

A signature scheme where at least M of N authorized signers must cooperate to produce a valid signature.¶

Sparse Merkle Tree (SMT):

A Merkle tree of intractable size (one leaf per possible key digest) in which the vast majority of leaves are empty (default), enabling efficient membership and non-membership proofs.¶

Epoch:

A strictly monotonically increasing sequence number identifying a finalized SMT root, associated with a UNIX timestamp of finalization.¶

DRL Node:

A network peer maintaining a replica of the SMT state and serving proofs to TLS servers.¶

4. Architecture Overview

The DRL is a Sparse Merkle Tree collectively maintained by participating CAs acting as consensus validators. Only revocations are inserted; a certificate that has never been revoked corresponds to a default (empty) leaf. The consortium signs the SMT root of each Epoch with a threshold signature.¶

While the exact ledger implementation is outside the scope of this TLS extension, the underlying network MUST guarantee:¶

1. Deterministic Finality: Once committed, a revocation cannot be reverted or forked. Proof-of-Work and probabilistic Proof-of-Stake are NOT RECOMMENDED; permissioned Byzantine Fault Tolerant (BFT) / Proof-of-Authority consensus is RECOMMENDED.¶

2. Authority Accountability: The validator set MUST consist of identifiable and accountable entities, such as CAs present in existing root trust stores.¶

5. Sparse Merkle Tree Construction

The DRL is a Sparse Merkle Tree of depth D, where D equals the output length in bits of the tree hash algorithm (256 for SHA-256). Each certificate is mapped to a unique leaf whose position is the digest of its identifier. A valid (never-revoked) certificate maps to a default leaf; a revoked certificate maps to a non-default leaf carrying its revocation reason.¶

6. Cryptographic Agility

This specification defines a DRLHashAlgorithm enumeration for the SMT and leverages the SignatureScheme registry of TLS 1.3 [RFC8446] for the threshold signature. The tree depth D is determined by the chosen hash algorithm.¶

7. Data Structures

All structures use the TLS presentation language [RFC8446].¶

enum {
    sha256(1),   /* D = 256 */
    sha384(2),   /* D = 384 */
    sha512(3),   /* D = 512 */
    (255)
} DRLHashAlgorithm;

enum {
    valid(0),      /* proven by a non-membership proof */
    revoked(1),    /* proven by a membership proof     */
    (255)
} CertificateStatus;

enum {
    unspecified(0),
    keyCompromise(1),
    cACompromise(2),
    affiliationChanged(3),
    superseded(4),
    cessationOfOperation(5),
    certificateHold(6),
    /* 7 reserved; 8 (removeFromCRL) intentionally omitted */
    privilegeWithdrawn(9),
    aACompromise(10),
    (255)
} CRLReason;

struct {
    opaque issuer_hash<32..64>;
    opaque serial_number<1..32>;
} CertificateID;

struct {
    opaque node_hash<20..64>;
} MerkleNode;

struct {
    CertificateID cert_id;
    CertificateStatus status;
    CRLReason reason_code;        /* meaningful only if status == revoked */
    DRLHashAlgorithm hash_algo;
    SignatureScheme sig_scheme;
    opaque key_id<4..32>;
    opaque path_bitmap<0..2^16-1>; /* D bits, ceil(D/8) bytes, bit j = level j */
    MerkleNode audit_path<0..2^16-1>; /* non-default siblings, bottom to top */
    uint64 epoch_number;
    uint64 epoch_timestamp;
    opaque root_signature<1..2^16-1>;
} DRLProof;

8. TLS Extension for DRL Stapling

We define a new Certificate Status Type for the status_request extension [RFC6066].¶

enum {
    ocsp(1),
    drl_proof(TBD),
    (255)
} CertificateStatusType;

9. Client Validation

Upon receiving a DRLProof, the client MUST perform the following steps. If any fails, the proof is invalid. The client MUST NOT act on status until steps 1 through 5 succeed, to prevent an attacker from forcing a handshake abort via an unauthenticated revoked claim.¶

1. Identifier and index: Verify that cert_id matches the server certificate (issuer SPKI hash and serial number), then compute leaf_index = Hash(cert_id) using hash_algo.¶

2. Leaf digest: If status is valid, set cur = E[0]. If revoked, set cur = Hash(0x02 || reason_code).¶

3. Root reconstruction: For j from 0 to D-1: let the controlling bit be b[D-1-j] of leaf_index; obtain the sibling S = audit_path next entry if path_bitmap bit j is set, else S = E[j]. If the controlling bit is 0, set cur = Hash(0x01 || cur || S); else cur = Hash(0x01 || S || cur). After D iterations, ComputedRoot = cur. Implementations MUST verify that the number of set bits in path_bitmap equals the number of entries in audit_path.¶

4. Signature: Look up the aggregated key for key_id; if absent, reject. Verify root_signature using sig_scheme over ComputedRoot || epoch_number || epoch_timestamp. It MUST be a valid M-of-N threshold signature.¶

5. Freshness: epoch_timestamp MUST be within the acceptable freshness window; stale proofs MUST be rejected. Stateful clients MAY reject proofs whose epoch_number is lower than the highest previously seen.¶

6. Status evaluation: If status is revoked, abort with a certificate_revoked alert.¶

10. Privacy and Performance Considerations

The client performs no outbound status query, so browsing habits and IP address are never exposed to third-party responders. For SHA-256 (D = 256), the average number of non-default siblings on a path is O(log N) where N is the number of revoked certificates [RevocationTransparency] [SMT]; the remaining siblings are default and omitted, kept implicit via path_bitmap.¶

11. Operational Considerations

Servers SHOULD refresh their cached DRLProof at an interval shorter than the client freshness window (a RECOMMENDED value is half the window), with exponential-backoff retry. The consortium SHOULD generate epochs at a regular cadence; for Web PKI, an epoch interval between 1 minute and 1 hour is RECOMMENDED.¶

12. Security Considerations

13. IANA Considerations

Appendix A. Example DRL Proof Verification

This non-normative example uses a toy depth of D = 4 for readability (a real deployment uses D = 256 for SHA-256). Suppose the certificate maps to leaf_index = 1011 (b[0]=1, b[1]=0, b[2]=1, b[3]=1) and is valid, i.e., its leaf is empty.¶

Precompute defaults:
  E[0] = Hash(0x00)
  E[1] = Hash(0x01 || E[0] || E[0])
  E[2] = Hash(0x01 || E[1] || E[1])
  E[3] = Hash(0x01 || E[2] || E[2])

Start (status = valid):
  cur = E[0]

Walk bottom (j=0) to top (j=3); controlling bit = b[3-j]:
  j=0: bit b[3]=1 -> cur is right child.
       sibling S0 = (bitmap bit0 set ? audit_path[.] : E[0])
       cur = Hash(0x01 || S0 || cur)
  j=1: bit b[2]=1 -> cur is right child.
       cur = Hash(0x01 || S1 || cur)
  j=2: bit b[1]=0 -> cur is left child.
       cur = Hash(0x01 || cur || S2)
  j=3: bit b[0]=1 -> cur is right child.
       cur = Hash(0x01 || S3 || cur)

ComputedRoot = cur

Verify root_signature over
  (ComputedRoot || epoch_number || epoch_timestamp)
using the consortium aggregated key selected by key_id,
then check freshness. Since status = valid, the handshake proceeds.

Authors' Addresses