Davey Group LLC 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.