Two-Thirds of the Web Is Already Post-Quantum, but Your Certificate Still Isn't

Open your browser developer tools on almost any major website today, open the security panel, and inspect the connection parameters. If you are using a modern release of Chrome, Edge, Firefox, or Safari, you will likely spot an unfamiliar key exchange group: X25519MLKEM768. That string is not telemetry or an internal flag. It proves that the browser and server completed a hybrid post-quantum key agreement. The symmetric encryption keys safeguarding HTML, JSON, images, and session cookies for the remainder of that HTTPS connection were derived from two distinct algorithms: classical elliptic-curve Diffie-Hellman and a module-lattice encapsulation mechanism standardized by NIST.

That slice of the web has already crossed into production reality. Cloudflare reported that more than two-thirds of all human-initiated TLS connections reaching its network negotiate hybrid post-quantum key exchange. Chrome enabled the exchange by default on desktop, followed by Firefox and Apple operating systems. In August 2026, the Internet Engineering Task Force published RFC 10024, formalizing hybrid ML-KEM key agreement mechanisms for TLS 1.3 on the standards track. To anyone glancing solely at browser metrics, the long-heralded post-quantum transition of the internet appears to have arrived smoothly.

Yet if you look one layer higher in that exact same handshake and inspect the digital certificate that verified the server identity, an entirely different picture appears. The public key embedded in that certificate and the digital signature stamped across its identity fields are almost certainly classical: an RSA-2048 key, an RSA-3072 key, or an ECDSA signature using the NIST P-256 curve. Across the public internet, no major web browser trust store validates ML-DSA post-quantum certificates as its production default. No commercial public Certificate Authority issues post-quantum leaf certificates accepted by stock operating systems without manual root installation. Measurement surveys of production domains across 2026 consistently show that while hybrid key exchange protects tens of millions of hostnames, the prevalence of post-quantum digital certificates on the public web remains stubbornly at zero percent.

This profound division across the web's cryptographic architecture is neither an accident nor an oversight. It is a fundamental asymmetry dictated by network physics, TCP packet dynamics, initial congestion window limits, and the operational structure of the public Web Public Key Infrastructure. Session key exchange was relatively straightforward to modernize because it requires adding roughly one kilobyte to the opening handshake, affecting only the two endpoints actively negotiating the connection. Upgrading the digital certificates that prove website authenticity, by contrast, collides directly with maximum transmission unit ceilings, legacy deep-packet inspection firewalls, and the multi-hop latency of TCP slow-start.

To understand why browsers and CDNs rushed to deploy post-quantum key exchange years ahead of final standards, one must examine the adversary model governing encrypted traffic: the strategy known as harvest now, decrypt later.

The threat of quantum computing to public-key cryptography is not science fiction, but its timeline creates a deceptive sense of safety. Cryptographically Relevant Quantum Computers—machines capable of executing Shor's algorithm at scale to factor large prime integers or solve discrete logarithms—remain years away in laboratory development. If quantum computers were only capable of attacking live connections in real time, internet architects could theoretically wait until the hardware arrived before replacing underlying algorithms.

The harvest-now-decrypt-later strategy destroys that comfort. State intelligence agencies and criminal syndicates do not need a quantum computer today to compromise encrypted web traffic. All they require today is vast, inexpensive physical storage. By passively tapping undersea fiber-optic cables, internet exchange points, and transit links, an adversary can systematically record petabytes of encrypted TLS traffic every single day. That data sits quietly in magnetic and optical archives, unreadable today under the protection of AES-256 or ChaCha20-Poly1305.

The vulnerability lies entirely in the ephemeral handshake that generated those symmetric keys. In a classical TLS 1.3 connection using pure X25519 or P-256 Diffie-Hellman, the client and server exchange public parameters over the wire to calculate a shared secret. If an adversary captures that exchange today and retains the recording until a fault-tolerant quantum computer arrives ten or fifteen years from now, Shor's algorithm will solve the discrete logarithm problem in polynomial time. The adversary will recover the private keys, reconstruct the session secret, and decrypt the recorded payload.

For temporary social media feeds, retroactive decryption carries minimal consequence. But for data with a mandatory confidentiality lifespan measured in decades—personal health records, financial records, intellectual property, biometric databases, diplomatic communications, and legal settlements—the vulnerability window is open right now. Any sensitive record transmitted across the public internet under classical-only key exchange in 2026 is effectively an open book waiting for a future decryption key.

Authentication signatures operate under a completely different temporal threat model. When your browser connects to your bank, the bank certificate uses an RSA or ECDSA signature to prove you are communicating with the genuine server. That validation happens entirely in the present tense: the browser checks the mathematical signature against trusted Certificate Authority roots during the few milliseconds of the TLS handshake. Once the handshake finishes, the digital signature has served its purpose. An adversary who captures that signature today cannot use a future quantum computer to retroactively forge a past authentication event that already concluded.

Because retroactive decryption threatens confidentiality retroactively while signature forgery only threatens live connections in the future, securing key exchange became an immediate emergency. Securing digital certificates could afford to take the slower, more deliberate path required by global standards bodies.

When standards architects began designing post-quantum replacements for TLS key agreement, they confronted a significant mathematical shift. The familiar algorithms that powered internet security for four decades—RSA, Diffie-Hellman, and Elliptic Curve Cryptography—relied on number theory: prime factorization and discrete logarithms. Shor's algorithm solves both with exponential speedup.

To resist quantum cryptanalysis, researchers turned to lattice-based cryptography, specifically the Learning With Errors problem over module lattices. In August 2024, NIST released FIPS 203, officially standardizing the Module-Lattice-based Key-Encapsulation Mechanism, designated as ML-KEM. The parameter set selected for general web deployment is ML-KEM-768, offering a security level roughly equivalent to AES-192, comfortably exceeding margins needed against both classical and quantum adversaries.

Unlike classical Diffie-Hellman, which operates as a symmetric key exchange where both parties exchange public parameters and compute the shared value independently, ML-KEM operates as a Key Encapsulation Mechanism. The receiver generates an encapsulation key pair and sends the public key to the sender. The sender generates a random shared secret, encapsulates it using the receiver's public key to create a ciphertext, and transmits that ciphertext back. The receiver uses its private decapsulation key to recover the exact same shared secret from the ciphertext.

In TLS 1.3, the client advertises cryptographic capabilities and sends speculative key shares inside the supported_groups and key_share extensions of its opening ClientHello message.

However, neither the IETF nor browser vendors were willing to trust the entire internet solely to newly standardized lattice mathematics. An unforeseen algebraic shortcut or implementation flaw in ML-KEM could theoretically compromise connections without warning. The engineering answer was the hybrid key exchange. Instead of choosing between classical and post-quantum security, the protocol executes both simultaneously and merges them.

Published as RFC 10024 in August 2026, the standard combines classical X25519 with ML-KEM-768 under the group identifier X25519MLKEM768, assigned IANA code point 0x11EC. During a TLS 1.3 handshake utilizing this group:

• The client generates an ephemeral X25519 key pair and an ephemeral ML-KEM-768 encapsulation key pair. Inside ClientHello, the client sends 32 bytes of classical X25519 public key followed by 1,184 bytes of ML-KEM-768 encapsulation key, totaling 1,216 bytes.
• The server performs both computations, generates its own X25519 key pair, and encapsulates a random 32-byte secret using the client ML-KEM key to produce a 1,088-byte ciphertext.
• Inside ServerHello, the server sends its 32-byte X25519 public key and the 1,088-byte ML-KEM ciphertext, totaling 1,120 bytes.
• Both endpoints pass the classical Diffie-Hellman secret and the decapsulated ML-KEM secret through HKDF-Extract and HKDF-Expand to derive session keys.

An attacker attempting to recover plaintext must break both the classical elliptic-curve discrete logarithm and the module-lattice Learning With Errors problem. If a flaw is discovered in ML-KEM tomorrow, the classical X25519 component maintains the existing security boundary. If a quantum computer emerges in a decade, the ML-KEM component maintains post-quantum protection.

RFC 10024 also specified SecP256r1MLKEM768 and SecP384r1MLKEM1024. However, in the official IANA registry, only X25519MLKEM768 is designated as Recommended: Yes. That single group has become the universal standard negotiated by modern browsers, CDNs, and operating systems.

In traditional internet protocol history, deployment follows a predictable timeline: research leads to drafts, working groups debate specifications for years, the IETF publishes an RFC, libraries implement the standard, operating systems package the libraries, and administrators update servers.

With post-quantum TLS, that sequence was inverted. Deployment did not wait for the standard; the standard followed the deployment.

Google implemented experimental post-quantum key exchange in Chromium as early as 2019, and tested Kyber-based hybrids in 2023. By April 2024, Chrome 124 introduced hybrid post-quantum key exchange enabled by default on desktop. Mozilla enabled X25519MLKEM768 for HTTPS in Firefox 132 in October 2024, followed by QUIC and HTTP/3 support in Firefox 135. Apple incorporated system-wide hybrid ML-KEM support across iOS and macOS networking stacks.

On the server side, content delivery networks acted as the primary force multiplier. Cloudflare enabled post-quantum key exchange across its global edge network by default, ensuring every website routed through its reverse proxies negotiated the hybrid group without requiring site owners to edit configuration files. AWS updated its s2n-tls library and edge endpoints; Google Cloud and Microsoft Azure rolled out support across application load balancers.

The quantitative results were remarkable. In October 2025, Cloudflare announced that over 50 percent of all human-initiated HTTPS connections on its network had transitioned to hybrid post-quantum key exchange. By February 2026, that proportion climbed past 60 percent. By April 2026, telemetry demonstrated that more than two-thirds of human-generated web traffic reaching Cloudflare's edge actively utilized X25519MLKEM768.

Yet this aggregate metric conceals an important architectural reality: browser-to-edge encryption is only half the journey. For millions of websites operating behind CDNs, the connection from the visitor browser to the CDN edge proxy is post-quantum secure. But what about the origin connection—the network leg traveling from the CDN edge back to the customer web server sitting in a data center or cloud virtual machine?

Until recently, almost all origin connections quietly fell back to classical TLS. While the front door was fortified with lattice cryptography, the back door remained exposed to long-term interception.

To bridge that gap, Cloudflare introduced Automatic Key Exchange for origins in September 2026. The edge proxy dynamically probes origin servers to detect whether their TLS stacks support post-quantum key agreement. If the origin server indicates support in its handshake parameters, Cloudflare automatically upgrades the origin connection to X25519MLKEM768. Following the launch of this feature, daily post-quantum origin connections across scanned domains jumped from 25 billion to 45 billion, with over 99.2 percent of those handshakes completing cleanly without requiring a round-trip HelloRetryRequest.

The adoption curve proved that when major client vendors and edge providers agree on an operational priority, software-level encryption can be deployed across billions of users in under two years. But that success makes the total absence of post-quantum digital certificates even more conspicuous.

If web browsers and CDNs upgraded key exchange across two-thirds of the planet with minimal friction, why has the digital certificate ecosystem not followed suit? Why does every production website continue to present a digital certificate signed with classical RSA or ECDSA?

The answer lies in the fundamental operational distinction between symmetric session keys and the global Web Public Key Infrastructure.

To upgrade session key exchange, only two software components need to agree: the browser crypto library and the server crypto library. The exchange is ephemeral, self-contained, and negotiated on the fly. If either side does not understand the hybrid group, TLS 1.3 simply falls back to classical X25519 within the exact same handshake. No third parties, regulatory bodies, or external databases are involved.

Upgrading digital certificates, by contrast, requires transforming an intricate, heavily regulated global bureaucracy of trust.

A digital certificate does not exist in isolation. When your browser validates a website identity, it does not inspect a single cryptographic signature; it inspects an entire trust chain: the leaf certificate issued to the domain, one or more intermediate Certificate Authority certificates, and the root Certificate Authority certificate embedded immutably inside the operating system or browser root trust store.

In addition to the certificate chain itself, modern web security requires Certificate Transparency. Every publicly trusted TLS certificate must be logged in multiple independent, cryptographically verifiable CT logs operated by entities such as Google, Cloudflare, and Sectigo. Before a browser displays a secure connection, it verifies Signed Certificate Timestamps embedded directly within the certificate or delivered via the TLS handshake. Furthermore, browsers rely on Online Certificate Status Protocol stapling or Certificate Revocation Lists to ensure certificates have not been revoked.

The CA/Browser Forum, the regulatory consortium of browser vendors and Certificate Authorities that establishes the Baseline Requirements for publicly trusted certificates, operates through formal ballots and consensus. While working groups within the CA/Browser Forum have actively drafted guidelines for ML-DSA and SLH-DSA post-quantum signatures, no merged Baseline Requirement currently authorizes public CAs to issue publicly trusted post-quantum certificates for general web traffic.

Even if a Certificate Authority wanted to issue an ML-DSA certificate today, it could not do so for the public web. Major root programs—managed independently by Microsoft, Apple, Google, and Mozilla—require years of audits, operational evaluations, and compliance verification before adding a new root CA certificate to their trusted stores. As of late 2026, not a single post-quantum root CA has been accepted into the default production root stores of Windows, iOS, Android, or macOS.

Private enterprise PKI environments, where an organization controls both server endpoints and managed client devices, can deploy internal post-quantum CAs using tools like rustls or internal Vault clusters. But on the public web, the infrastructure of identity is locked in place. And as network engineers know all too well, the obstacles preventing that transition are physical.

To understand why network engineers dread the arrival of post-quantum certificates, one must calculate the byte mathematics of network packets and observe what happens when cryptographic payloads collide with the physical constraints of the internet.

For fifteen years, TLS performance has been optimized around compact elliptic curves. An ECDSA P-256 public key occupies 64 bytes. An ECDSA signature occupies roughly 64 to 72 bytes. An entire three-certificate chain—leaf, intermediate, and cross-signatures—typically measures between 2,000 and 3,500 bytes.

Now compare those compact classical figures with post-quantum digital signature algorithms standardized under NIST FIPS 204 (ML-DSA).

ML-DSA, derived from CRYSTALS-Dilithium, is the primary candidate for general digital signature adoption. At the lowest standardized tier, ML-DSA-44, the public key is 1,312 bytes and the signature is 2,420 bytes. A single ML-DSA-44 certificate exceeds 3,800 bytes. At the recommended ML-DSA-65 tier, the public key is 1,952 bytes and the signature is 3,309 bytes, expanding a single certificate past 5,300 bytes.

Constructing a standard three-tier certificate chain using pure ML-DSA-65 causes the cumulative payload to explode to between 12,000 and 16,000 bytes. If you implement a hybrid certificate pairing ECDSA with ML-DSA for backwards compatibility, the payload becomes larger still.

This dramatic expansion in byte volume collides violently with the architecture of TCP/IP networking.

The standard Ethernet Maximum Transmission Unit is 1,500 bytes. Subtracting standard IP and TCP headers leaves an effective Maximum Segment Size between 1,420 and 1,460 bytes. In a classical TLS handshake, the opening ClientHello measured roughly 300 to 500 bytes, fitting comfortably inside a single packet.

When hybrid key exchange was introduced via X25519MLKEM768, the client had to transmit an additional 1,184 bytes of encapsulation key. That expanded the ClientHello payload to roughly 1,500 bytes, hovering directly over the MTU boundary.

While clean networks handle this via TCP segmentation, legacy middleboxes and enterprise firewalls frequently discard ClientHello messages split across fragments or exceeding local MTU settings. Early experiments by Cloudflare and Google showed that roughly 0.05 percent of connections broke when post-quantum key exchange was enabled, requiring temporary enterprise opt-out policies while firewalls were patched.

With certificates, the problem is an order of magnitude worse. A 15-kilobyte certificate chain requires ten to fourteen individual TCP segments. During connection initiation, TCP operates under an initial congestion window (typically initcwnd = 10). If the certificate chain exceeds this window or suffers packet loss, TCP slow-start halts transmission. The connection stalls, waiting for round-trip acknowledgments before delivering the remaining certificate data.

On mobile networks or satellite links, injecting multiple round-trip stalls into the cryptographic handshake destroys web performance. Page load metrics like Time to First Byte degrade noticeably. This is the real barrier holding back post-quantum certificates: the network plumbing of the global internet cannot digest the byte volume without choking.

Recognizing that brute-force replacement of classical certificates with multi-kilobyte ML-DSA chains is an operational dead end, security researchers and standards bodies are actively exploring radical architectural alternatives.

The most prominent initiative from the browser perspective is the Chromium security team's research into Merkle Tree Certificates (MTC).

In the traditional Web PKI model, every certificate is an autonomous identity document carrying a full cryptographic signature generated by an intermediate CA. The server sends the entire certificate and signature across the wire, forcing the client to verify the cryptographic math from scratch.

Merkle Tree Certificates invert this paradigm by shifting the burden of trust from heavy individual signatures to lightweight cryptographic proofs. Under MTC, Certificate Authorities continuously aggregate thousands of issued certificates into a cryptographic Merkle tree. The CA calculates the single root hash of the tree and signs only that solitary root hash at regular intervals using a post-quantum signature.

When a client connects to a web server utilizing Merkle Tree Certificates:

• The server does not send a multi-kilobyte certificate chain containing several heavy signatures.
• Instead, the server sends its lightweight certificate data accompanied by a compact Merkle inclusion proof: a short list of 32-byte intermediate hashes proving that the server's certificate is a valid leaf inside the CA's published tree.
• The web browser, having already cached the CA's current signed tree root in the background, validates the inclusion proof using simple, fast SHA-256 hash operations.

Because a Merkle inclusion proof scales logarithmically, an inclusion proof for a tree containing a billion certificates requires only about 30 hashes—less than one kilobyte of data. By replacing large signatures with compact hash paths, Merkle Tree Certificates reduce the wire size of the server's identity payload back down to classical proportions, neatly sidestepping the MTU fragmentation trap.

A second architectural proposal under investigation within the IETF is KEM-TLS. KEM-TLS demonstrates that by re-architecting the protocol to use nested Key Encapsulation Mechanisms rather than digital signatures, a server can authenticate itself purely through post-quantum key encapsulation. Because ML-KEM keys and ciphertexts are substantially smaller than ML-DSA signatures, KEM-TLS slashes handshake bandwidth, though it requires fundamental modifications to the core state machine of TLS.

Simultaneously, content delivery networks are pioneering transition paths on the operational front. In late 2026, Cloudflare announced the establishment of a Public Certificate Authority specifically tailored for the post-quantum web. Designed to bridge the multi-year gap between experimental standards and browser trust stores, such initiatives allow organizations to experiment with automated post-quantum certificate issuance, measure real-world packet drops, and establish baseline performance metrics before global root programs enforce mandatory cutovers.

Given this complex landscape, what should a responsible systems engineer or website operator do right now? You do not need access to a quantum laboratory to audit your systems. The tools to verify post-quantum readiness already exist on your development workstation.

Auditing Your Browser Connection in Real Time

To verify whether your current web browser is successfully negotiating post-quantum key exchange:

• Open Google Chrome, Microsoft Edge, or Mozilla Firefox.
• Navigate to your website or any major web property.
• Open Developer Tools by pressing F12 (or Cmd + Option + I on macOS).
• Select the Security tab (in Firefox, click the padlock icon in the address bar, then select More Information -> Technical Details).
• Under the Connection section, look for the field labeled Key exchange group or Key exchange.
• If the connection displays X25519MLKEM768, your browser and the remote server are actively exchanging session keys via hybrid post-quantum cryptography.
• Next, inspect the Certificate section in the exact same panel. You will observe that the certificate remains classical: typically PKCS #1 SHA-256 with RSA Encryption or ECDSA with SHA-256.

You can also test your browser against Cloudflare's dedicated cryptographic research endpoint by visiting https://pq.cloudflareresearch.com. The page performs an automated handshake analysis and reports whether your client supports hybrid post-quantum key agreement.

Probing Server-Side Readiness via OpenSSL

If you manage an origin server, load balancer, or reverse proxy, you must verify whether your server software supports post-quantum key exchange when queried directly, bypassing any CDN caching layer.

Ensure you have OpenSSL 3.5 or later installed, and execute the following command:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 -groups X25519MLKEM768

Inspect the output:

• If the handshake succeeds and reports Negotiated Group: X25519MLKEM768, your server stack is fully capable of terminating post-quantum session keys directly at the origin.
• If the command fails, common causes include running an older OpenSSL 1.1.1 or 3.0 branch, having an explicit ssl_ecdh_curve directive in Nginx that restricts supported groups, or having an upstream firewall that drops ClientHello packets exceeding 1,400 bytes.

For Nginx servers running atop OpenSSL 3.5+, enabling hybrid key exchange requires ensuring your configuration file allows TLS 1.3 and permits modern curves:

ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

For environments utilizing Caddy or modern Go services compiled with Go 1.24+, X25519MLKEM768 is supported out of the box with zero configuration changes required.

Verifying Middlebox Resilience and Packet Fragmentation

Do not assume that because your server software supports ML-KEM, your end users can connect without issue. Internal corporate networks, branch office VPNs, and cloud security gateways must be explicitly tested.

Audit your network path by generating deliberate handshake flights of varying sizes. Monitor firewall dropped-packet counters for TCP resets occurring specifically during the TLS connection phase. If your organization operates deep packet inspection proxies or TLS decryption appliances for threat monitoring, verify with the appliance vendor that firmware updates supporting FIPS 203 and RFC 10024 payloads have been applied.

The post-quantum migration is the largest cryptographic infrastructure transition in the history of computer networking. It will take a decade to complete. Navigating that transition without succumbing to either paralyzing anxiety or reckless complacency requires a clear, pragmatic strategy.

For web developers, site operators, and technology leaders, the actionable priorities divide into three clear operational tracks:

• Fortify the Wire (Immediate Priority: 2026): Ensure client-facing endpoints negotiate hybrid key exchange today. If you utilize a content delivery network such as Cloudflare, Fastly, or AWS CloudFront, ensure post-quantum features are active. If you manage direct origin servers, plan your upgrade path to OpenSSL 3.5+, AWS-LC, or BoringSSL. Enabling X25519MLKEM768 closes the harvest-now-decrypt-later vulnerability window for every visitor accessing your services.
• Conduct a Cryptographic Inventory (Medium-Term Priority: 2026–2028): Do not confuse browser-level TLS with organizational security. The default settings in Chrome and Cloudflare protect public web browsing, but they do nothing for your internal enterprise architecture. Begin compiling a comprehensive Cryptographic Bill of Materials across your digital estate: internal mutual-TLS connections, long-lived code-signing certificates, VPN gateways, and document encryption keys. DigiCert's global readiness surveys in 2026 revealed that while nearly 90 percent of enterprises have formulated post-quantum migration plans, fewer than 10 percent have deployed quantum-safe cryptography across their operational certificate fleets.
• Track Web PKI Standardization Without Forcing Deployment (Long-Term: 2028–2032): Do not attempt to deploy self-signed post-quantum certificates on public-facing production websites. The public Web PKI cannot accept them today, and forcing massive ML-DSA signatures into public handshakes will only degrade performance and trigger firewall drops for your users. Instead, monitor the progress of Merkle Tree Certificates within the CA/Browser Forum and browser root programs. When standardized post-quantum certificate mechanisms finally receive production support across browser root stores, adopting them will be as seamless as running an automated ACME renewal script.

We are living through a unique, fascinating moment in the evolution of internet security. The public web is currently balanced across two distinct eras of mathematics.

Down in the ephemeral trenches of the TLS session key exchange, the internet has already entered the post-quantum age. More than two-thirds of the human web traffic flowing across global fiber networks is protected by multi-dimensional lattice problems that would confound the most powerful quantum computer theoretical physics can envision.

Yet up in the identity layer of digital certificates, the web remains comfortably, deliberately classical. RSA and elliptic curves continue to authenticate the servers that anchor global commerce, held in place by the immutable packet physics of Ethernet MTUs and TCP slow-start.

Neither reality cancels out the other. The fact that digital certificates are not yet post-quantum does not diminish the immense triumph of having deployed hybrid key exchange to billions of people in under two years. And the fact that key exchange is secure does not excuse us from the massive engineering work required to rebuild the Web PKI before fault-tolerant quantum hardware arrives.

The most effective engineering teams in 2026 are those that recognize this duality. They audit their connections, verify their server configurations, and celebrate the silent protection already running inside their address bars—while keeping their eyes firmly focused on the long, unglamorous infrastructure work still waiting to be done.

Sources: Internet Engineering Task Force (IETF) RFC 10024 ("Hybrid Key Agreement for TLS 1.3"); National Institute of Standards and Technology (NIST) FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA); Cloudflare Engineering Research ("Post-Quantum Cryptography Adoption Metrics" and "Automatic Key Exchange for Origins"); Chromium Security Team ("Post-Quantum Web PKI Architecture and Merkle Tree Certificates"); CA/Browser Forum Server Certificate Working Group proceedings.