IP Paris

arthur.premont@ip-paris.fr

Telecom SudParis

hossam.afifi@telecom-sudparis.eu

LAMPS Internet-Draft Revocation TLS Sparse Merkle Tree PKI BFT Managing certificate revocation remains a recurring challenge in the Web Public Key Infrastructure (WebPKI). Existing solutions such as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) involve compromises in terms of propagation latency, availability, and user privacy. With the planned deprecation of OCSP by some major Certificate Authorities (CAs), there is renewed interest in alternatives. This document specifies a decentralized certificate revocation architecture based on a Distributed Revocation Ledger (DRL) managed collectively by CAs. The ledger state is maintained as a Sparse Merkle Tree (SMT) in which only revoked certificates occupy non-default leaves, so that a valid certificate is attested by a compact non-membership proof and no prior registration of valid certificates is required. This document further defines a new Transport Layer Security (TLS) extension enabling "DRL Stapling", which allows a server to provide a client with a cryptographic proof of a certificate's status, consisting of a Sparse Merkle audit path and an M-of-N threshold signature from the CA consortium. The approach builds on the Revocation Transparency proposal of Laurie and Kasper and on subsequent formalizations of Sparse Merkle Trees; its novel contributions are the decentralized threshold-signature trust model with deterministic finality and the concrete TLS wire format.

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

• CRLs suffer from high issuance latency, massive file sizes, and high bandwidth consumption for clients.
• OCSP 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 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 , 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 . 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.

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 . 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 . 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 and the Must-Staple concept , and is inspired by Certificate Transparency . It is complementary to, and distinct from, Merkle Tree Certificates , 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.

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.

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.

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.

Consortium Validators and Epoch Generation When a CA revokes a certificate, it submits a signed revocation transaction. Upon consensus, the corresponding SMT leaf transitions from default to a revoked value, a new Epoch is finalized, and the validators produce a collective threshold signature over the new SMT root together with the epoch metadata. The following properties are RECOMMENDED for the underlying DRL protocol:

• A revocation transaction SHOULD only be accepted if it originates from (or is endorsed by) the issuing CA.
• The consensus mechanism SHOULD ensure that no single compromised CA can unilaterally alter the status of certificates it did not issue.

Note that, because only revocations are stored, no registration of valid certificates is required.

Edge Nodes and Proof Computation To limit latency and distribute load, DRL Nodes may be deployed close to servers. (Edge topologies such as Multi-Access Edge Computing are one possible non-normative realization.) A node holds a synchronized replica of the SMT and computes, on demand, either a membership proof (for a revoked certificate) or a non-membership proof (for a certificate absent from the tree), attaching the consortium threshold signature for the current Epoch. This yields the DRLProof.

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.

Leaf Index The leaf index for a certificate is computed as leaf_index = Hash(CertificateID), where Hash is the algorithm identified by hash_algo and CertificateID is serialized as defined in . The index is interpreted as a bit string b[0..D-1] with b[0] the most significant bit; b[0] selects the direction at the root and b[D-1] at the leaf's parent.

Node Encoding and Default Digests To prevent second-preimage confusion between leaves, internal nodes, and empty subtrees, hashing employs distinct one-byte domain separation prefixes:

• Empty leaf digest: E[0] = Hash(0x00).
• Default digest of an empty subtree of height k (1 <= k <= D): E[k] = Hash(0x01 || E[k-1] || E[k-1]).
• Revoked (non-default) leaf digest: RevokedLeaf = Hash(0x02 || reason_code), where reason_code is a single byte.
• Internal node digest: Hash(0x01 || left_child || right_child).

The default digests E[0..D] are deterministic and MUST be precomputed by all implementations. Because empty subtrees share these digests, only the non-default siblings along a path need to be transmitted; the resulting SMT root is deterministic and history-independent.

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

Data Structures All structures use the TLS presentation language .

Hash Algorithm The hash_algo field identifies the hash algorithm used for the SMT. Values are defined in the "DRL Hash Algorithm" registry established by this document (). Implementations MUST support sha256(1). Support for sha384(2) and sha512(3) is RECOMMENDED.

Certificate Identifier and Status ; opaque serial_number<1..32>; } CertificateID; ]]> The CRLReason values are drawn from Section 5.3.1; removeFromCRL(8) is omitted as it pertains to delta-CRL processing.

• issuer_hash: the hash of the DER-encoded Subject Public Key Info (SPKI) of the issuer's certificate, using hash_algo; its length MUST equal the output length of that algorithm (32, 48, or 64 bytes).
• serial_number: the raw value bytes of the ASN.1 INTEGER serial number (without tag/length), in network byte order. Formatting characters (e.g., ':') MUST NOT be used.

The canonical serialization of CertificateID is its TLS-presentation-language encoding per Section 3, with length-prefixed opaque vectors. The leaf index is computed over exactly these bytes.

The DRL Proof A DRL Proof carries everything the client needs to recompute the SMT root and evaluate the status. The audit path transmits only non-default siblings; a bitmap indicates, for each of the D levels (bottom to top), whether the sibling is non-default (present in audit_path) or is the precomputed default digest for that level. ; } 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; ]]>

• status: valid(0) denotes a non-membership proof (the leaf at leaf_index is empty); revoked(1) denotes a membership proof (the leaf holds RevokedLeaf).
• path_bitmap: exactly ceil(D/8) bytes. Bit j (j = 0 is the bottom/leaf level) set means the sibling at level j is non-default and appears next in audit_path; unset means the sibling is the default digest E[j].
• audit_path: the non-default siblings in bottom-to-top order, in the same order as the set bits of path_bitmap.
• key_id: identifier of the consortium aggregated public threshold key, computed as the leading 20 bytes of the SHA-256 hash of the serialized aggregated public key. If unrecognized, the client MUST reject the proof.
• epoch_number: strictly monotonically increasing 64-bit epoch counter; ensures ordering, uniqueness, and rollback detection.
• epoch_timestamp: UNIX timestamp (seconds) of epoch finalization, used for freshness.
• root_signature: the M-of-N threshold signature over ComputedRoot || epoch_number || epoch_timestamp, with the two integers encoded as 8 bytes each in network byte order.

Threshold Signatures and Baseline Mode To ensure interoperability in the absence of a standardized threshold signature code point, implementations MUST support a baseline mode in which root_signature carries the concatenation of individual SignatureScheme signatures (using a mandatory-to-implement scheme such as ecdsa_secp256r1_sha256), of which at least M MUST verify against consortium member keys in the client's trust store. BLS threshold aggregation, following , is an OPTIONAL optimization; once an IANA code point is assigned it MUST be used in sig_scheme. Any threshold scheme used MUST prevent rogue-key attacks.

TLS Extension for DRL Stapling We define a new Certificate Status Type for the status_request extension .

Client Hello A client wishing to receive a DRL Proof includes a status_request extension with status_type set to drl_proof. A client MAY advertise both drl_proof and ocsp.

Server Certificate Message If the server holds a valid DRLProof for its end-entity certificate and the client advertised drl_proof, the server MUST include the DRLProof in the CertificateStatus structure. In TLS 1.3 it is carried in the extensions of the relevant CertificateEntry; in TLS 1.2 it follows in a CertificateStatus message. The server MUST NOT send an empty drl_proof status; it MAY fall back to ocsp.

Fallback and Coexistence

• Server: If it cannot obtain a fresh proof, the server SHOULD fall back to OCSP Stapling if supported.
• Client: If it advertised drl_proof but receives none, it SHOULD apply its local revocation policy.
• Hard-fail: Deployments MAY define a Must-Staple-like policy extension (analogous to ); such a definition is out of scope here.

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.

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 ; the remaining siblings are default and omitted, kept implicit via path_bitmap.

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.

Security Considerations

Byzantine Consortium and Threshold Signatures Security relies on the assumption that compromised authorities do not exceed the fault-tolerance threshold f (typically M = 2f + 1 with N = 3f + 1). Unlike OCSP, a single compromised CA cannot forge a root signature; an adversary must compromise M authorities to subvert the system. This replaces the auxiliary-log accountability of Revocation Transparency with cryptographic threshold accountability.

Freshness, Rollback and Equivocation Because the SMT represents a mutable current state, an evil node could attempt to present a stale root in which a currently revoked certificate still appears valid, as described in . The epoch_number and epoch_timestamp strictly couple the signature to one epoch. Clients MUST enforce a freshness threshold and therefore MUST maintain a reasonably accurate clock; stateful clients SHOULD additionally enforce monotonicity of epoch_number to detect rollback and equivocation.

Node Encoding Distinct domain separation prefixes for empty leaves, revoked leaves, and internal nodes prevent an interior digest from being reinterpreted as a leaf, following the encoding rationale of . Because the tree depth is fixed by hash_algo, the position of a leaf is uniquely determined by Hash(cert_id), binding a revocation to its certificate.

Network Partitioning A partitioned DRL Node freezes at an old epoch. Servers SHOULD fail over to an alternative node; otherwise clients reject the stale proof once the freshness threshold expires, providing a fail-safe.

Governance and Trust Model Assumptions This specification assumes a functioning CA consortium willing to operate validators and produce threshold signatures. Establishing such a consortium (membership, liability, key-share custody, edge funding) is a governance problem out of scope here and is expected to require coordination with root program operators and the CA/Browser Forum.

Trust Bootstrap and Key Rotation Clients are provisioned with the consortium aggregated public key via their trust store, analogous to a root CA. Each key is identified by key_id (leading 20 bytes of SHA-256 of the serialized key). On membership changes, a new key is distributed; during a transition period the consortium signs each root with both old and new keys, and clients accepting either key_id validate either proof. After the transition, the old key is retired.

IANA Considerations

CertificateStatusType Registry IANA is requested to assign a new value for drl_proof in the "TLS Certificate Status Types" registry .

Value	Description	Reference
TBD	DRL Sparse Merkle Proof	This document

DRL Hash Algorithm Registry IANA is requested to create a "DRL Hash Algorithm" registry with a "Specification Required" policy.

Value	Description	Reference
0	Reserved	This document
1	sha256	This document
2	sha384	This document
3	sha512	This document
4-254	Unassigned
255	Reserved	This document

Normative References Informative References Google Research NordSec 2016

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