# Certificate Transparency Logs and PQC **Source**: https://quantumsequrity.com/blog/certificate-transparency-pqc **Category**: Operations --- [← Back to Blog](../../blog.html) Operations # Certificate Transparency Logs and PQC 10 min read Certificate Transparency, defined in RFC 9162 (and earlier RFC 6962), is the public record of every TLS certificate issued by a participating CA. The logs are append-only, cryptographically auditable, and have been a quiet success of internet infrastructure since deployment in the mid-2010s. CT logs catch misissued certificates, support browser revocation logic, and provide a forensic record that has been used in many security investigations. When PQC enters this picture, three things change. The certificates being logged are larger. The signatures on log entries (the Signed Certificate Timestamps, or SCTs) may eventually become PQ. And the log infrastructure itself, which signs Merkle tree heads, will need PQ-resistant signing. This article walks through what CT logs do today, how PQC affects each component, and what operators of CT-dependent systems should plan for. ## What CT Logs Do A CT log accepts certificate submissions from CAs and produces: 1. **A Signed Certificate Timestamp (SCT)**: A short signed receipt for each accepted certificate. The CA includes the SCT in the issued certificate (or in the OCSP response or TLS extension). 2. **A Merkle tree of all submitted certificates**: Periodically, the log signs a Signed Tree Head (STH) attesting to the current state of the tree. 3. **An auditable record**: External monitors can ask the log for inclusion proofs and cross-check that all logged certificates appear in subsequent STHs. The cryptographic primitives: - **SCT signature**: Currently ECDSA with P-256 or RSA, depending on the log. - **STH signature**: Same. - **Merkle tree hash**: SHA-256 (RFC 6962) or any approved hash for RFC 9162. For chrome's CT policy, every publicly trusted certificate must be logged in at least two CT logs and accompanied by SCTs. ## Bigger Certificates in CT Logs The first PQ effect on CT is purely structural: bigger certificates mean bigger log entries. A classical certificate with ECC public key and ECC CA signature might be 1-2 KB. A hybrid certificate with ML-DSA-65 + Ed25519 signature and ML-KEM + X25519 public key can easily be 6-8 KB. A pure PQ certificate even larger. For CT log operators, this means: - **More storage per certificate**. Linear scaling. - **More bandwidth per query**. CT logs serve historical certificates on demand. - **More cost per Merkle leaf hash**. The hashing is cheap, but the leaf data is bigger. - **More cost for inclusion proofs**. Proofs are leaf hashes plus tree path; the leaves carry the certificate data. Major CT logs (Google's Argon and Xenon, Cloudflare's Nimbus, DigiCert's Yeti, etc.) ingest hundreds of millions of certificates per year. Doubling or tripling the per-cert storage matters for operational cost. Expect log operators to invest in storage capacity ahead of PQ rollout. ## PQ Signatures on SCTs The SCT itself is a small artifact: log identifier, timestamp, signature. With ECDSA P-256, the SCT signature is 64-72 bytes. With ML-DSA-65, it would be ~3.3 KB. Why does this matter? Browsers fetch SCTs as part of TLS handshakes. SCTs are typically included via: 1. **X.509 SCT extension**: SCTs embedded in the certificate itself. 2. **TLS extension**: Server presents SCTs during the handshake. 3. **OCSP stapling**: SCTs included in the stapled OCSP response. Each delivery mechanism has size constraints. A 3.3 KB SCT signature multiplies the size of these mechanisms. With three SCTs per certificate (typical for browser policy compliance), the SCT bundle is 10 KB+. CT log operators are watching this carefully. The current path appears to be: - **Continue with classical SCT signatures during transition**. The SCT is a short-lived attestation; the underlying certificate can be PQ even if the SCT is classical. - **Move SCTs to PQ when warranted by threat model**. The SCT does not protect data confidentiality; it protects against fraudulent certificate issuance. The threat to SCTs is forgery of a "this cert was logged" claim. A reasonable estimate: SCT signatures will move to hybrid (ECDSA + ML-DSA) before pure PQ. Pure PQ SCTs are unlikely before late 2020s. ## Merkle Tree Hash and STH Signature The Merkle tree hashing in CT logs is SHA-256 (RFC 6962) or any approved hash for RFC 9162. SHA-256 has roughly 128-bit security against quantum collision attacks (Brassard-Hoyer-Tapp), which is generally considered acceptable for log integrity. Some thinking suggests upgrading to SHA-384 or SHA-512 for the Merkle tree hash to provide more headroom against potential improvements in quantum collision-finding. RFC 9162 allows hash algorithm negotiation, so upgrading is feasible. The STH signature is the more pressing concern. The STH attests to the current state of the log; forging an STH would let an attacker present a different log state to different observers (a "split-view" attack). The STH signing key is high-value. Migration path for STH signing keys: 1. **Now**: ECDSA P-256 or RSA-3072. Acceptable. 2. **Year 1-2**: Add hybrid signature support (ECDSA + ML-DSA-65) on STHs. 3. **Year 3+**: Move to pure ML-DSA or Falcon for STH signing. This is a coordinated migration across CT log operators and CT-aware clients (browsers, monitors, auditors). ## Monitoring and Auditing in a PQ World CT logs depend on independent monitors and auditors. Monitors download new entries and check for misissued certificates. Auditors verify Merkle proofs to ensure log integrity. Tools widely used today: - **crt.sh** by Sectigo: a public CT search interface. - **Censys Universal Internet Dataset**: indexed CT data. - **Cloudflare Merkle Town**: visualization of CT log state. - **Google's CT monitoring tools**. These tools will need updates to handle PQ certificates and (eventually) PQ-signed log artifacts. The structural changes are largely transparent: parsers handle bigger certs, verifiers handle PQ signatures. The bandwidth and storage cost is the main operational concern. For organizations doing their own CT monitoring (a common pattern for security teams), expect: - More bandwidth to ingest CT updates. - More storage to hold the historical record. - New code paths to verify PQ signatures (when SCT and STH signing migrates). ## CT Log Policy and the PQ Transition Apple, Google, and Mozilla each maintain their own CT policy. These policies define which logs they trust, how many SCTs are required per certificate, and what minimum cryptographic strength is acceptable. Policy questions for the PQ transition: - **When do logs need to support PQ certificate ingestion?** Probably 2026-2027. - **When do logs need to use PQ-signed STHs?** Later, perhaps 2028-2030. - **What happens to legacy logs that do not migrate?** Likely deprecated, with their entries no longer accepted as proof of inclusion. Browser policies tend to be conservative and coordinated. Expect explicit deadlines and migration windows announced 12-24 months in advance. ## Internal CT for Enterprise PKI Some organizations run internal CT logs for their internal PKI. The motivation is similar to public CT: catch misissued internal certificates, provide an auditable record. Internal CT operators have more flexibility on PQ migration timing than public CT operators. Internal browsers and clients can be coordinated. The migration can be aligned with the broader internal PKI PQC roadmap. For internal CT, the PQ checklist: 1. **Storage**: Ensure capacity for larger PQ certificates. 2. **Signing**: STH signing keys move to PQ on the same schedule as the issuing CA. 3. **Verification**: Internal monitors and auditors handle PQ signatures. 4. **Documentation**: Internal CT policy documents updated to reflect PQ algorithms. ## Operational Recommendations For organizations that depend on CT (which is essentially everyone running TLS at scale): 1. **Inventory CT consumers**. Where in your infrastructure are SCTs verified? Ensure all of them can handle larger PQ-era SCTs. 2. **Test handshake size**. Stapling all SCTs and OCSP into the TLS handshake is the typical pattern. Test handshake size assuming PQ certs and SCTs. 3. **Update monitoring tools**. CT search and monitoring tools need updates. Pin versions, plan upgrades. 4. **Engage with CA roadmaps**. Your CAs publish CT logging policies. Track them. 5. **Plan for CT log churn**. Some logs will retire during the PQ transition. Have a process for adding new logs to your trusted set. ## Storage Cost Modeling for CT Operators Public CT logs absorb a relentless stream of new certificate submissions. Google's Argon and Xenon shards together accept tens of millions of new certificates per month. The operational cost of running a public log is dominated by storage, bandwidth, and compute for Merkle tree maintenance. A rough cost model assuming PQ ML-DSA-65 + Ed25519 hybrid certificates as the dominant submission class: - Average classical certificate: 1.5 KB. Average hybrid PQ certificate: 6.5 KB. Multiplier: 4.3x. - Argon-2024 ingested approximately 380 million certificates. At 1.5 KB average, that is 570 GB raw. At 6.5 KB hybrid, that becomes 2.5 TB raw. - With Merkle tree overhead (proofs, hashes, indexes), Google's actual storage footprint is roughly 3x raw. Hybrid PQ extrapolates to ~7.5 TB per year per shard. - Bandwidth for CT clients querying historical entries (monitors, auditors) scales similarly. Over a 10-year retention horizon, a single public log shard could grow to 75 TB or more. This is manageable for hyperscale operators (Google, Cloudflare, DigiCert all run on commodity object storage) but raises questions about smaller operators. For private CT logs at enterprise scale, the cost projections are similar in shape but smaller in absolute numbers. A medium-sized enterprise PKI might run an internal CT log with a few hundred thousand certificates per year. PQ hybrid certs push the storage from a few hundred MB to a few GB per year, well within commodity infrastructure budgets. ## Sharding and Horizontal Scaling CT logs use temporal sharding. Each shard accepts certificates whose notBefore date falls within a specific calendar year (Argon 2025, Argon 2026, etc.). When a shard fills its target window, it rotates and a new shard takes over. In a PQ era, sharding strategies may shift. Options under discussion: - **Smaller temporal shards**: Move from yearly shards to quarterly to keep individual shard sizes manageable. - **Algorithm-based sharding**: Separate logs for classical vs PQ certificates. Verifiers must check both. - **Compression**: CT logs do not compress submissions today (compression would break the tree integrity guarantees in obvious implementations). PQ certificates contain repetitive structures (algorithm OIDs, encoding overhead) that could compress well, but new RFC work would be needed to integrate compression cleanly. The IETF TRANS working group is the venue for these decisions. Public discussions on the trans@ietf.org mailing list track the evolution. ## RFC 9162 Algorithm Negotiation RFC 9162 (Certificate Transparency 2.0) added more flexible algorithm support than RFC 6962. The hash algorithm and signature algorithm are negotiable, allowing logs to advertise their capabilities and clients to verify accordingly. For PQ migration, this flexibility means: - A log can advertise classical SCT signatures while accepting PQ certificate submissions. - A log can later advertise PQ SCT signatures, with clients negotiating the appropriate verification. - Multiple logs in a CT system can use different algorithms during transition without breaking inclusion verification. The CT API (the HTTPS endpoints logs expose) carries algorithm identifiers in well-defined fields. Implementing PQ algorithm support requires updating the JSON schema for log responses but does not change the underlying RFC structure. ## Frequently Asked Questions **Will my SCT verification break with PQ certs?** Not initially. The SCT is signed by the log, not by the CA. SCTs remain classical-signed during the early PQ phase. The certificate inside the SCT can be PQ, but the SCT signature itself is classical. Verifiers handle this naturally. **Are CT logs vulnerable to quantum attack?** The Merkle tree hash (SHA-256) has roughly 128-bit post-quantum security via Grover's algorithm. The STH signature (ECDSA today) is broken by Shor's algorithm on a CRQC. So a future quantum adversary could forge STHs but cannot break the Merkle structure. Mitigation: migrate STH signing to PQ. **Do I need to do anything special about CT for QNSQY?** QNSQY's `.qs` format does not use X.509 certificates and therefore does not interact with CT logs. If you use TLS to connect to QNSQY services (e.g., the billing API), your TLS infrastructure handles CT in the usual way. **What is the bandwidth impact of PQ-era CT?** For CT log operators, expect 5-10x storage growth and similar bandwidth growth as PQ certificates dominate. For CT consumers (monitoring, auditing), similar increases. **Will RFC 9162 need a successor for full PQ?** Probably. RFC 9162 v1 was about ECDSA migration. A future revision will likely formalize PQ signing for SCTs and STHs. The IETF TRANS working group tracks this work. **Should I run my own CT log for an enterprise PKI?** For organizations with strict audit and compliance requirements, internal CT logs provide independent verification of CA behavior. Open-source CT log implementations (Trillian from Google, sectigo's CTLog) are available. Running an internal CT log is a multi-FTE operational commitment because the log must be highly available, append-only, and never serve inconsistent views. For most enterprises, relying on the existing public CT ecosystem combined with internal monitoring is more cost-effective. **How does CT relate to certificate revocation?** CT and revocation are separate mechanisms. CT records certificates as they are issued, providing a public audit trail. Revocation tracks which certificates have been revoked after issuance. The two together provide a complete picture of certificate state. PQ migration affects both: CT logs hold larger PQ certificates, and revocation infrastructure (CRLs, OCSP, CRLite) handles larger PQ signatures. See [CRL and OCSP at PQC Signature Sizes](crl-ocsp-pqc-scale.md). ## Sources 1. RFC 9162 (Certificate Transparency Version 2.0) — https://datatracker.ietf.org/doc/html/rfc9162 2. RFC 6962 (Certificate Transparency, the original) — https://datatracker.ietf.org/doc/html/rfc6962 3. Apple CT Policy — https://support.apple.com/en-us/103214 4. Google CT Policy — https://googlechrome.github.io/CertificateTransparency/log_policy.html 5. NIST FIPS 204 (ML-DSA Standard) — https://csrc.nist.gov/pubs/fips/204/final 6. IETF TRANS Working Group — https://datatracker.ietf.org/wg/trans/about/ 7. Trillian (Google's Append-Only Merkle Log Implementation) — https://github.com/google/trillian 8. NIST IR 8547, "Transition to PQC Standards" — https://csrc.nist.gov/pubs/ir/8547/final ## Related Articles - [Certificate Lifecycle Management and PQC](cert-lifecycle-pqc.md) - [CRL and OCSP at PQC Signature Sizes](crl-ocsp-pqc-scale.md) - [Crypto-Agility Explained](crypto-agility-explained.md) - [NIST FIPS Guide for Post-Quantum Cryptography](nist-fips-guide.md) - [Why RSA-2048 Will Break](why-rsa-2048-will-break.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)