%% You should probably cite draft-davey-tls-braid-01 instead of this revision.
@techreport{davey-tls-braid-00,
    number =    {draft-davey-tls-braid-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-davey-tls-braid/00/},
    author =    {George Davey},
    title =     {{Bound Routing, Authority, and Identity Data (BRAID): Multi-Strand TLS Certificates with Structural, Owner-Controlled Revocation}},
    pagetotal = 40,
    year =      ,
    month =     ,
    day =       ,
    abstract =  {This document defines BRAID, a negotiated profile and set of protocol mechanisms for publicly trusted TLS server certificates whose continued validity is bound to multiple independent "strands": the issuing certificate authority's signature (the Authority strand), an owner-controlled, DNSSEC-anchored freshness authorization carried by a short-lived Delegated Credential (the Identity strand), and an optional routing assertion that constrains the certificate to a network origin authorized in the global routing system (the Routing strand). An optional Witness strand adds an appointed third-party co-signature. The requirement to satisfy each strand is signed into the certificate, so the strands are load-bearing rather than advisory: a certificate that is missing or has a withdrawn required strand simply does not validate, and revocation becomes structural and owner-controlled rather than an optional status check. Impersonating a protected domain requires the concurrent compromise of two independently held credentials --- the end-entity key and the owner's DNS publication path --- not either alone. Because a compromised certificate can be neutralized within a short freshness window, BRAID certificates MAY be issued with multi-year validity periods, subject to root-program policy. BRAID support is negotiated in the handshake, so a server presents a BRAID certificate only to a client that offers to validate it and presents a conventional certificate otherwise; deployment therefore breaks no existing client. To remain deployable, BRAID reuses existing standards and certificate structures rather than reinventing them: short-lived keys use Delegated Credentials (RFC 9345); the requirement flag reuses the TLS Feature extension (RFC 7633); routing constraints reuse the ASN.1 resource types of RFC 3779 inside BRAID's own extension; witness attestations reuse the Certificate Transparency signed-timestamp and Merkle-log formats; routing validation is delegated to the client's RPKI-validating resolver rather than performed in band; large validation proofs are transported by reference with client-side caching to stay within the initial congestion window; and enforcement is staged from monitor to strict using a policy model adapted from SPF, DKIM, and DMARC, including a graceful-degradation mode that bounds the availability risk of fail-closed operation.},
}