[TLS] Re: BRAID IETF 126 Hackathon

Here's the latest — draft-davey-tls-braid-01, attached. Substantial restructure of -00 in response to Eric Rescorla's review: - Authorization and revocation latency are now separated. The base profile publishes one static DNSSEC-signed record and requires no recurring operation; the mandatory 7-day credential refresh in -00 is now an optional enhancement (§10). - §8 states the Two-Control Property: because the anchor authorizes credential keys rather than the end-entity key, impersonation requires both the EE key and the ability to publish in the owner's zone. §17.1 uses this to distinguish BRAID from TLSA usage 1. - §1.3 states the costs plainly: operators run conventional certificates alongside during any transition, and the DNSSEC dependency is real and unresolved. - §18 is honest that the wire formats are not yet specified. Feedback welcome, particularly on §14 (DNSSEC validation modes) and §9 (revocation latency bounds). George

From: George Davey <[email protected]>
Sent: Saturday, July 18, 2026 12:17 PM
To: Nico Frati <[email protected]>
Cc: <[email protected]> <[email protected]>
Subject: [TLS] Re: BRAID IETF 126 Hackathon

 EXTERNAL
________________________________
Hi, Thanks for the interest — glad to have you. Quick status: -01 goes up as soon as the pre-meeting submission window reopens. It's a substantial restructure, not a tidy-up, so it's worth waiting for rather than reading -00. Draft: https://datatracker.ietf.org/doc/draft-davey-tls-braid/ Code: https://github.com/braid2026/BRAID The idea in one line: build independent circuit breakers into ordinary web certificates, so that any authorization the owner appoints can be withdrawn to invalidate the certificate — and because invalidation is reliable and doesn't involve the CA, the certificate no longer has to be short-lived. What changed in -01, and why it matters if you're thinking about contributing: Eric Rescorla reviewed -00 and pointed out that its mandatory 7-day credential refresh just relocated the renewal treadmill rather than removing it — which was the opposite of my intent. -01 separates authorization (published once, persists until withdrawn) from revocation latency (how fast a withdrawal propagates). In the base profile you publish one DNSSEC-signed record and then do nothing; short-interval refresh is now an optional enhancement. -01 also concedes openly what it costs: you run conventional certs alongside during any transition, and the DNSSEC dependency is real and unsolved. So the design is genuinely live right now, which I think makes this a good moment to jump in rather than a bad one. The open questions I'd most value help on for -02: - Wire formats — the braid_chain extension, the BRAIDBinding extension, and the Anchor record are deliberately unspecified in -01. That's the biggest concrete gap. - Revocation latency: what bound is defensible, and how should relying party caching be constrained? - The DNSSEC validation modes in §14 — whether the "validated material" mode is actually workable for general clients. - Whether owner-appointed third-party invalidation (the Witness strand) is a feature or a liability. If any of that is your area, say so and I'll loop you in directly. Happy to talk through any of it before -01 even lands. Thanks, George

From: Nico Frati <[email protected]<mailto:[email protected]>>
Sent: Saturday, July 18, 2026 4:32 AM
To: George Davey <[email protected]<mailto:[email protected]>>
Subject: BRAID IETF 126 Hackathon

 EXTERNAL
________________________________
Hello George, nice to meet you!

I'm Nico Frati, I was interested to help getting BRAID phase 0 done, but I couldn't seem to find the project on the hackathon room, is there another place where the team is at?

Thanks,
Nico

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]