Coping with post-quantum signatures in the WebPKI
summary
WebPKI requires six separate signatures during a TLS visit and most post‑quantum signature candidates are far from drop‑in: Falcon suffers floating‑point signing pitfalls, Sphincs adds ~50 KB and huge signing costs, UOV gives tiny signatures but ~66 KB root public keys. Practical workarounds evaluated include leave out intermediates (≈3 KB saved), switching the handshake to a KEM, and a concrete Merkle‑tree certificate design where CAs publish hourly batches and sign one Merkle root per batch.
AI-written summary · about
chapters (12)
- 0:00Post-quantum signatures in WebPKI
- 1:08Post-quantum signature algorithms
- 3:56NIST candidates and trade-offs
- 7:23Practical post-quantum deployments
- 9:33Coping with signature size
- 13:08Replacing TLS handshake signatures
- 17:06OCSP and revocation challenges
- 18:55Merkle Tree certificates solution
- 23:39WebPKI transition summary
- 24:22Q&A: Code-based signatures
- 26:28Q&A: Merkle Trees and censorship
- 28:16Q&A: Merkle Trees for operators
related talks
55mMaking PQ Signatures work in the WebPKI
36mPost-Quantum Cryptography for Digital Signing
29mWhy the Internet isn’t ready for Post-Quantum Certificates
27mTurning Quantum Threats into Opportunities: Modernizing WebPKI with QUIC and Metrics-Driven Insights
28mMixed Certificate Chains for the Transition to Post Quantum Authentication in PKI
26mCrypto-Agile PKI: A Strategic Blueprint for Post-Quantum Trust
36mpost-quantum isogeny signatures, explained in 30 memes or less
13mNavigating the Quantum Readiness Journey: Open-Source Cryptography, PKI and Signing Tools
