Hi all, I've posted a -00 that tries to address the problem underneath ever-shorter certificate lifetimes: revocation that clients can't rely on.
https://datatracker.ietf.org/doc/draft-davey-tls-braid/ The core idea is to make a certificate's freshness a precondition of use, controlled by the owner rather than a queried status service. A short-lived Delegated Credential (RFC 9345, unchanged) carries the freshness; the keys it may use are listed in a DNSSEC-signed record under the owner's domain. A certificate validates only while its live credential is authorized there — withdraw the record and validity lapses within the freshness window. No OCSP, no CRL, no CA round-trip. Because exposure is bounded by that window rather than by notAfter, the same mechanism makes much longer certificate lifetimes safe. Two properties I've tried hard to preserve: - Reuse over reinvention. It composes Delegated Credentials, the TLS Feature extension (RFC 7633), RFC 3779 resource types, CT structures, and DNSSEC — no new short-lived key format, no new transparency log. - No harm to anyone who hasn't adopted it. Support is negotiated, so a BRAID certificate is only ever presented to a client that offered to validate it; every legacy client sees an ordinary certificate. Optional strands add a use-time routing check (RFC 3779 / RPKI) and an independent third-party witness. I'd genuinely value review, and critical review most of all. The load-bearing parts are the negotiation / downgrade analysis and the Identity-strand construction (what the DNSSEC anchor names, and why a stolen end-entity key isn't enough on its own) — those are where I'd most like to be told I'm wrong. I'd rather find the next problem here than later. I'm also building a Phase 0 monitor for the IETF 126 Hackathon in Vienna that checks the served credential against the DNSSEC anchor, on real infrastructure. Anyone curious is welcome to follow along or stop by: https://github.com/braid2026/BRAID Thanks, George Davey [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
