]> Davey Group LLC

BRAID@cpu.io

Security TLS certificate lifetime revocation delegated credentials DNSSEC RPKI certificate transparency DMARC 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.

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 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 ("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 . 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 , the TLS Feature extension , the resource-encoding ASN.1 types of , and the Certificate Transparency structures /, 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 () --- 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 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 (): 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.

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 ().
• 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.

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 , logged to Certificate Transparency /.
• Identity strand (base) --- an owner-controlled freshness authorization: a short-lived Delegated Credential whose public key is authorized in a DNSSEC-signed BRAID Anchor record under the domain holder's control ().
• 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) /, optionally narrowed to a specific IP prefix or single address, expressed in the certificate using the ASN.1 resource types of carried inside the BRAIDBinding extension ().
• 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 ().

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 () and is the broadly deployable baseline.
• BRAID-Routed --- adds the Routing strand (with optional address binding). Eligible for the extended validity period of .
• 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 ().

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.

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 when, and only when, they appear in all capitals.

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: 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 , and only when the relying party's configured policy explicitly allows it.

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-entity private key	Identity strand: the DNSSEC-signed BRAID Anchor authorizes specific Delegated Credential keys; 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 ()
Stolen Delegated Credential key	Bounded by the freshness window (at most seven days); owner rotates the Anchor to exclude it immediately
Mis-issued or fraudulent certificate	Identity strand mismatch with the owner's BRAID Anchor; Certificate Transparency and Revocation Transparency logging
CA compromise	Independent Identity strand: a CA-signed certificate not authorized by the owner's DNSSEC anchor does not validate
DNS/DNSSEC compromise at the owner's zone	Authority strand (CA validation) and, where present, Routing strand remain independent anchors; forging a usable certificate additionally requires a CA-signed certificate and its private key
Simultaneous compromise of the owner's DNS and the end-entity key	Witnessed freshness (optional): the witness's renewal lever is independent of both and stops the certificate within one window ()
BGP hijack at connection time (use-time hijack)	Routing strand: origin-AS check against locally validated RPKI data; optional address binding ()
BGP hijack to pass domain-control validation at issuance	Primarily mitigated at issuance by the CA/Browser Forum requirement for Multi-Perspective Issuance Corroboration; the Identity strand independently rejects the resulting certificate, whose credentials the owner's Anchor never authorized
Stale or unreachable revocation	Structural freshness: absence of current evidence fails the handshake within the freshness window
Use of a valid certificate by an unauthorized party	Witness strand private-use mode: authorization gate on session establishment
Downgrade to a non-BRAID certificate against a BRAID-capable client	BRAID Policy record and preloaded BRAID-required set ()
Registry/resolver outage causing mass failure	Graceful-degradation policy () with proof-of-outage, bounded by relying-party policy

The Identity strand's headline property is stated precisely in : 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.

Negotiation and Certificate Selection BRAID requires TLS 1.3 or later ; the Identity strand inherits this floor from Delegated Credentials, which are defined only for TLS 1.3 . The BRAIDBinding extension is critical (), 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 () in its ClientHello, alongside the delegated_credential extension of 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 . 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 requires operators to run before enforcement. 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 () 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 , 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.

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 , 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 , 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 extension listing the braid_chain ExtensionType, declaring in the long-standing "must-staple" idiom that the handshake is required to include the BRAID material. This gives middleware and audit tooling that already parses visibility into the requirement without new code.
• Routing parameters. The authorized origin AS number(s) and any bound IP prefixes or host addresses are carried in a BRAIDRoutingConstraints field native to BRAIDBinding, whose syntax imports the IP-address-block and AS-identifier ASN.1 types of verbatim --- but deliberately not that RFC's extension object identifiers. The distinction is semantic, not cosmetic: an extension asserts resource holdership, validated by containment up the IANA-to-RIR delegation chain, and a WebPKI CA has no authority in that hierarchy and performs no such validation. What a BRAID certificate carries is a different claim entirely --- a subscriber-requested usage constraint on where the certificate may be served from --- and encoding it under the OIDs would misstate the claim, confuse RPKI relying-party tooling that treats those OIDs as holdership assertions, and force a criticality deviation from 's own rules. Importing the types keeps the hardened parsers and the operational familiarity; keeping the field native to BRAIDBinding keeps the two PKI architectures semantically insulated from each other.
• Locators. The DNS name of the BRAID Anchor record, the URI of the proof repository, and the Witness ledger locator are carried as GeneralName access descriptors in the Subject Information Access extension, reusing the access-method pattern of rather than bespoke fields.
• Delegated name constraints. The constraint set of reuses the GeneralSubtrees syntax of the Name Constraints extension, carried inside BRAIDBinding (because Name Constraints proper is defined only for CA certificates). Matching follows .
• Witness parameters. The co-signer identity and inclusion-proof parameters reuse the SignedCertificateTimestamp and log-identifier structures of / ().

What remains native to BRAIDBinding is therefore minimal:

• a strand bitmap indicating which of {Identity, Routing, Witness} are REQUIRED (the Authority strand is always present);
• the BRAIDRoutingConstraints field where the Routing strand is used, including its validation-method parameter ();
• the maximum acceptable age of the freshness evidence (the freshness window), not to exceed the Delegated Credential maximum of seven days ;
• OPTIONALLY the delegated name-constraint GeneralSubtrees ();
• OPTIONALLY a witness-freshness flag and interval ();
• OPTIONALLY a private-use flag and parameters (); and
• the policy mode and degradation parameters under which the certificate was issued ().

This reuse is a deployment argument, not only an aesthetic one: a CA's issuance pipeline and a client's validation library already contain hardened encoders and parsers for , the resource types, Subject Information Access, GeneralSubtrees, and SCT structures. The new parsing surface BRAID introduces is a single short sequence.

What Each Strand Signs To eliminate ambiguity, each strand is a signature over a defined structure:

• Authority strand --- the CA's signature over the X.509 TBSCertificate per , including the critical BRAIDBinding extension and the reused extensions of . The binding is therefore covered by the CA signature and cannot be altered without invalidating the certificate.
• Identity strand --- a Delegated Credential per , unchanged: a validity interval and a public key, signed by the end-entity certificate key, with the handshake signature produced by the Delegated Credential key. What BRAID adds is an authorization check, not a format: the credential's public key MUST be authorized by the owner's DNSSEC-signed BRAID Anchor record ().
• Routing strand --- no new signature on the critical path: the client compares the certificate's BRAIDRoutingConstraints origin-AS and address assertions () against routing data its resolver has already validated against the RPKI trust anchors. The RPKI objects themselves are signed by the Regional Internet Registries and validated off the handshake path ().
• Witness strand --- the co-signer's signature over the certificate's issuer, serial, and public key, encoded as a signed timestamp in the manner of , plus a Merkle inclusion proof against the ledger named in the certificate ().

The Identity Strand: Owner-Controlled Liveness via Anchored Delegated Credentials Traditional revocation fails because checking is optional and frequently soft-fails. BRAID makes freshness a precondition of use, while reusing a standard short-lived key mechanism rather than inventing one.

Construction The mechanism composes three parts, of which only the third is new:

1. The Delegated Credential, per unchanged. The server operator mints a short-lived credential --- a fresh public key and a validity interval not exceeding the freshness window (at most seven days) --- signed by the end-entity certificate's private key, exactly as specifies. The server signs the handshake with the credential's key.
2. The BRAID Anchor record. The domain holder publishes, in its DNSSEC-signed zone at the name given in the certificate (), a BRAID Anchor RRset listing the credential public keys (by hash) currently authorized to serve the domain. The RRset MAY list several keys to permit overlap during rotation, and SHOULD be updated once per rotation period through the same automation that mints the credentials (for example, alongside ACME operations , in the manner of CDS/CDNSKEY child-to-parent automation). Until the BRAID Anchor RRTYPE is widely supported by provisioning systems, the RRset MAY equivalently be published as a TXT record at the _braid prefix of the anchor name; SPF, DKIM, and DMARC each launched on TXT records and demonstrated that this path carries production traffic at internet scale, and a validator MUST treat a DNSSEC-validated TXT-form anchor as equivalent to the native RRTYPE during the transition.
3. The client's conjunctive check. A client requiring the Identity strand MUST verify all of: (a) the Delegated Credential validates under against the end-entity certificate; (b) the credential is within its validity interval and that interval does not exceed the certificate's freshness window; and (c) the hash of the credential's public key appears in the domain's DNSSEC-validated BRAID Anchor RRset. Failure of any check fails the strand.

Rotation at scale. The freshness window is only as safe as the rotation discipline behind it, and large anycast or multi-region fleets face real propagation lag: zone-signing latency, secondary-server synchronization, and resolver TTL caching all sit between an Anchor update and its global visibility. Three practices, borrowed from DNSSEC key-rollover operations, bound the fail-closed surface. The next window's credential key SHOULD be pre-published in the Anchor RRset before any server presents it (the pre-publish discipline of key rollover), so propagation completes while the previous key is still serving. The Anchor RRset's TTL SHOULD be a small fraction of the freshness window, so caches converge well inside it. And fleets SHOULD stagger credential validity across regions rather than expiring globally at one instant, so a delayed rotation degrades one region's headroom rather than the whole service. With pre-publication in place, the steady state always has at least two authorized keys in the Anchor --- current and next --- and an operator's rotation failure gives a full window of margin before any client fails closed.

The two-key security property The check in step 3(c) is what converts from a performance mechanism into a revocation mechanism, and its consequence deserves precise statement. An adversary who steals the end-entity private key can mint syntactically valid Delegated Credentials --- alone cannot prevent that, since the end-entity key is the delegator. But those credentials name adversary-chosen public keys, and the adversary cannot cause those keys to appear in the owner's DNSSEC-signed BRAID Anchor RRset without separately compromising the owner's DNS publication path. Conversely, an adversary who compromises the owner's zone can publish anchor entries but holds no CA-signed certificate and no end-entity key with which to mint a credential those entries would authorize. Impersonation therefore requires the simultaneous compromise of two independently held and independently operated secrets. Theft of a deployed credential key alone --- the most exposed key, living on front-line servers --- is bounded by the freshness window and is cured immediately by rotating the Anchor RRset to exclude it. To preserve this independence in practice, the DNS update credential used to publish the Anchor SHOULD NOT be resident on the TLS-terminating hosts that hold the end-entity or credential keys, and the zone's DNSSEC signing key SHOULD be operated per current best practice (offline or HSM-held where feasible). Revocation is then owner-controlled and structural: to revoke, the owner stops refreshing credentials and withdraws or empties the Anchor RRset; within the freshness window the certificate ceases to validate everywhere, with no dependence on a central status responder and no per-connection privacy leak.

Delegated name constraints A Delegated Credential inherits the full name scope of the end-entity certificate that signs it: provides no means to limit which of the certificate's identities a given credential may assert, nor the depth of further delegation. Where credentials are handed to a third party such as a CDN edge, this over-authorizes the holder --- a compromised edge credential can impersonate any name on the certificate, including sensitive subdomains, not only the names the edge legitimately serves. Because X.509 Name Constraints are issued by CAs and do not apply to Delegated Credentials, BRAID closes the gap at the policy layer: the delegated name constraints carried in the critical BRAIDBinding extension (), expressed in the GeneralSubtrees syntax of , enumerate the identities a credential is permitted to assert and, optionally, a maximum delegation depth. A client requiring the Identity strand MUST reject a Delegated Credential whose asserted identity falls outside this set (for example, permitting static.example.com while refusing the apex or auth.example.com). Matching follows : a name matches only if it equals a listed fully qualified name or is covered by a listed single-label wildcard, and a wildcard never matches the apex or a multi-label suffix. An empty or absent constraint set means the credential inherits the certificate's full name scope, exactly as under today, so the field is strictly additive. Matching is defined precisely enough to leave no edge ambiguity in multi-tenant deployments: comparison is performed on lowercase A-labels (the Punycode form for internationalized names), so that case and Unicode representation differences cannot produce divergent match results; a wildcard is permitted only as the entire left-most label --- partial-label wildcards, including any wildcard within an A-label such as xn--*, MUST NOT be accepted --- and a name that is syntactically malformed under these rules fails the Identity strand rather than being repaired or partially matched. In combination with per-edge Anchor entries --- each edge's credential key listed separately, so any one edge can be de-authorized by removing one RRset entry --- this makes the otherwise weak CDN deployment profile () materially safer at no added handshake cost.

The Routing Strand: Resolver-Validated Origin and Address Binding The Routing strand binds the certificate to the network legitimately serving it, defending against BGP-hijack attacks in which an adversary fraudulently announces a victim's address space in order to impersonate a service. Its position in the threat landscape should be stated honestly: hijacks mounted to pass a CA's domain-control validation at issuance time are now primarily addressed at the point of issuance, where the CA/Browser Forum requires Multi-Perspective Issuance Corroboration, and the Identity strand independently defeats the resulting certificate because the owner's Anchor never authorized its credentials. The Routing strand's distinct contribution is protection at use time --- against an adversary who hijacks a prefix to sit in front of clients with a certificate (stolen or mis-issued) that would otherwise validate --- which no issuance-time control provides. This revision removes the prior, unworkable requirement that the TLS client perform in-band RPKI validation. RPKI validation is a layer that does not belong on end hosts: in normal operation, dedicated Relying Party software synchronizes the RPKI, builds a validated cache, and feeds routers over the RPKI-to-Router (RTR) protocol /; routers themselves perform no cryptographic verification. BRAID follows the same separation:

• Origin-AS binding. The certificate asserts the authorized origin AS(es) in the BRAIDRoutingConstraints field (). The client checks the asserted origin against routing data its RPKI-validating resolver or local gateway has already validated, querying that local component rather than parsing raw RPKI certificate chains in the handshake. Hosts without access to a validating resolver treat the Routing strand as "unknown" rather than failing, unless policy requires otherwise.
• Address binding. The BRAIDRoutingConstraints field MAY list authorized prefixes or a single host address (a /32 for IPv4 or /128 for IPv6). A client MUST verify that the server endpoint it connected to falls within the bound set, and otherwise treat the certificate as invalid for that connection. This confines a stolen certificate to its authorized address(es).

The validated-origin query is new work, named as such. No deployed protocol today lets a stub client ask its resolver "is origin AS X RPKI-valid for the prefix covering this address?": RTR is router-facing, and ordinary DNS responses do not carry validated routing state. BRAID therefore requires a small companion specification --- a validated-origin query, realizable as a new EDNS(0) option (with failure semantics drawing on Extended DNS Errors ) or as a lightweight endpoint co-located with DNS over HTTPS --- that returns the validation state for an (address, origin AS) pair from the resolver's existing validated cache. This document deliberately does not define its wire format, which belongs to the DNSOP/SIDROPS communities (); until it is available, implementations MAY consult a local RTR-fed validator directly (appropriate for enterprise gateways and server-side validation) and clients otherwise treat the strand as "unknown". The dependency is disclosed rather than hidden precisely because the strand is optional: BRAID-Base and the Witness strand are fully specifiable and deployable without it. To prevent that dependency from gating the profile, the Routing strand defines two validation methods, selected by the BRAIDRoutingConstraints validation-method parameter and by relying-party policy. The resolver-validated method is the preventive form described above: the connection fails unless the origin is RPKI-valid for the bound resources. The witness-corroborated method is the detective form of the following paragraph: the client corroborates the certificate across independent co-located services and treats a mismatch as evidence of hijack, blocking or reporting per policy. The assurance difference is stated plainly rather than papered over --- corroboration detects a hijack in progress but cannot prevent a first connection through one --- and a certificate or policy that REQUIRES the resolver-validated method MUST NOT be satisfied by corroboration alone. The value of defining both is deployability without dilution: BRAID-Routed is usable on today's operating-system stacks under the witness-corroborated method, and hardens automatically to the preventive method as validated-origin queries deploy, with the certificate itself recording which assurance its issuer intended. A detected mismatch also changes what the suspect path may be used for: a client that has observed corroboration failure MUST NOT source recovery material from the endpoint or network path under suspicion except under the hash verification of , and --- more importantly --- MUST NOT treat fetch failures over that path as the attributable outage that permits graceful degradation (), since an on-path adversary can trivially manufacture fetch failures. Evidence for degradation must come from a path the adversary does not control, or degradation is simply unavailable for that connection. Two further limitations are stated plainly. First, address binding is bypassed where the client connects through a terminating proxy, CDN, or NAT, because the observed address is the intermediary's; such deployments SHOULD omit address binding and rely on origin-AS binding, accepting that a successful hijack of the intermediary's prefix is not contained at the address layer. Second, origin-AS binding shifts trust to the client's resolver/validator; a relying party that cannot trust its routing data SHOULD treat the Routing strand as unavailable rather than authoritative. A witness-based detection alternative --- in which a client corroborates reachability through independent, co-located TLS services and treats certificate mismatches as evidence of hijack --- MAY be used where resolver-side RPKI is not available. Because a BGP hijack diverts traffic at prefix granularity (typically a /24 or shorter) but cannot forge the private keys of every authenticated service co-located in that prefix, a mismatch among co-located witnesses is high-confidence evidence of a hijack; this approach detects, rather than prevents, hijacks, and does so without trusting the local resolver.

The Witness Strand: Appointed Co-Signing and Ledger Pairing The Witness strand requires an appointed third party to counter-sign the certificate before it is treated as valid, analogous to a two-signer arrangement: no single party, including the CA, can unilaterally produce a usable certificate. A note on terminology: in the transparency-log literature, "witness" has acquired the specific meaning of a party that cosigns log checkpoints to prevent split-view attacks. The BRAID Witness strand is a related but distinct role --- an appointed co-signer of an individual certificate --- and deployments MAY additionally employ checkpoint witnessing on the underlying ledger; the two compose rather than conflict. The co-signer signs the structure of , encoded as a signed timestamp in the format of / with a BRAID-specific entry type, and anchors the attestation in a ledger named in the certificate (). Reusing the SCT structure is deliberate: clients, CAs, and monitors already generate, embed, transport, and verify SCTs at web scale, so a witness attestation rides an existing rail --- it can be embedded in the certificate at issuance exactly as SCTs are, delivered in the handshake exactly as SCTs are, and audited by adapted CT monitor tooling. Three ledger substrates are supported, trading auditability against confidentiality: a public append-only Merkle log with independent monitors (RECOMMENDED, as in Certificate Transparency, with no consensus mechanism); a public blockchain, where decentralized anchoring is specifically desired, at the cost of latency and governance; or a secured private ledger for closed ecosystems.

Witness eligibility and independence The witness role is intentionally open. Its technical requirements are only the ability to operate a signing key under sound key-management practice, to publish attestations to a ledger of a supported type, and to be named in the certificate at issuance; no relationship to the WebPKI is required. A certificate authority, DNS operator, registrar, CDN, network operator, auditor, or regulator can each serve as a witness, and a subscriber selects one whose incentives fit its threat model. One requirement is security-critical and is therefore stated normatively: the witness MUST be operationally independent of both the issuing CA and the certificate subscriber --- separate key custody, separate administrative control, and no shared signing infrastructure --- because the strand's value is precisely that no single organization can produce (or, under , sustain) a usable certificate. A witness that is a business unit of the issuing CA does not satisfy this requirement.

Witnessed freshness By default a witness attestation is made once, at provisioning, and is valid for the life of the certificate. A deployment MAY instead mark the Witness strand as fresh in BRAIDBinding, giving the attestation its own validity interval, not to exceed the certificate's freshness window. The witness then re-attests each window --- an out-of-band, cacheable operation, never on the connection path --- and a client requiring a fresh Witness strand MUST reject an attestation whose interval has lapsed. Witnessed freshness adds a revocation lever that is independent of every other strand: renewal stops on the subscriber's instruction, on the witness's own policy (for example, upon evidence of compromise or a court order contemplated in its terms of appointment), or by the witness's failure, and the certificate then ceases to validate within the window. This is the only lever in BRAID that survives the simultaneous compromise of the owner's DNS publication path and the end-entity key, which is what makes it appropriate for the highest-assurance profiles. Two consequences are stated plainly. First, it does not replace the Identity strand's structural revocation (); it complements it, and the Identity strand remains the base mechanism because it is under the owner's sole control. Second, freshness converts the witness from a one-time attester into a sustained availability dependency: a relying party MUST treat a lapsed attestation identically to a withdrawn one, so a deployment SHOULD mark the Witness strand fresh only where the witness's operational maturity warrants it, and the graceful-degradation policy of applies to verifiable witness outages as it does to other strand infrastructure.

Public verifiability with private use When the private-use option is set, verification remains fully public while use is gated. The certificate, its public strands, and the existence of its witness attestation are recorded in public logs, so any party --- including transparency monitors --- can confirm the certificate is genuine and unrevoked without private access. Use, however, requires the connecting party to satisfy an authorization gate before a handshake may complete: either mandatory mutual authentication or a capability granted to ecosystem members (deployable today), or, as an optional high-assurance measure, a session key that incorporates a secret share held only by authorized parties so that a stolen private key alone cannot complete a session (see ). The result is a certificate that is visible and verifiable to all but usable only inside the authorized ring --- appropriate for banking and defense. One limit must be stated: the holder of the server's private key can always use it, so the gate governs which counterparties may establish sessions, not the operator. Clients unable to verify a required strand or satisfy a required gate MUST fail closed, subject to .

Proof Transport: braid_chain and Reference-Based Caching A naive design that staples complete DNSSEC and RPKI proof chains plus inclusion proofs into every handshake produces payloads well over 10 KB, exceeding the initial congestion window (about 14 KB for IW10 ) and forcing extra round trips and fragmentation. BRAID therefore transports proofs by reference, not by value:

• The server sends compact identifiers --- a hash and/or URI --- for the validation material (DNSSEC chain to the BRAID Anchor, witness inclusion proof) via the braid_chain TLS extension, whose presence in the ClientHello also serves as the BRAID negotiation signal ().
• Clients maintain a global cache of validated chains. Because these change infrequently relative to the freshness window, the steady-state handshake carries only the small Delegated Credential and the compact references, staying within the initial congestion window.
• Only on a cache miss does the client fetch the full chain, from the server or a public repository, out of the latency-critical path where possible.

Each reference is a cryptographic hash of the material it names. A client MUST verify that fetched or cached content matches the referenced hash before relying on it, so that neither an untrusted repository nor a poisoned cache can substitute different material; the URI, if present, is a convenience locator only and is never trusted on its own. Caches are keyed by this hash, which makes entries self-certifying and safely shareable across connections and origins.

Resource management and denial of service A reference cache is itself an attack surface: a hostile or compromised server, or an adversary who can induce a client to contact many origins, could stream unique or unresolvable references in an attempt to exhaust the client's storage or keep it in continuous cache-miss fetching. Four properties bound this. First, the number of references per handshake is derivable, not open-ended: a server presents at most one reference per required strand plus one for the policy record, and a client MUST reject a braid_chain extension exceeding that bound. Second, admission to the cache is verification-gated: only material whose hash has been checked () is stored, so unresolvable or malformed references occupy no cache space --- there is nothing to pollute with junk that never verifies. Third, eviction and allocation are the client's to govern: caches SHOULD use a recency-based eviction policy with per-origin allocation limits, so no single origin can crowd out the rest of the cache. Fourth, failure is negatively cached: a reference whose fetch fails or times out SHOULD be recorded as unavailable for a bounded interval, during which subsequent handshakes presenting it treat the strand as unavailable immediately --- evaluated under the relying party's policy () --- rather than triggering repeated fetches. Fetched material MUST also be size-bounded before parsing; the largest legitimate object, a DNSSEC chain, is a few kilobytes, so a limit of 16 KB is ample and prevents an adversarial repository or endpoint from streaming an unbounded response into the parser. Cache-miss fetches MUST NOT reintroduce the per-connection third-party observation that discredited OCSP. A client resolving a reference SHOULD fetch it from the server it is connecting to (which learns nothing it does not already know), and MAY use a shared repository only over a privacy-preserving transport such as Oblivious HTTP or via a batched, prefetched snapshot; a client MUST NOT emit a per-connection identifying query to a third-party repository as a matter of course. In-band stapling of a full DNSSEC chain, in the style of the experimental TLS DNSSEC Chain Extension , is supported only as an OPTIONAL fallback. BRAID does not make --- which is Experimental, was published via the Independent Submission stream, and did not reach consensus for Standards Track in the TLS Working Group --- a load-bearing dependency. Baseline operation relies on resolver-side DNSSEC validation and reference-based transport instead. Concrete byte, latency, and CPU budgets for this transport are given in .

Structural Revocation and Revocation Transparency Revocation in BRAID is structural: it follows from the absence of current Identity-strand evidence () rather than from a queried status service. In addition, every BRAID certificate's issuance and revocation events SHOULD be recorded in a public, append-only, cryptographically verifiable log, extending Certificate Transparency / to revocation. Clients SHOULD consume a periodically synchronized, compressed revocation snapshot (in the manner of CRLite) so that revocation is checked locally, with no per-visit query. A ledger need not be a blockchain: a signed, append-only Merkle log with independent monitors provides mandatory, public, tamper-evident properties without consensus overhead. To avoid fragmenting the ecosystem, Revocation Transparency SHOULD reuse existing Certificate Transparency log infrastructure, Merkle-tree formats, and monitor tooling --- recording revocation as additional logged entries with a new entry type --- rather than stand up a parallel system.

Validity Period Because a certificate cannot be used beyond its short freshness window without current owner-authorized evidence, and because its revocation status is owner-controlled and structural, the rationale for short maximum lifetimes does not apply to a certificate whose required strands include the Identity strand. A CA MAY issue a BRAID-Routed certificate with a validity period of up to five years. A governance boundary must be acknowledged plainly: maximum validity periods for publicly trusted certificates are set not by the IETF but by root-program policy through the CA/Browser Forum, which has adopted a schedule reducing lifetimes to 47 days. This document does not and cannot override that schedule. What it provides is the technical basis on which a root program could define a distinct, longer maximum for certificates that carry an enforced Identity strand --- the enforcement telemetry of supplying the evidence that the freshness window, not the notAfter date, is the effective bound on exposure. The five-year figure is therefore a protocol ceiling contingent on root-program adoption, and the extended lifetime is the principal incentive this document offers operators and CAs for carrying BRAID's machinery. The deployment phases of are sequenced accordingly: BRAID is issued and enforced at prevailing lifetimes first (Phase 2), generating the enforcement evidence on which the extension request (Phase 3) then stands.

Deployment Model and Graceful Degradation The chief risk of any fail-closed mechanism is breaking reachable sites when an external dependency is briefly unavailable. The email-authentication ecosystem solved the equivalent problem, and BRAID adopts its template.

• Keys and policy in DNS, deployed at scale. DKIM publishes a key in DNS and validates signatures against it; SPF authorizes sending origins. These demonstrate the model in production.
• A policy record with staged enforcement. As DMARC progresses from none to quarantine to reject, a BRAID Policy record progresses through monitor, staged, and strict. In monitor, clients validate strands and report failures but do not block; in strict, a missing or invalid required strand fails the handshake, and a BRAID-capable client MUST also reject a conventional certificate for the domain ().
• Aggregate reporting. Operators receive reports of strand-validation outcomes, so misconfiguration is found before enforcement is enabled.

To bound the availability risk of strict mode, BRAID defines a graceful-degradation option. When enabled by the relying party's policy, a client that cannot validate a routing or identity strand because of a verifiable, attributable infrastructure outage --- for example, an expired RIR manifest or a broken DNSSEC trust anchor whose failure the client can confirm cryptographically --- MAY degrade to standard WebPKI validation rather than failing closed. This preserves resilience during outages while still failing closed against an active attacker who cannot produce such proof. This is a deliberate trade-off, not a free option. The degradation path is itself an attack surface: an adversary who can manufacture or forge the appearance of an attributable outage could trigger downgrade. The "proof of outage" MUST therefore be unforgeable (for example, a signed, expired manifest that the attacker cannot fabricate), and relying parties in the highest-assurance deployments SHOULD disable degradation and accept strict fail-closed behavior. To prevent a first-contact downgrade, domains MAY be enrolled in a preloaded BRAID-required set distributed with client software, in the manner of HSTS (). The new client-side implementation surface is correspondingly modest: each element reuses an existing code path --- Delegated Credential verification , TLS Feature parsing , resource-type parsing, SCT verification and Certificate Transparency log consumption, resolver-side DNSSEC, and HSTS-style preloading --- leaving the BRAIDBinding parser, the braid_chain reference cache, and the policy-record check as the principal new work. BRAID-Base can be adopted by a single operator without ecosystem-wide coordination, and a client that does not implement BRAID interoperates unchanged because it is never shown a BRAID certificate ().

Deployment Phases: Running Today, Strengthening Over Time The staged policy of governs how strictly a given domain enforces BRAID; this section states the complementary ecosystem-level path --- what can run on infrastructure deployed today, and in what order the remaining pieces arrive. The governing principle is that every phase delivers standalone security value with no dependence on a later phase, so there is no flag day, no stranded investment if progress stalls, and no phase whose adopters are waiting on someone else. Phase 0 --- Observe (deployable today; no new client, CA, or protocol code). The domain holder publishes a BRAID Anchor as a DNSSEC-signed _braid TXT record () and a BRAID Policy record in monitor mode, and enables Delegated Credentials where the serving stack already supports them. No handshake changes: validation is performed out of band by the operator's own monitoring and by third-party monitors, which check that the credentials a domain's servers actually present match the published Anchor, and produce aggregate reports in the manner of DMARC monitoring. The standalone value is threefold: the owner acquires and rehearses an owner-controlled revocation capability (rotating the Anchor and observing propagation); monitors gain a signal Certificate Transparency alone cannot provide --- CT shows what certificates exist, while an Anchor mismatch shows a certificate or credential serving traffic that the owner never authorized; and the operator accumulates the misconfiguration telemetry needed before any enforcement is enabled. Phase 1 --- Enforce in closed ecosystems (deployable today within private PKIs). Enterprises, banks, and closed networks operate their own root programs and control both endpoints, so they are not gated on public root-program or browser decisions: they can issue certificates carrying BRAIDBinding under private-use codepoints, enforce the Identity strand in their managed clients, and deploy the Witness strand's private-use gating with mutual authentication, all of which notes is deployable now. These deployments are BRAID's proving ground: they generate the interoperability and operational record () that public-web standardization will ask for, in exactly the environments --- regulated and high-assurance --- that want the strongest profiles first. Phase 2 --- Public web at prevailing lifetimes (the security benefit, decoupled from the lifetime benefit). Public CAs issue BRAID certificates at whatever maximum lifetime root programs then require, and browsers ship validation behind a flag, progressing domains through monitor, staged, and strict as their telemetry warrants. This phase's one root-program ask is small and deliberately severable from lifetimes: current CA/Browser Forum certificate profiles enumerate the extensions a publicly trusted certificate may carry, so permitting the single BRAIDBinding extension in leaf certificates --- within which every BRAID parameter is serialized () --- requires a scoped profile ballot --- a permission-to-carry change, not a lifetime change, of the kind the Forum routinely processes. Beyond that, nothing is asked: a BRAID certificate at a 47-day lifetime is still strictly stronger than a conventional one --- owner-controlled revocation within the freshness window, defense against CA compromise via the independent Anchor, and delegated name constraints for CDN deployments. Decoupling matters strategically as well as technically: BRAID must be worth deploying with no lifetime reward at all, and it is. Phase 3 --- Extended validity. With Phase-2 enforcement telemetry demonstrating that the freshness window, not the notAfter date, bounds real exposure, a root-program ballot can define a distinct validity class for certificates carrying an enforced Identity strand (). The long-lived certificate is the reward for proven enforcement, not a prerequisite for adoption. Phase 4 --- Routing strand at scale. Once the validated-origin query () is standardized and deployed in validating resolvers, the Routing strand graduates from enterprise gateways and server-side validators to general clients, and BRAID-Routed becomes broadly available. To be fully candid about its footprint, Phase 0 involves no protocol implementation at all --- no handshake change, no client change, no CA change; it is an operational monitoring posture whose entire mechanism is DNS publication plus out-of-band comparison. That candor is deliberate: it means the cost of starting is a DNS record and a cron job, and nothing published in Phase 0 is thrown away later. The per-phase status of each strand is summarized below; "advisory" means validated and reported out of band without affecting connections.

Strand	Phase 0 (observe)	Phase 1 (closed ecosystems)	Phases 2--4 (public web)
Authority	Enforced (as today)	Enforced (as today)	Enforced (as today)
Identity	Advisory, out of band	Enforced in managed clients	monitor -> staged -> strict ()
Routing	Not evaluated	Optional, via local validator	Policy-selected method (); preventive form arrives with Phase 4
Witness	Not evaluated	Enforced where profiled	Optional per profile ()

Phases overlap rather than queue: Phase 1 ecosystems need not wait for Phase 0 to mature, and Phase 4 proceeds in DNSOP/SIDROPS in parallel with Phases 2 and 3. The dependency structure is deliberately a fan, not a chain.

Deployment Profiles

• Small business / independent operator. BRAID-Base. One DNSSEC-signed anchor plus Delegated Credentials via existing ACME tooling ; a long-lived certificate with low renewal churn.
• Enterprise. BRAID-Routed with origin-AS binding to the organization's allocated prefixes; strict policy with aggregate reporting.
• CDN / anycast. BRAID-Routed with address binding omitted (per ); origin-AS binding, per-edge Delegated Credentials, per-edge Anchor entries, and delegated name constraints ().
• Banking. BRAID-Witnessed with a regulator or auditor as co-signer on a public log, witnessed freshness enabled (), plus private-use gating to enrolled clients.
• Defense / closed network. BRAID-Witnessed with a private ledger and private-use with mandatory mutual authentication; degradation disabled.

The strands can be adopted one at a time and by one party at a time: BRAID-Base needs only a DNSSEC-signed anchor and Delegated Credentials and can be enabled by a single operator without ecosystem-wide coordination. The lowest incremental cost falls to providers that already operate the supporting infrastructure --- authoritative DNSSEC, RPKI-validated routing data, Delegated Credentials, and CRLite-style revocation tooling --- for whom adoption is largely a matter of connecting existing capabilities; such providers are natural early adopters and can make BRAID available across many domains at once, which softens the bootstrapping problem that hinders new PKI mechanisms. One dependency bounds the addressable base and is stated honestly: the Identity strand requires the domain's zone to be DNSSEC-signed, and most zones today are not. The registrars and DNS operators who can enable signing at scale --- often as a one-click or default setting --- are the same providers just identified as natural early adopters, so BRAID gives the parties with the levers a concrete reason to pull them; domains that cannot yet sign are simply outside BRAID's scope and lose nothing, per . The same providers most often serve traffic through terminating proxies, where address binding does not apply (per ) and a Delegated Credential must be scoped by the delegated name constraints of ; the CDN profile is thus the most operationally convenient to deploy and the most dependent on those constraints for its strength. Broad early availability and the strongest per-connection guarantees are therefore in tension, and an operator selects its profile accordingly.

Comparison with Related Mechanisms BRAID is not DANE. DANE replaces or supplements CA trust by publishing the certificate or key in DNSSEC; BRAID does not replace the WebPKI but layers additional, independent anchors on top of it, and forging a certificate requires defeating several at once. BRAID also avoids DANE-for-web's principal deployment blocker --- in-band DNSSEC parsing by browsers --- by validating DNSSEC at the resolver and transporting proofs by reference (). BRAID is the successor to must-staple, not a competitor to it. The TLS Feature extension pioneered the signed-in requirement that BRAID depends on, and BRAID reuses the extension itself (). Where must-staple required fresh evidence from a third party the operator did not control --- the CA's OCSP responder, whose outages forced soft-fail and ultimately deprecation --- BRAID requires evidence the operator publishes and refreshes itself, aligning the availability burden with the party able to carry it, and adds negotiation () so that enforcement never strands a legacy client. Academic proposals such as Delegation Certificates explore CA-independent delegation with built-in subdomain and delegation-depth scoping. BRAID instead achieves equivalent scoping at the policy layer, via the delegated name constraints of , so that it can reuse the standards-track Delegated Credentials rather than depend on a non-standardized credential format; such a format could be adopted later as an additional Identity-strand substrate without changing the model.

Capability	TLS/WebPKI	OCSP Must-Staple (RFC 7633)	DANE	Delegated Creds (RFC 9345)	BRAID
Independent of CA trust	No	No	Yes	No	Layered (multi-anchor)
Owner-controlled revocation	No	No	Yes	No	Yes
Revocation is mandatory to use	No	Signed-in, but soft-failed in practice	Optional	N/A	Yes (structural)
Freshness evidence controlled by	n/a	CA's OCSP responder	Owner (DNS)	Operator (unanchored)	Owner (DNSSEC anchor)
Safe for legacy clients	Yes	Yes	Yes	Yes	Yes (negotiated; )
Routing-aware	No	No	No	No	Yes (optional)
In-band browser DNSSEC/RPKI parsing	No	No	Yes (issue)	No	No (resolver-side)
Steady-state handshake overhead	Low	Low + staple	High (in-band DNSSEC)	Low (+~1 KB)	Low (references + DC)
Short-lived key reuse of a standard	n/a	n/a	n/a	Yes	Yes (uses RFC 9345)
Long-lived certificate, low churn	No	No	Partial	n/a	Yes (up to 5 yr; )

Performance Considerations The principal objection to any multi-strand certificate is performance. An early design that stapled complete DNSSEC and RPKI proofs in band would have produced a server flight exceeding ten kilobytes and would have required clients to act as RPKI validators. The architecture of this document is shaped specifically to avoid both outcomes; this section gives concrete budgets rather than assurances. The figures below are order-of-magnitude estimates for typical ECDSA P-256 deployments and will vary with algorithm and chain length.

Handshake size and the initial congestion window The relevant constraint is the IW10 initial congestion window of approximately 14,600 bytes (ten segments) : a server flight that fits within it completes in one round trip, while a flight that exceeds it incurs additional round trips and exposure to loss. The table contrasts the rejected in-band design with the steady-state flight of this document.

Server's first-flight component	In-band design (rejected)	This document (steady state)
Authority certificate chain	~3 KB	~3 KB
Delegated Credential (Identity)	n/a	~0.5--1 KB
DNSSEC chain to BRAID Anchor	1.5--3 KB stapled	0 (by reference; resolver-validated)
RPKI objects (Routing)	2--5 KB stapled	0 (resolver-side; not on client)
Witness / inclusion proofs	1--2 KB	~32--100 B (reference)
braid_chain references	n/a	~100--300 B
Total server flight	~10--15+ KB	~4--4.5 KB

The steady-state BRAID-Routed flight stays well within IW10 and completes in the same single round trip as a conventional TLS 1.3 handshake . Reference-based transport () and resolver-side routing validation () are precisely what remove the multi-kilobyte components that would otherwise overflow the window.

Cold start and caching The reference model trades a rare fetch for a small steady state. On a cache miss --- a client that has not recently validated a given domain's DNSSEC chain --- the client obtains the chain once, either as an in-band fallback (which adds only the DNSSEC chain and typically still fits within IW10) or, preferably, out of band from the server or a privacy-preserving repository off the latency-critical path (). Because the referenced material changes on the order of the freshness window (up to seven days) rather than per connection, the amortized per-connection cost approaches zero, and clients MAY prefetch popular chains. Even the worst case --- a cold in-band fallback --- is no worse than a single conventional handshake with a large certificate chain, and the common case adds nothing. This is strictly better than OCSP, which imposed a third-party query and a privacy leak on every connection.

Client computation In steady state a BRAID client performs: the certificate-chain verification it already performs today (Authority strand); one additional signature verification for the Delegated Credential plus its handshake signature (Identity strand) --- the same incremental cost as deploying alone; a constant-time cache lookup and hash comparison per braid_chain reference; a hash-set membership test of the credential key against the Anchor RRset (); and, for the Routing strand, a lookup against routing data the client's resolver has already validated. The client does not parse RPKI objects, verify AS-resource extensions cryptographically, or maintain Trust Anchor Locators for the Regional Internet Registries. Published measurements showing that certificate parsing and signature verification dominate RPKI relying-party CPU describe exactly the work this document keeps off the client; that cost remains in the dedicated relying-party software where it already lives and is fed to the client's resolver over RTR /. The net added client cost over a present-day TLS 1.3 handshake is therefore on the order of a single signature verification, negligible beside the key exchange the handshake already performs.

Amplification and QUIC Reference-based transport also avoids turning the server into an amplifier: the bulky proof material is fetched by the client on demand rather than emitted unsolicited. This matters for QUIC, where a server may send no more than three times the data it has received before validating the client's address; a compact server flight keeps a BRAID handshake within that anti-amplification limit, whereas a multi-kilobyte stapled flight would risk exceeding it and stalling the handshake behind address validation.

Server cost A server mints a fresh Delegated Credential at most once per freshness window, not per connection, and otherwise serves static references; both are cheap and cacheable across all connections. The accompanying Anchor RRset update is one DNS operation per rotation, executed by the same automation. A Witness co-signature, where used, is obtained out of band when the certificate is provisioned, never on the connection path. BRAID therefore adds no per-connection asymmetric operation to the server beyond what already entails.

Cryptographic Agility and Post-Quantum Migration Each strand is signature-algorithm agnostic and migrates independently. The Authority strand follows CA/WebPKI algorithm policy; the Identity strand's Delegated Credentials negotiate their own scheme , which also makes them a convenient early vehicle for post-quantum handshake signatures without reissuing the certificate; the Routing and Witness strands carry their own algorithm identifiers. An operator can therefore introduce post-quantum signatures in one strand without waiting for the others, and a relying party can require post-quantum protection per strand via policy.

Security Considerations Downgrade and stripping. The validity requirement is carried in a critical certificate extension, reinforced by the TLS Feature extension , and, for enrolled domains, in the policy record and preloaded set of ; an attacker can withhold a strand but cannot make a BRAID certificate validate without it. The negotiation of introduces a first-contact downgrade surface --- substitution of a conventional certificate before the client learns the domain's BRAID policy --- whose mitigations and residual exposure are analyzed there; operators for whom that residue is unacceptable use preloading. Single-anchor concentration. Requiring independent strands ensures that compromise of the CA, the DNSSEC hierarchy, or the routing system alone is insufficient to forge a valid certificate. BRAID is defense-in-depth, not the replacement of one single point of failure with another. Stolen keys. The two-key property of governs: theft of the end-entity private key alone does not permit impersonation of a BRAID-strict domain, because the thief's Delegated Credentials are not authorized by the owner's Anchor; theft of a credential key alone is bounded by the freshness window and cured by one Anchor rotation. The property collapses if the DNS update credential is co-resident with the TLS keys, which therefore counsels against; operators SHOULD treat that separation as part of the deployment, not an optimization. Availability and the degradation path. Strict fail-closed operation couples web availability to the stability of DNSSEC and routing infrastructure. The staged policy (), reference-based transport (), and bounded freshness windows reduce avoidable outages, and graceful degradation bounds the residual risk --- but degradation is itself an attack surface and MUST rely on unforgeable proof of outage; highest-assurance deployments SHOULD disable it. Resolver trust. Origin-AS validation depends on the client's RPKI-validating resolver, and the channel to it is itself a target: an on-path adversary on an unauthenticated client-to-resolver link could spoof validation state or DNS responses. Clients SHOULD reach the validating resolver over an authenticated, encrypted transport such as DNS over TLS or DNS over HTTPS , and the resolver-to-router segment SHOULD use a secured RTR transport . A relying party that can trust neither its routing data nor that channel MUST treat the Routing strand as unavailable rather than authoritative, or fall back to the witness-based detection of . The Identity strand's Anchor lookup carries the same dependency and the same remedy: a client that does not perform DNSSEC validation locally is trusting its resolver's validation result, so the authenticated-transport requirement applies equally to the Anchor query, and clients in hostile resolver environments SHOULD validate the Anchor RRset's DNSSEC chain themselves (the material the braid_chain reference already identifies; ). The lookup introduces no new observer: it is directed to the same resolver that resolved the server's name and reveals nothing that name resolution did not already reveal. Theft and relocation. Address binding () confines a certificate to its authorized address(es); this is defeated only by an attacker who can hijack the bound prefix, which the origin-AS layer is designed to detect. Delegated Credential considerations. The cross-protocol and clock-skew considerations of apply unchanged to the Identity strand. Clock skew additionally bounds how aggressively an Anchor rotation takes effect; owners requiring immediate de-authorization SHOULD both rotate the Anchor and cease serving the excluded credential. Privacy. Freshness and revocation are checked from cached and stapled material (, ); BRAID introduces no per-connection query to a third party and does not reproduce the OCSP privacy leak. Cache-miss fetches follow the privacy rules of , and the validated-origin query of is directed at the client's own chosen resolver, which already observes the client's name-resolution traffic.

Future Work The optional cryptographic use-gate of --- in which session-key establishment incorporates a secret share held only by authorized parties --- requires a concrete threshold or multi-party construction and a formal security analysis; it is out of scope for this version and is noted as future work. Also deferred: a formal model of the security invariant (); the precise wire encodings of the braid_chain extension, the BRAIDBinding sequence, and the BRAID Anchor and Policy records; and the companion validated-origin query specification ().

Implementation Status This section records the status of known implementations per . RFC Editor: please remove this section before publication. No complete implementation of this document exists at the time of writing; Phases 0 and 1 of require none. The building blocks, however, are individually implemented and deployed: Delegated Credentials ship in a major browser and in widely used TLS libraries and are deployed by large CDN operators; DNSSEC validation is standard in major recursive resolvers; Certificate Transparency logging, monitoring, and SCT verification / operate at web scale; compressed revocation snapshots in the CRLite style ship in a major browser; HSTS-style preload pipelines are in production; and ACME automation is the dominant issuance path. The authors intend to record here, in future revisions, Phase-0 monitor implementations and Phase-1 closed-ecosystem deployments as they are reported, and solicit such reports.

IANA Considerations By reusing the TLS Feature extension , the resource types, Subject Information Access, GeneralSubtrees, and the / timestamp and log structures, this document keeps its registration footprint small. It requests:

• a TLS ExtensionType for braid_chain in the TLS ExtensionType Values registry;
• a single object identifier for the BRAIDBinding certificate extension, within which all BRAID parameters --- strand bitmap, freshness windows, routing constraints, delegated name constraints, and witness parameters --- are serialized, so that no parallel certificate-extension identifiers are required;
• a DNS RRTYPE for the BRAID Anchor record and a record format for the BRAID Policy record;
• a Certificate Transparency log entry type for witness attestations and one for revocation entries (, ); and
• registries for BRAID policy modes, strand identifiers, and degradation parameters.

Several of these registrations require coordination beyond the TLS Working Group. The BRAID Anchor and BRAID Policy RRTYPEs require DNS expert review and are expected to involve the DNSOP community; the validated-origin query of belongs jointly to DNSOP and SIDROPS; and the BRAIDBinding ASN.1, including its syntax-only import of the resource types (), warrants LAMPS review. Early review by those groups is anticipated, and the authors expect initial dispatch discussion to determine the appropriate venue for each component.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK] The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial-of-service attack that might otherwise be possible. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification. Informative References DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK] In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK] This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated by DNSSEC and that are needed to perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial-of-existence proof that can be validated. This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages.

Change Log RFC Editor: please remove this section before publication. Changes from draft-braid-tls-double-secure-01 (this document replaces that draft; the "replaces" relationship should be declared at submission):

• Added : BRAID support is negotiated via the ClientHello braid_chain offer; servers present BRAID certificates only to BRAID-capable clients and conventional certificates otherwise, with downgrade resistance via the policy record, preloading, and policy caching. Resolves the conflict between the critical BRAIDBinding extension and legacy-client compatibility.
• Made the Identity strand construction precise (): the BRAID Anchor is a DNSSEC-signed allowlist of Delegated Credential public keys; Delegated Credentials are used per RFC 9345 unchanged; stated and analyzed the resulting two-key security property, closing the stolen end-entity-key gap in the -01 text.
• Named the validated-origin (stub-to-resolver) query as new companion work (); repositioned the Routing strand relative to Multi-Perspective Issuance Corroboration as a use-time defense.
• Reused existing certificate structures throughout (): TLS Feature (RFC 7633) as the requirement flag; RFC 3779 resource types for routing parameters (see the -02 external-review bullet below); Subject Information Access for locators; GeneralSubtrees for delegated name constraints; SCT-format witness attestations and revocation entries. Reduced the IANA footprint accordingly.
• Added must-staple lineage and comparison rows; added privacy rules for cache-miss fetches (server-fetch or Oblivious HTTP); acknowledged the CA/Browser Forum governance boundary on validity periods; renamed the profile "BRAID Double-Secure" to "BRAID-Routed"; renamed the draft from draft-braid-tls-double-secure.
• Added : a five-phase deployment path in which Phase 0 (observe: TXT-form Anchor, Delegated Credentials, out-of-band monitoring and aggregate reporting) runs today with no new code, Phase 1 (closed-ecosystem enforcement under private root programs) runs today, and the public-web security benefit (Phase 2) is explicitly decoupled from the extended-lifetime benefit (Phase 3). Added the _braid TXT interim publication form for the Anchor per the SPF/DKIM/DMARC precedent, and an RFC 7942 Implementation Status section.
• Witness strand: added , stating that the witness role is open to any party meeting the technical requirements and normatively requiring operational independence from both the issuing CA and the subscriber; added the optional witnessed-freshness mode (), giving the Witness strand a renewal-based revocation lever independent of every other strand, with its availability trade-off stated; added the corresponding threat-table row and BRAIDBinding field.
• Fact-check corrections: Phase 2 now correctly states that public issuance requires a scoped CA/Browser Forum certificate-profile ballot to permit the BRAID extensions (a permission-to-carry change, severable from lifetimes), rather than claiming no root-program ask; the resolver-trust security consideration now covers the Identity strand's Anchor lookup, with a local-validation remedy and a no-new-observer privacy note; the TLS 1.3 floor inherited from is stated explicitly; and the DNSSEC-adoption bound on the addressable base is acknowledged in .
• Incorporated external review: routing parameters moved from the extension OIDs to a native BRAIDRoutingConstraints field importing only that RFC's ASN.1 types, on the semantic ground that extensions assert resource holdership validated up the IANA delegation chain, which a WebPKI CA cannot attest --- this also removed the criticality deviation and shrank the root-program ask to one extension; defined two Routing-strand validation methods (resolver-validated, preventive; witness-corroborated, detective) so the profile is deployable before the validated-origin query standardizes, with the assurance difference stated normatively; added operational isolation rules for the BRAID certificate (never a default/fallback certificate; loud, safe-direction failure observable in monitor telemetry); added rotation-at-scale guidance for the Anchor (pre-publication, TTL bounds, staggered validity); stated plainly that Phase 0 involves no protocol implementation, with a per-phase strand status table.
• Incorporated a second external review selectively: added (derivable per-handshake reference bound, verification-gated cache admission, recency eviction with per-origin limits, negative caching of failed fetches, and a justified 16 KB fetch size bound); added the suspect-path rule to the witness-corroborated Routing method (no degradation evidence may be sourced over a path under corroboration suspicion, since an on-path adversary can manufacture fetch failures); tightened delegated-name-constraint matching to lowercase A-label comparison with a whole-label-only wildcard rule and hard failure on malformed names, resolving the internationalized-name item previously deferred in . Rejected from the same review: fixed arbitrary constants in favor of derivable or justified bounds, a mandate to fail closed when no Oblivious HTTP relay is available (an availability regression; the SHOULD-level privacy rules of stand), and a nonexistent TLS alert code.