CTng: Secure Certificate and Revocation Transparency

CTng: Secure Certificate and Revocation Transparency

Speakers: Jie Kong

Conference: NDSS Symposium 2026

YouTube: https://www.youtube.com/watch?v=X_OreYRRRro

Overview

The Web PKI ecosystem that underpins secure internet communication relies on Certificate Transparency (CT) to detect maliciously or mistakenly issued certificates, and on revocation mechanisms to invalidate compromised ones. However, both systems suffer from fundamental security and privacy flaws. Revocation is effectively broken -- browsers routinely accept revoked certificates through soft-fail behavior, vendor-assisted revocation provides no guarantee of complete coverage, and rogue CAs can hide revocation status. Meanwhile, CT itself is vulnerable to split-world attacks where a malicious logger maintains parallel log views, and relying parties who attempt to audit certificates directly compromise their privacy by revealing their communication patterns to loggers. This talk introduces CTng, an evolutionary extension of Certificate Transparency that simultaneously achieves secure transparency, revocation transparency, relying party privacy, and improved efficiency through a gossip-based threshold signature scheme among monitors.

Background

▶ Watch: How certificate revocation breaks down: soft-fail and rogue CAs (1:30)

The current X.509 certificate lifecycle involves Certificate Authorities (CAs) issuing certificates that bind identities to public keys, enabling TLS-secured communication. When a certificate must be prematurely invalidated -- for example, due to key compromise -- the certificate holder contacts the CA to request revocation, and relying parties (like browsers) must check revocation status before trusting a certificate.

Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) are the traditional mechanisms for revocation checking. However, if a network adversary blocks the revocation check, or if the check simply takes too long, browsers implement soft-fail behavior: they accept the certificate as valid despite being unable to verify its revocation status. This means an attacker who compromises a key and can interfere with network connectivity effectively bypasses revocation entirely.

Vendor-assisted revocation, used by modern browsers, involves browser vendors periodically retrieving revocation updates from CAs and selectively pushing them to browsers. But the selective nature of these pushes provides no guarantee that any specific revocation will reach all browsers. A rogue CA can also hide revocation status from the vendor entirely.

Certificate Transparency was introduced to detect unauthorized certificate issuance. CAs must submit certificates to trusted third-party loggers, which issue Signed Certificate Timestamps (SCTs) -- promises to include the certificate in their Merkle-tree-based log within a bounded time. However, an SCT is merely a signature, not proof of inclusion. For a relying party to verify actual inclusion, they must contact the logger directly, compromising their privacy by revealing which certificates (and therefore which servers) they are communicating with.

Key Findings

▶ Watch: Certificate Transparency privacy problem: loggers learn communication patterns (5:30)

The research identifies and addresses four interconnected problems in the current Web PKI transparency and revocation ecosystem:

Revocation is broken at multiple levels. Soft-fail behavior, selective vendor pushes, and the ability of rogue CAs to hide revocation status all undermine the reliability of certificate revocation. There is currently no revocation transparency -- revocation actions are not logged or made auditable in the way certificate issuance is.

CT is vulnerable to split-world attacks. A malicious logger can maintain two parallel log views: one containing a fraudulent certificate (shared with the victim's browser) and one without it (shared with monitors and the legitimate certificate owner). The current mitigation -- log redundancy, requiring certificates to be logged across multiple loggers -- is inefficient (each SCT requires signature verification) and merely makes the attack harder rather than preventing it.

Relying party privacy is compromised. Any attempt by a relying party to audit certificate inclusion directly exposes their communication patterns. Even delegating auditing to browser vendors does not fully address this if the vendor must query specific loggers about specific certificates.

CTng resolves all four issues by replacing SCTs with actual proofs of inclusion, piggybacking revocation information onto existing monitor infrastructure, and using a threshold signature gossip mechanism among monitors to ensure consistency without requiring relying parties to contact loggers or monitors directly.

Technical Deep Dive

▶ Watch: Split-world attack: malicious loggers maintaining parallel log views (8:00)

CTng introduces a modified workflow that preserves the existing CT entity model (CAs, loggers, monitors, relying parties) while fundamentally changing the security properties.

In the modified issuance flow, the CA submits a certificate to the logger as before, but instead of receiving an SCT (a promise), the logger periodically updates its Merkle tree and provides the CA with an actual proof of inclusion (POI) and a Signed Tree Head (STH). The CA embeds the POI directly in the certificate, so Alice receives proof of inclusion without needing to contact the logger. She still needs the STH to verify the POI, but this is obtained through a separate, privacy-preserving mechanism.

For revocation transparency, CTng piggybacks on the existing monitor infrastructure. Monitors already periodically retrieve new certificates and STHs from loggers. CTng adds revocation information to this data flow, using the efficient CRV (Certificate Revocation Vector) design from the Let's Revoke system (NDSS 2020). This means monitors now have both certificate issuance and revocation status in a single, auditable data structure.

The gossip mechanism is the key innovation for consistency assurance. Monitors engage in a gossip protocol to verify they are all seeing the same log data -- preventing split-world attacks. Once consistency is confirmed, each monitor generates a partial threshold signature over the combined issuance and revocation data. These partial signatures are collected and combined into a single combined threshold signature. Alice can then obtain the STH, revocation status, and the combined signature from any public repository -- monitors, ISPs, DNS records, or browser vendors -- without revealing which specific certificates she is interested in.

The prototype implementation was evaluated on the SPHERE testbed. Key performance results show that convergence time (the time for gossip to complete across all monitors) remains flat even as the number of monitors increases beyond current CT deployment levels. Under workload scaling tests, with real-world CT certificate volume of approximately 400,000 certificates per hour (observed December 2024), convergence time grows linearly -- even tripling the workload to 1.2 million certificates per hour produces convergence times well within the operational bounds of hours to 24 hours that the current CT ecosystem allows.

Demo / Proof of Concept

▶ Watch: Gossip-based threshold signatures for consistency assurance (11:30)

The prototype evaluation demonstrates two critical scalability properties. First, the gossip-based threshold signature mechanism scales horizontally: adding more monitors does not increase convergence time, meaning the system can accommodate growth in the monitor ecosystem without performance degradation. Second, the system handles workload surges gracefully: even at 3x the current real-world CT certificate volume, convergence times remain within acceptable bounds. The proof of inclusion verification also offers a potential performance improvement over SCT verification, as it involves verifying a series of hash computations rather than public-key digital signature verification.

Defensive Implications

▶ Watch: Performance evaluation: convergence time scales flat with monitor count (13:30)

For web security practitioners, CTng addresses the uncomfortable reality that the current CT system provides weaker guarantees than commonly assumed. The split-world attack is not theoretical -- it requires a malicious logger, which is a realistic threat given that loggers are trusted third parties. By replacing promises (SCTs) with proofs (POIs) and using threshold signatures for consistency, CTng eliminates the need to trust individual loggers.

For browser vendors and CA/Browser Forum participants, the revocation transparency component is particularly significant. The current vendor-assisted revocation model creates an accountability gap: there is no way to audit whether a vendor has actually pushed all relevant revocation updates to all browsers. CTng makes revocation actions transparent and auditable alongside certificate issuance.

For privacy-conscious organizations, the elimination of direct relying-party-to-logger communication removes a surveillance vector. Under current CT, a compromised or "snoopy" logger can learn which clients are communicating with which servers by observing who requests inclusion proofs for which certificates. CTng's architecture ensures that relying parties obtain all necessary verification data from general-purpose public repositories without revealing their specific interests.

The evolutionary design -- reusing existing CT entities and infrastructure rather than proposing entirely new systems -- makes adoption more realistic than revolutionary alternatives.

Key Takeaways

• Certificate revocation is fundamentally broken: soft-fail, selective vendor pushes, and rogue CAs all undermine revocation reliability
• Current Certificate Transparency is vulnerable to split-world attacks where malicious loggers maintain parallel log views
• Relying parties who audit certificates directly compromise their privacy by revealing communication patterns to loggers
• CTng replaces SCT promises with actual proofs of inclusion embedded in certificates, eliminating trust in individual loggers
• A gossip-based threshold signature mechanism among monitors ensures consistency without requiring relying parties to contact loggers
• Revocation transparency is achieved by piggybacking on existing monitor infrastructure using the CRV design from Let's Revoke
• The system scales horizontally: convergence time is flat as monitors increase and linear as certificate volume grows

About the Speaker(s)

Jie Kong is a researcher working on web PKI security, certificate transparency, and revocation systems. The work is a collaboration with Damon James, Eva Ceta, and Amir Herzberg, bringing together expertise in cryptographic protocol design, distributed systems, and web security infrastructure. The research builds on prior work including the Let's Revoke system presented at NDSS 2020.