TLS G. Davey Internet-Draft Davey Group LLC Intended status: Standards Track 3 July 2026 Expires: 4 January 2027 Bound Routing, Authority, and Identity Data (BRAID): Multi-Strand TLS Certificates with Structural, Owner-Controlled Revocation draft-davey-tls-braid-00 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. Davey Expires 4 January 2027 [Page 1] Internet-Draft BRAID Multi-Strand Certificates July 2026 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Security goals . . . . . . . . . . . . . . . . . . . . . 5 1.2. The braid metaphor and the strands . . . . . . . . . . . 5 1.3. BRAID profiles . . . . . . . . . . . . . . . . . . . . . 6 1.4. Requirements language . . . . . . . . . . . . . . . . . . 6 2. Security Invariant . . . . . . . . . . . . . . . . . . . . . 7 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Negotiation and Certificate Selection . . . . . . . . . . . . 9 5. The BRAID Binding Certificate Extension . . . . . . . . . . . 10 6. What Each Strand Signs . . . . . . . . . . . . . . . . . . . 12 7. The Identity Strand: Owner-Controlled Liveness via Anchored Delegated Credentials . . . . . . . . . . . . . . . . . . 13 7.1. Construction . . . . . . . . . . . . . . . . . . . . . . 13 7.2. The two-key security property . . . . . . . . . . . . . . 14 7.3. Delegated name constraints . . . . . . . . . . . . . . . 15 Davey Expires 4 January 2027 [Page 2] Internet-Draft BRAID Multi-Strand Certificates July 2026 8. The Routing Strand: Resolver-Validated Origin and Address Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. The Witness Strand: Appointed Co-Signing and Ledger Pairing . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Witness eligibility and independence . . . . . . . . . . 19 9.2. Witnessed freshness . . . . . . . . . . . . . . . . . . . 19 9.3. Public verifiability with private use . . . . . . . . . . 20 10. Proof Transport: braid_chain and Reference-Based Caching . . 20 10.1. Resource management and denial of service . . . . . . . 21 11. Structural Revocation and Revocation Transparency . . . . . . 22 12. Validity Period . . . . . . . . . . . . . . . . . . . . . . . 22 13. Deployment Model and Graceful Degradation . . . . . . . . . . 23 14. Deployment Phases: Running Today, Strengthening Over Time . . 24 15. Deployment Profiles . . . . . . . . . . . . . . . . . . . . . 26 16. Comparison with Related Mechanisms . . . . . . . . . . . . . 27 17. Performance Considerations . . . . . . . . . . . . . . . . . 29 17.1. Handshake size and the initial congestion window . . . . 29 17.2. Cold start and caching . . . . . . . . . . . . . . . . . 30 17.3. Client computation . . . . . . . . . . . . . . . . . . . 31 17.4. Amplification and QUIC . . . . . . . . . . . . . . . . . 31 17.5. Server cost . . . . . . . . . . . . . . . . . . . . . . 31 18. Cryptographic Agility and Post-Quantum Migration . . . . . . 32 19. Security Considerations . . . . . . . . . . . . . . . . . . . 32 20. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 34 21. Implementation Status . . . . . . . . . . . . . . . . . . . . 34 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 23.1. Normative References . . . . . . . . . . . . . . . . . . 35 23.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction The maximum validity period of publicly trusted TLS certificates has been reduced repeatedly and is scheduled to reach 47 days. The stated motivation is to limit the exposure window of a stolen or mis- issued certificate. This is a direct consequence of a deeper failure: certificate revocation, the mechanism intended to cancel a bad certificate before its natural expiry, has never worked reliably at internet scale. Online status checks (OCSP) have been deprecated by major browsers for privacy, latency, and "soft-fail" reasons, and traditional certificate revocation lists are not consulted in a way that protects users. Shortening certificate lifetimes is a mitigation, not a remedy. It imposes a permanent operational burden that falls hardest on small and independent operators, and it does not repair the underlying Davey Expires 4 January 2027 [Page 3] Internet-Draft BRAID Multi-Strand Certificates July 2026 mechanism. This document takes the opposite approach: rather than making certificates expire quickly so that broken revocation matters less, it makes revocation structural and owner-controlled so that certificates can safely live for years. The core observation is that today's external checks are optional: a TLS client will accept a certificate even when revocation information is unavailable. The TLS Feature extension [RFC7633] ("must-staple") demonstrated the right structural idea --- a validation requirement signed into the certificate by the CA, which an on-path attacker cannot strip --- but it failed in deployment because the requirement pointed at an unreliable dependency: a third-party OCSP responder whose outages made hard-fail enforcement untenable, so clients enforced it softly or not at all. BRAID retains the signed- requirement mechanism and replaces the dependency. The evidence a BRAID certificate requires is published and refreshed by the certificate's own owner, under keys and infrastructure the owner controls, so the party that bears the availability risk is the party with the power and incentive to manage it. An on-path attacker can withhold a strand but cannot make the certificate validate without it; a certificate missing a required strand is invalid. Fail-closed is achieved by construction, subject to the bounded graceful- degradation policy of Section 13. Two design principles shape this revision. First, reuse over reinvention: BRAID does not define a new short-lived key format, a new requirement-flag extension, a new encoding for network resources, or a new transparency-log format; it composes Delegated Credentials [RFC9345], the TLS Feature extension [RFC7633], the resource-encoding ASN.1 types of [RFC3779], and the Certificate Transparency structures [RFC6962]/[RFC9162], each of which has deployed parsers and operational history. Second, keep expensive validation off the client's critical path: browsers do not parse DNSSEC or RPKI in band; those functions live at the resolver and in dedicated relying-party software, where they already run today. BRAID changes nothing for parties that do not adopt it, and --- because support is negotiated (Section 4) --- deploying it breaks nothing for parties that have not yet adopted it. A client signals in its ClientHello that it can validate BRAID; a server presents a BRAID certificate only to such clients and presents a conventional certificate to all others. A CA may keep issuing short-lifetime certificates unchanged, and a client that does not implement BRAID validates ordinary certificates exactly as before. The mechanism is purely additive --- an enhanced option a CA MAY offer and an operator MAY adopt to obtain long-lived, structurally revocable certificates in exchange for running the supporting machinery. It is therefore complementary to, not a replacement for, the prevailing move toward Davey Expires 4 January 2027 [Page 4] Internet-Draft BRAID Multi-Strand Certificates July 2026 shorter lifetimes: the two can coexist, and each operator chooses the trade-off that fits it rather than being moved onto a single path. Deployment is correspondingly phased (Section 14): the earliest phase runs entirely on infrastructure deployed today, requiring no new client, CA, or protocol code, and every subsequent phase delivers standalone security value rather than a promise redeemed later. 1.1. Security goals BRAID aims to provide, for operators that opt in: * Structural revocation: a certificate cannot be used once its owner-controlled freshness evidence lapses, without reliance on a queried status service. * Owner-controlled revocation: the domain holder, not only the CA, can neutralize a certificate within a bounded freshness window. * Multiple independent trust anchors: forging a valid certificate requires defeating more than one of the WebPKI, the DNSSEC hierarchy, and the routing system; and using a stolen end-entity key requires additionally compromising the owner's DNSSEC-signed zone (Section 7). * Long-lived, low-churn certificates: validity periods of multiple years without increasing the practical exposure window. * Incremental, reversible, negotiated deployment: enforcement can be adopted in stages, with telemetry, without breaking any reachable site or any legacy client. * Reuse over reinvention: the requirement flag, short-lived keys, network-resource encoding, transparency structures, and routing validation all rely on existing standards. 1.2. The braid metaphor and the strands A single strand is weak; strands woven together are strong, and the braid unravels if any required strand is cut. BRAID defines a base of two strands plus optional enhancement strands an operator MAY add when the deployment and threat model warrant. Each strand is an independent attestation anchored in a distinct trust system: * *Authority strand* (base) --- the X.509 certificate signed by a publicly trusted CA [RFC5280], logged to Certificate Transparency [RFC6962]/[RFC9162]. Davey Expires 4 January 2027 [Page 5] Internet-Draft BRAID Multi-Strand Certificates July 2026 * *Identity strand* (base) --- an owner-controlled freshness authorization: a short-lived Delegated Credential [RFC9345] whose public key is authorized in a DNSSEC-signed BRAID Anchor record under the domain holder's control (Section 7). * *Routing strand* (optional) --- an assertion, checked against the client's locally validated routing data, that the connection originates from a network authorized in the Resource Public Key Infrastructure (RPKI) [RFC6480]/[RFC6482], optionally narrowed to a specific IP prefix or single address, expressed in the certificate using the ASN.1 resource types of [RFC3779] carried inside the BRAIDBinding extension (Section 8). * *Witness strand* (optional) --- a counter-signature from an appointed third party, anchored in a public log, a public blockchain, or a secured private ledger, encoded as a signed- timestamp structure in the manner of Certificate Transparency (Section 9). 1.3. BRAID profiles The strands compose into named profiles, each a strict superset of the previous one, so operators adopt only the assurance they need: * *BRAID-Base* --- Authority + Identity strands. Delivers owner- controlled, structural revocation (Section 11) and is the broadly deployable baseline. * *BRAID-Routed* --- adds the Routing strand (with optional address binding). Eligible for the extended validity period of Section 12. * *BRAID-Witnessed* --- adds the Witness strand, with an optional private-use mode that keeps a certificate publicly verifiable while gating its use to authorized parties (Section 9). Profiles above BRAID-Base are enhanced options, not requirements; a relying party enforces a strand only when it is marked REQUIRED in the certificate or by the relying party's own policy. 1.4. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Davey Expires 4 January 2027 [Page 6] Internet-Draft BRAID Multi-Strand Certificates July 2026 2. Security Invariant BRAID validation reduces to a single rule. Let R be the set of strands marked REQUIRED by the certificate or by relying-party policy. A certificate is valid for a connection if and only if every required strand validates for that connection: valid(cert, connection) <=> for all s in R : verify(s, cert, connection) = TRUE This is a logical conjunction: there is no strand whose failure can be compensated for by another. The only relaxation permitted is the bounded graceful-degradation policy of Section 13, and only when the relying party's configured policy explicitly allows it. 3. Threat Model BRAID is designed against the following adversaries. Each row states the attack and the strand or mechanism that mitigates it. +================+=================================================+ | Attack | Primary mitigation | +================+=================================================+ | Stolen end- | Identity strand: the DNSSEC-signed BRAID Anchor | | entity private | authorizes specific Delegated Credential keys; | | key | a thief holding only the end-entity key cannot | | | place a credential key of their own into the | | | owner's signed zone, so credentials the thief | | | mints are rejected (Section 7) | +----------------+-------------------------------------------------+ | Stolen | Bounded by the freshness window (at most seven | | Delegated | days); owner rotates the Anchor to exclude it | | Credential key | immediately | +----------------+-------------------------------------------------+ | Mis-issued or | Identity strand mismatch with the owner's BRAID | | fraudulent | Anchor; Certificate Transparency and Revocation | | certificate | Transparency logging | +----------------+-------------------------------------------------+ | CA compromise | Independent Identity strand: a CA-signed | | | certificate not authorized by the owner's | | | DNSSEC anchor does not validate | +----------------+-------------------------------------------------+ | DNS/DNSSEC | Authority strand (CA validation) and, where | | compromise at | present, Routing strand remain independent | | the owner's | anchors; forging a usable certificate | | zone | additionally requires a CA-signed certificate | | | and its private key | +----------------+-------------------------------------------------+ | Simultaneous | Witnessed freshness (optional): the witness's | Davey Expires 4 January 2027 [Page 7] Internet-Draft BRAID Multi-Strand Certificates July 2026 | compromise of | renewal lever is independent of both and stops | | the owner's | the certificate within one window (Section 9.2) | | DNS and the | | | end-entity key | | +----------------+-------------------------------------------------+ | BGP hijack at | Routing strand: origin-AS check against locally | | connection | validated RPKI data; optional address binding | | time (use-time | (Section 8) | | hijack) | | +----------------+-------------------------------------------------+ | BGP hijack to | Primarily mitigated at issuance by the CA/ | | pass domain- | Browser Forum requirement for Multi-Perspective | | control | Issuance Corroboration; the Identity strand | | validation at | independently rejects the resulting | | issuance | certificate, whose credentials the owner's | | | Anchor never authorized | +----------------+-------------------------------------------------+ | Stale or | Structural freshness: absence of current | | unreachable | evidence fails the handshake within the | | revocation | freshness window | +----------------+-------------------------------------------------+ | Use of a valid | Witness strand private-use mode: authorization | | certificate by | gate on session establishment | | an | | | unauthorized | | | party | | +----------------+-------------------------------------------------+ | Downgrade to a | BRAID Policy record and preloaded BRAID- | | non-BRAID | required set (Section 4) | | certificate | | | against a | | | BRAID-capable | | | client | | +----------------+-------------------------------------------------+ | Registry/ | Graceful-degradation policy (Section 13) with | | resolver | proof-of-outage, bounded by relying-party | | outage causing | policy | | mass failure | | +----------------+-------------------------------------------------+ Table 1 The Identity strand's headline property is stated precisely in Section 7: neutralizing it requires the compromise of two independently held secrets --- the end-entity private key and the ability to publish in the owner's DNSSEC-signed zone --- not either alone. Davey Expires 4 January 2027 [Page 8] Internet-Draft BRAID Multi-Strand Certificates July 2026 4. Negotiation and Certificate Selection BRAID requires TLS 1.3 or later [RFC8446]; the Identity strand inherits this floor from Delegated Credentials, which are defined only for TLS 1.3 [RFC9345]. The BRAIDBinding extension is critical (Section 5), so a client that does not implement BRAID will reject a BRAID certificate. BRAID therefore MUST be negotiated, and a server MUST NOT present a BRAID certificate to a client that has not offered to validate it. *Client signal.* A BRAID-capable client offers the braid_chain extension (Section 10) in its ClientHello, alongside the delegated_credential extension of [RFC9345] that the Identity strand requires. The presence of braid_chain in the ClientHello is the client's declaration that it implements this document and will enforce the certificate's required strands. *Server certificate selection.* A server operating a BRAID deployment holds both a BRAID certificate and a conventional certificate for the same identity (or serves populations of clients through distinct endpoints). If the ClientHello offers braid_chain, the server SHOULD select the BRAID certificate and respond with the braid_chain extension; otherwise it MUST select the conventional certificate and complete an ordinary TLS 1.3 handshake [RFC8446]. This mirrors the certificate-selection model already deployed for Delegated Credentials and for signature-algorithm negotiation, and it means BRAID adoption is invisible to every legacy client, crawler, and embedded device. *Operational isolation of the BRAID certificate.* The remaining deployment risk is server-side misconfiguration: a default- certificate rule, an unsynchronized load-balancer fleet, or an SNI- routing error that serves the BRAID certificate to a client that never offered braid_chain. A BRAID certificate MUST NOT be configured as the default or fallback certificate of any listener; it is selected only on an affirmative braid_chain offer, and a server that cannot determine the offer state MUST serve the conventional certificate. Two properties bound the residual risk. The failure direction is safe: a legacy client shown a BRAID certificate rejects it loudly on the unrecognized critical extension --- a hard, visible handshake failure, never a silent acceptance with weakened validation. And the failure is observable before it matters: the misconfiguration manifests as a spike of such alerts in exactly the aggregate reporting that the monitor phase of Section 13 requires operators to run before enforcement. Davey Expires 4 January 2027 [Page 9] Internet-Draft BRAID Multi-Strand Certificates July 2026 *Downgrade resistance.* Negotiation creates a first-contact downgrade surface: an attacker who has stolen a conventional certificate for the domain could strip the client's braid_chain offer or simply answer with the stolen conventional certificate. BRAID closes this in three graduated ways. First, the owner publishes a DNSSEC-signed BRAID Policy record (Section 13) whose strict mode instructs BRAID- capable clients that the domain MUST present a BRAID certificate; a BRAID-capable client that has validated such a record MUST reject a conventional certificate for that domain. Second, domains MAY be enrolled in a preloaded BRAID-required set distributed with client software, in the manner of HSTS [RFC6797], which protects even the first contact. Third, a client SHOULD cache a domain's observed BRAID policy for its stated lifetime, so that any subsequent downgrade within that lifetime fails. Note that the conventional certificate a BRAID operator holds for legacy clients is, by design, short-lived under prevailing root-program rules, so the residual downgrade exposure against BRAID-capable clients is bounded by the shorter of the policy-record lifetime and the conventional certificate's own lifetime. *Coexistence rationale.* This dual-certificate model is a feature, not a transition cost: the long-lived BRAID certificate eliminates renewal churn for the population of clients that can enforce its guarantees, while the conventional certificate covers the long tail. As BRAID-capable clients become the majority, the conventional certificate becomes a fallback artifact whose short lifetime matters less because it serves less traffic. 5. The BRAID Binding Certificate Extension A BRAID certificate carries a critical X.509 extension, BRAIDBinding, declaring which strands are REQUIRED and the minimal parameters needed to locate and verify them. Because the extension is marked critical [RFC5280], any client that does not understand BRAID MUST reject the certificate rather than treat it as an ordinary certificate; this prevents a silent downgrade to single-strand validation. Presentation of such a certificate to non-BRAID clients is prevented by the negotiation of Section 4, so criticality never strands a legacy client. BRAID deliberately keeps BRAIDBinding small by expressing every parameter that has an existing, deployed X.509 encoding in that encoding rather than a new one: * *Requirement flag.* In addition to the criticality of BRAIDBinding itself, the certificate SHOULD carry the TLS Feature