Bound Routing, Authority, and Identity Data (BRAID): Multi-Strand TLS Certificates with Structural, Owner-Controlled Revocation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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 [RFC7633] ("must-staple") demonstrated the right structural idea --- a validation requirement signed into the certificate by the CA, which an on-path attacker cannot strip --- but it failed in deployment because the requirement pointed at an unreliable dependency: a third-party OCSP responder whose outages made hard-fail enforcement untenable, so clients enforced it softly or not at all. BRAID retains the signed-requirement mechanism and replaces the dependency. The evidence a BRAID certificate requires is published and refreshed by the certificate's own owner, under keys and infrastructure the owner controls, so the party that bears the availability risk is the party with the power and incentive to manage it. An on-path attacker can withhold a strand but cannot make the certificate validate without it; a certificate missing a required strand is invalid. Fail-closed is achieved by construction, subject to the bounded graceful-degradation policy of Section 13.¶

Two design principles shape this revision. First, reuse over reinvention: BRAID does not define a new short-lived key format, a new requirement-flag extension, a new encoding for network resources, or a new transparency-log format; it composes Delegated Credentials [RFC9345], the TLS Feature extension [RFC7633], the resource-encoding ASN.1 types of [RFC3779], and the Certificate Transparency structures [RFC6962]/[RFC9162], each of which has deployed parsers and operational history. Second, keep expensive validation off the client's critical path: browsers do not parse DNSSEC or RPKI in band; those functions live at the resolver and in dedicated relying-party software, where they already run today.¶

BRAID changes nothing for parties that do not adopt it, and --- because support is negotiated (Section 4) --- deploying it breaks nothing for parties that have not yet adopted it. A client signals in its ClientHello that it can validate BRAID; a server presents a BRAID certificate only to such clients and presents a conventional certificate to all others. A CA may keep issuing short-lifetime certificates unchanged, and a client that does not implement BRAID validates ordinary certificates exactly as before. The mechanism is purely additive --- an enhanced option a CA MAY offer and an operator MAY adopt to obtain long-lived, structurally revocable certificates in exchange for running the supporting machinery. It is therefore complementary to, not a replacement for, the prevailing move toward shorter lifetimes: the two can coexist, and each operator chooses the trade-off that fits it rather than being moved onto a single path. Deployment is correspondingly phased (Section 14): the earliest phase runs entirely on infrastructure deployed today, requiring no new client, CA, or protocol code, and every subsequent phase delivers standalone security value rather than a promise redeemed later.¶

2. Security Invariant

BRAID validation reduces to a single rule. Let R be the set of strands marked REQUIRED by the certificate or by relying-party policy. A certificate is valid for a connection if and only if every required strand validates for that connection:¶

valid(cert, connection)  <=>  for all s in R : verify(s, cert, connection) = TRUE

This is a logical conjunction: there is no strand whose failure can be compensated for by another. The only relaxation permitted is the bounded graceful-degradation policy of Section 13, and only when the relying party's configured policy explicitly allows it.¶

3. Threat Model

BRAID is designed against the following adversaries. Each row states the attack and the strand or mechanism that mitigates it.¶

The Identity strand's headline property is stated precisely in Section 7: neutralizing it requires the compromise of two independently held secrets --- the end-entity private key and the ability to publish in the owner's DNSSEC-signed zone --- not either alone.¶

4. Negotiation and Certificate Selection

BRAID requires TLS 1.3 or later [RFC8446]; the Identity strand inherits this floor from Delegated Credentials, which are defined only for TLS 1.3 [RFC9345]. The BRAIDBinding extension is critical (Section 5), so a client that does not implement BRAID will reject a BRAID certificate. BRAID therefore MUST be negotiated, and a server MUST NOT present a BRAID certificate to a client that has not offered to validate it.¶

Client signal. A BRAID-capable client offers the braid_chain extension (Section 10) in its ClientHello, alongside the delegated_credential extension of [RFC9345] that the Identity strand requires. The presence of braid_chain in the ClientHello is the client's declaration that it implements this document and will enforce the certificate's required strands.¶

Server certificate selection. A server operating a BRAID deployment holds both a BRAID certificate and a conventional certificate for the same identity (or serves populations of clients through distinct endpoints). If the ClientHello offers braid_chain, the server SHOULD select the BRAID certificate and respond with the braid_chain extension; otherwise it MUST select the conventional certificate and complete an ordinary TLS 1.3 handshake [RFC8446]. This mirrors the certificate-selection model already deployed for Delegated Credentials and for signature-algorithm negotiation, and it means BRAID adoption is invisible to every legacy client, crawler, and embedded device.¶

Operational isolation of the BRAID certificate. The remaining deployment risk is server-side misconfiguration: a default-certificate rule, an unsynchronized load-balancer fleet, or an SNI-routing error that serves the BRAID certificate to a client that never offered braid_chain. A BRAID certificate MUST NOT be configured as the default or fallback certificate of any listener; it is selected only on an affirmative braid_chain offer, and a server that cannot determine the offer state MUST serve the conventional certificate. Two properties bound the residual risk. The failure direction is safe: a legacy client shown a BRAID certificate rejects it loudly on the unrecognized critical extension --- a hard, visible handshake failure, never a silent acceptance with weakened validation. And the failure is observable before it matters: the misconfiguration manifests as a spike of such alerts in exactly the aggregate reporting that the monitor phase of Section 13 requires operators to run before enforcement.¶

Downgrade resistance. Negotiation creates a first-contact downgrade surface: an attacker who has stolen a conventional certificate for the domain could strip the client's braid_chain offer or simply answer with the stolen conventional certificate. BRAID closes this in three graduated ways. First, the owner publishes a DNSSEC-signed BRAID Policy record (Section 13) whose strict mode instructs BRAID-capable clients that the domain MUST present a BRAID certificate; a BRAID-capable client that has validated such a record MUST reject a conventional certificate for that domain. Second, domains MAY be enrolled in a preloaded BRAID-required set distributed with client software, in the manner of HSTS [RFC6797], which protects even the first contact. Third, a client SHOULD cache a domain's observed BRAID policy for its stated lifetime, so that any subsequent downgrade within that lifetime fails. Note that the conventional certificate a BRAID operator holds for legacy clients is, by design, short-lived under prevailing root-program rules, so the residual downgrade exposure against BRAID-capable clients is bounded by the shorter of the policy-record lifetime and the conventional certificate's own lifetime.¶

Coexistence rationale. This dual-certificate model is a feature, not a transition cost: the long-lived BRAID certificate eliminates renewal churn for the population of clients that can enforce its guarantees, while the conventional certificate covers the long tail. As BRAID-capable clients become the majority, the conventional certificate becomes a fallback artifact whose short lifetime matters less because it serves less traffic.¶

5. The BRAID Binding Certificate Extension

A BRAID certificate carries a critical X.509 extension, BRAIDBinding, declaring which strands are REQUIRED and the minimal parameters needed to locate and verify them. Because the extension is marked critical [RFC5280], any client that does not understand BRAID MUST reject the certificate rather than treat it as an ordinary certificate; this prevents a silent downgrade to single-strand validation. Presentation of such a certificate to non-BRAID clients is prevented by the negotiation of Section 4, so criticality never strands a legacy client.¶

BRAID deliberately keeps BRAIDBinding small by expressing every parameter that has an existing, deployed X.509 encoding in that encoding rather than a new one:¶

• Requirement flag. In addition to the criticality of BRAIDBinding itself, the certificate SHOULD carry the TLS Feature extension [RFC7633] 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 [RFC7633] 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 [RFC3779] verbatim --- but deliberately not that RFC's extension object identifiers. The distinction is semantic, not cosmetic: an [RFC3779] 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 [RFC3779] OIDs would misstate the claim, confuse RPKI relying-party tooling that treats those OIDs as holdership assertions, and force a criticality deviation from [RFC3779]'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 [RFC5280] rather than bespoke fields.¶

• Delegated name constraints. The constraint set of Section 7 reuses the GeneralSubtrees syntax of the [RFC5280] Name Constraints extension, carried inside BRAIDBinding (because Name Constraints proper is defined only for CA certificates). Matching follows [RFC6125].¶

• Witness parameters. The co-signer identity and inclusion-proof parameters reuse the SignedCertificateTimestamp and log-identifier structures of [RFC6962]/[RFC9162] (Section 9).¶

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 (Section 8);¶

• the maximum acceptable age of the freshness evidence (the freshness window), not to exceed the Delegated Credential maximum of seven days [RFC9345];¶

• OPTIONALLY the delegated name-constraint GeneralSubtrees (Section 7);¶

• OPTIONALLY a witness-freshness flag and interval (Section 9.2);¶

• OPTIONALLY a private-use flag and parameters (Section 9); and¶

• the policy mode and degradation parameters under which the certificate was issued (Section 13).¶

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 [RFC7633], the [RFC3779] resource types, Subject Information Access, GeneralSubtrees, and SCT structures. The new parsing surface BRAID introduces is a single short sequence.¶

6. 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 [RFC5280], including the critical BRAIDBinding extension and the reused extensions of Section 5. The binding is therefore covered by the CA signature and cannot be altered without invalidating the certificate.¶

• Identity strand --- a Delegated Credential per [RFC9345], 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 (Section 7).¶

• Routing strand --- no new signature on the critical path: the client compares the certificate's BRAIDRoutingConstraints origin-AS and address assertions (Section 5) 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 (Section 8).¶

• 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 [RFC6962], plus a Merkle inclusion proof against the ledger named in the certificate (Section 9).¶

7. 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.¶

8. 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 [RFC6810]/[RFC8210]; 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 (Section 5). 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 [RFC8914]) or as a lightweight endpoint co-located with DNS over HTTPS [RFC8484] --- 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 (Section 22); 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 Section 10, and --- more importantly --- MUST NOT treat fetch failures over that path as the attributable outage that permits graceful degradation (Section 13), 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.¶

9. 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 Section 6, encoded as a signed timestamp in the format of [RFC6962]/[RFC9162] with a BRAID-specific entry type, and anchors the attestation in a ledger named in the certificate (Section 5). 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.¶

10. 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 [RFC6928]) 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 (Section 4).¶

• 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.¶

11. Structural Revocation and Revocation Transparency

Revocation in BRAID is structural: it follows from the absence of current Identity-strand evidence (Section 7) 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 [RFC6962]/[RFC9162] 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.¶

12. 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 Section 13 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 Section 14 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.¶

13. 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 [RFC6376] publishes a key in DNS and validates signatures against it; SPF [RFC7208] authorizes sending origins. These demonstrate the model in production.¶

• A policy record with staged enforcement. As DMARC [RFC7489] 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 (Section 4).¶

• 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 [RFC6797] (Section 4).¶

The new client-side implementation surface is correspondingly modest: each element reuses an existing code path --- Delegated Credential verification [RFC9345], TLS Feature parsing [RFC7633], [RFC3779] 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 (Section 4).¶

14. Deployment Phases: Running Today, Strengthening Over Time

The staged policy of Section 13 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 (Section 7.1) 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 Section 9 notes is deployable now. These deployments are BRAID's proving ground: they generate the interoperability and operational record (Section 21) 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 (Section 5) --- 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 (Section 12). 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 (Section 8) 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.¶

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.¶

15. Deployment Profiles

• Small business / independent operator. BRAID-Base. One DNSSEC-signed anchor plus Delegated Credentials via existing ACME tooling [RFC8555]; 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 Section 8); origin-AS binding, per-edge Delegated Credentials, per-edge Anchor entries, and delegated name constraints (Section 7.3).¶

• Banking. BRAID-Witnessed with a regulator or auditor as co-signer on a public log, witnessed freshness enabled (Section 9.2), 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 Section 1. The same providers most often serve traffic through terminating proxies, where address binding does not apply (per Section 8) and a Delegated Credential must be scoped by the delegated name constraints of Section 7.3; 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.¶

16. Comparison with Related Mechanisms

BRAID is not DANE. DANE [RFC6698] 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 (Section 10).¶

BRAID is the successor to must-staple, not a competitor to it. The TLS Feature extension [RFC7633] pioneered the signed-in requirement that BRAID depends on, and BRAID reuses the extension itself (Section 5). 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 (Section 4) 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 Section 7.3, so that it can reuse the standards-track Delegated Credentials [RFC9345] 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.¶

17. 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.¶

18. 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 [RFC9345], 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.¶

19. Security Considerations

Downgrade and stripping. The validity requirement is carried in a critical certificate extension, reinforced by the TLS Feature extension [RFC7633], and, for enrolled domains, in the policy record and preloaded set of Section 4; an attacker can withhold a strand but cannot make a BRAID certificate validate without it. The negotiation of Section 4 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 Section 7.2 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 Section 7.2 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 (Section 13), reference-based transport (Section 10), 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 [RFC7858] or DNS over HTTPS [RFC8484], and the resolver-to-router segment SHOULD use a secured RTR transport [RFC8210]. 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 Section 8. 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; Section 10). 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 (Section 8) 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 [RFC9345] 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 (Section 10, Section 11); 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 Section 10, and the validated-origin query of Section 8 is directed at the client's own chosen resolver, which already observes the client's name-resolution traffic.¶

20. Future Work

The optional cryptographic use-gate of Section 9 --- 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 (Section 2); 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 (Section 8).¶

21. Implementation Status

This section records the status of known implementations per [RFC7942]. 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 Section 14 require none. The building blocks, however, are individually implemented and deployed: Delegated Credentials [RFC9345] 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 [RFC6962]/[RFC9162] operate at web scale; compressed revocation snapshots in the CRLite style ship in a major browser; HSTS-style preload pipelines [RFC6797] are in production; and ACME automation [RFC8555] 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.¶

22. IANA Considerations

By reusing the TLS Feature extension [RFC7633], the [RFC3779] resource types, Subject Information Access, GeneralSubtrees, and the [RFC6962]/[RFC9162] 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 (Section 9, Section 11); 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 Section 8 belongs jointly to DNSOP and SIDROPS; and the BRAIDBinding ASN.1, including its syntax-only import of the [RFC3779] resource types (Section 5), 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.¶

23. References

Appendix A. 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 Section 4: 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 (Section 7): 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 (Section 8); repositioned the Routing strand relative to Multi-Perspective Issuance Corroboration as a use-time defense.¶

• Reused existing certificate structures throughout (Section 5): 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 Section 14: 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 Section 9.1, 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 (Section 9.2), 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 [RFC9345] is stated explicitly; and the DNSSEC-adoption bound on the addressable base is acknowledged in Section 15.¶

• Incorporated external review: routing parameters moved from the [RFC3779] extension OIDs to a native BRAIDRoutingConstraints field importing only that RFC's ASN.1 types, on the semantic ground that [RFC3779] 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 Section 10.1 (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 Section 20. 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 Section 10 stand), and a nonexistent TLS alert code.¶

Author's Address