What we have put to the standards bodies
Work we are arguing for, not work that has been accepted. Each proposal carries the whole evidence base behind it: the papers, the vulnerability corpus, the experiments and the public repositories, so the argument can be checked rather than taken on trust.
A proposal is not a standard. Nothing on these pages has been adopted by the IETF, the IAB, NIST or anyone else, and each page says so at the top. We publish them because an argument put to a standards body should be checkable by everyone, not just by the people in the room.
- SubmittedAug 28, 2026
What must a resumed TLS connection re-check?
TLS 1.2 required a server to refuse a resumption whose name had changed. TLS 1.3 removed that rule and never replaced it. Post-quantum makes the gap expensive.
Our position paper to the IAB Workshop on Accelerating the Deployment of Post-Quantum Authentication, with the whole evidence base: eleven CVE identifiers across eight pieces of software, reproductions against current releases, a fourteen-host measurement of public endpoints, and what conforming would save a deployment that cannot safely resume today.
Read the proposal and its evidence - SubmittedJul 27, 2026
A well-known URI for publishing cryptographic posture
There is no way to ask a deployment what cryptography it runs and get an answer a machine can check. This proposes one, at /.well-known/crypto-agility.json, modelled on security.txt.
Our individual Internet-Draft defining a small JSON document that a site or repository publishes at a predictable URL to declare its cryptographic posture: a readiness summary, a pointer to a CycloneDX CBOM, an optional attestation link, and the migration deadlines it declares it is measured against. Filed with the IETF, not adopted by any working group, and published to be argued with.
Read the proposal and its evidence