Bound Routing, Authority, and Identity Data (BRAID): Independent Circuit Breakers for Long-Lived TLS Certificates

Introduction The maximum validity period of publicly trusted TLS certificates has been reduced repeatedly. The stated motivation is to bound the exposure created by a stolen or mis-issued certificate. That motivation is sound, and it exists because the mechanism intended to cancel a bad certificate before its natural expiry, revocation, has never worked reliably at internet scale. Online status checking has been deprecated by major browsers for privacy, latency, and soft-fail reasons, and certificate revocation lists are not consulted in a way that reliably protects users. Shortening lifetimes is a mitigation rather than a repair. It imposes a permanent operational burden and it does not restore the ability to cancel a certificate on demand. This document takes the other path: rather than making certificates expire quickly so that unreliable revocation matters less, it gives a certificate one or more independent circuit breakers that reliably invalidate it when tripped, so that a longer natural lifetime does not imply a longer exposure window. A circuit breaker in this document is an authorization published by a party the domain owner appoints, which a relying party checks and which the appointed party can withdraw. The certificate carries, in a critical extension, the statement that particular circuit breakers are required. An on-path attacker can withhold the evidence that a circuit breaker is intact, but cannot cause the certificate to validate without it.

Relationship to draft-davey-tls-braid-00 This revision makes a substantive architectural correction. The -00 revision required a short-lived Delegated Credential, refreshed at least every seven days, as a mandatory element of the base profile, and it justified extended certificate lifetimes on the basis of that refresh cycle. Review of -00 correctly observed that this does not remove an operational renewal burden; it relocates it from certificate issuance to credential and anchor maintenance, and it does so in a design whose stated purpose was to reduce such burdens. The observation is correct and the -00 construction was inconsistent with the design intent. This revision separates two properties that -00 conflated under the single term "freshness":

Authorization is the state of a key being permitted to authenticate a domain. It is established once, persists without maintenance, and ends when the owner withdraws it. Authorization is the base mechanism of this document.
Revocation latency is the interval between an owner withdrawing an authorization and relying parties ceasing to accept the certificate. It is bounded by how long relying parties may cache authorization state, and it is tunable by the owner.

Short-interval credential refresh, the mechanism -00 made mandatory, is a way to reduce revocation latency and to bound the exposure of a stolen credential key. In this revision it is an optional enhancement (), not part of the base profile. An operator who adopts only the base profile publishes one DNSSEC-signed record and performs no recurring work.

Design goals

Invalidation that does not depend on a queried status service, and that does not require the participation of the issuing certification authority.
No steady-state operational burden in the base profile. Publishing the authorization is a one-time act.
More than one independently held control over a certificate's validity, so that compromise of a single credential or system is insufficient to impersonate a domain ().
Optional, owner-appointed distribution of invalidation authority to additional parties ().
No effect on relying parties that have not adopted BRAID, and no effect on the certificates they are served ().
Reuse of deployed mechanisms in preference to new ones.

Non-goals and acknowledged costs This document does not claim that BRAID is free of operational cost, and two costs are stated here rather than left to be discovered. First, until BRAID is universally supported, an operator that deploys it also continues to operate conventional certificates for clients that do not support it, and therefore continues to bear whatever renewal automation those certificates require. BRAID reduces the exposure that motivates short lifetimes; it does not, during a transition of unknown duration, remove the operational cost of short lifetimes. Operators should expect to run both. Second, the base profile depends on the domain owner operating a DNSSEC-signed zone and being able to modify a record in it. For zones that are not signed, BRAID offers nothing, and the deployment history of DNSSEC-dependent web mechanisms is not encouraging (). This document does not assert that this dependency is surmountable; it states the dependency plainly and confines the validation work it implies to the smallest form the author could find.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

BRAID Anchor: A DNSSEC-signed RRset, published by the domain owner, listing the public keys currently authorized to authenticate the domain. The Anchor is authorization state, not liveness state: it does not expire and is not refreshed on a schedule.
Circuit breaker: An authorization that a relying party checks and that an appointed party can withdraw, causing the certificate to stop validating.
Strand: A class of circuit breaker anchored in a particular trust system: Authority (the WebPKI), Identity (the owner's DNSSEC-signed zone), Routing (the RPKI), and Witness (an appointed third party).
Authentication credential: The key pair that produces the handshake signature. In this document it is carried as a Delegated Credential .
Revocation latency: The maximum interval between withdrawal of an authorization and relying parties ceasing to accept the certificate.

Overview A BRAID deployment consists of three published artifacts and one negotiated handshake behavior.

A certificate, issued by a certification authority in the ordinary way, carrying a critical BRAIDBinding extension that names which circuit breakers are required and where the Anchor is published ().
A BRAID Anchor, published once in the owner's DNSSEC-signed zone, listing the hashes of authorized authentication credential public keys ().
An authentication credential, a Delegated Credential signed by the end-entity key, whose public key hash appears in the Anchor.
Negotiation: a client indicates BRAID support in its ClientHello; a server presents a BRAID certificate only in response ().

In steady state, none of these change. The certificate may be long-lived; the Anchor is static; the credential may be issued with a validity period as long as the certificate's, unless the operator elects the optional enhancement of . To invalidate the certificate, the owner deletes the corresponding entry from the Anchor. Relying parties cease to accept the certificate within the revocation latency, which is bounded by the Anchor RRset's TTL and by relying party caching policy (). No status responder is queried, no revocation list is distributed, and the issuing certification authority is not involved.

Validation Invariant Let R be the set of circuit breakers marked required by the certificate or by relying party policy. A BRAID certificate is acceptable for a connection if and only if every member of R is intact for that connection. There is no member of R whose failure can be compensated for by another. The only permitted relaxation is the bounded degradation policy of , and only where relying party policy explicitly allows it.

The BRAID Anchor

Contents and semantics The BRAID Anchor is an RRset published in the domain owner's DNSSEC-signed zone at the name carried in the certificate. It contains a set of hashes of SubjectPublicKeyInfo structures, one for each authentication credential public key the owner authorizes to authenticate the domain, together with a version tag and the parameters of . The Anchor is authorization state. Its semantics are membership: a key is authorized if and only if its hash is present in the RRset. The Anchor carries no notion of the owner asserting continued liveness, and there is no interval within which the owner must act in order for existing authorizations to remain effective. An Anchor that is never modified authorizes the same keys indefinitely. This is the central design decision of this revision. Because the state is membership rather than freshness, publishing it is a one-time act, withdrawing it is a one-time act, and the steady state between them requires nothing. An Anchor MAY list more than one key, which permits an owner to authorize several serving locations independently and to withdraw any one of them by removing a single entry.

Parameters In addition to the authorized key set, an Anchor carries:

a maximum revocation latency, being the longest interval for which the owner permits a relying party to rely on cached authorization state (); and
optionally, a declaration that the optional freshness enhancement of is in use, and the maximum credential validity period it implies.

Publication The Anchor MUST be published in a DNSSEC-signed zone. Until a dedicated RRTYPE is allocated (), the Anchor MAY be published as a TXT record at the _braid prefix of the name carried in the certificate, and a relying party MUST treat a DNSSEC-validated TXT-form Anchor as equivalent to the native form. SPF , DKIM , and DMARC each entered production in this way. The credential used to modify the Anchor SHOULD NOT be resident on hosts that terminate TLS for the domain. The independence of these two capabilities is the basis of the Two-Control Property (); co-locating them forfeits it while leaving the deployment outwardly unchanged.

The BRAIDBinding Certificate Extension A BRAID certificate carries a critical extension, BRAIDBinding, declaring which circuit breakers are required and where their state is published. Because the extension is critical , a relying party that does not implement this document rejects the certificate rather than accepting it with a subset of the intended checks. Presentation of such a certificate to a relying party that has not negotiated BRAID is prevented by , so criticality never affects a client that has not asked for it. The extension is deliberately small. It carries:

a bitmap of which strands are required;
the DNS name at which the Anchor is published;
where the Routing strand is required, the authorized origin AS numbers and any bound address prefixes, expressed using the ASN.1 resource types of imported into a field native to this extension ();
where the Witness strand is required, the appointed witness identity and ledger locator ();
optionally, a set of name constraints limiting which identities an authentication credential may assert (); and
the policy mode under which the certificate was issued ().

A certificate SHOULD additionally carry the TLS Feature extension listing the braid_chain ExtensionType, so that tooling which already parses that extension can observe the requirement.

Use of RFC 3779 types The routing parameters import the IP address and AS identifier ASN.1 types of but MUST NOT use that document's extension object identifiers. The distinction is semantic. An extension asserts resource holdership, validated by containment within the delegation hierarchy of the address registries; a WebPKI certification authority has no standing in that hierarchy and performs no such validation. What a BRAID certificate expresses is a subscriber-requested constraint on where the certificate may be served from. Encoding the latter under the object identifiers of the former would misstate the claim and would mislead relying party software that treats those identifiers as holdership assertions.

The Identity Circuit Breaker The Identity strand is the base circuit breaker and is required in every BRAID profile.

Construction The server holds an authentication credential: a Delegated Credential , signed by the end-entity certificate's private key, whose private key produces the handshake signature. The owner publishes the hash of that credential's public key in the BRAID Anchor. A relying party requiring the Identity strand MUST verify all of the following:

the Delegated Credential validates under against the end-entity certificate;
the credential is within its stated validity interval, and, where the Anchor declares the optional enhancement of , that interval does not exceed the declared maximum;
the Anchor RRset is DNSSEC-validated under , and the relying party's copy of it is no older than the maximum revocation latency it declares; and
the hash of the credential's public key is a member of the authorized set in that Anchor.

Failure of any of these fails the strand. Check 4 is the circuit breaker: the owner trips it by removing the entry.

Credential scope binding To prevent an authentication credential from being replayed in a context other than the one for which it was issued, the credential signature MUST bind the credential to the parent end-entity certificate and to the server identity asserted in the handshake, in addition to the binding already provides. A relying party MUST reject a credential whose binding does not correspond to the certificate presented and the identity requested. The wire encoding of this binding is specified in .

Delegated name constraints A Delegated Credential inherits the full name scope of the certificate that signs it, and provides no means to narrow it. Where a credential is held by a party that legitimately serves only part of a certificate's name space, such as a content delivery edge, this over-authorizes the holder. Name Constraints are issued by certification authorities and do not apply to Delegated Credentials, so this document carries the constraint set in BRAIDBinding, expressed in the GeneralSubtrees syntax of . A relying party requiring the Identity strand MUST reject a credential asserting an identity outside the constraint set. Matching follows and is performed on lowercase A-labels; a wildcard is permitted only as the entire leftmost label, and a name that is malformed under these rules fails the strand rather than being repaired. An absent constraint set means the credential inherits the certificate's full name scope, as under today.

The Two-Control Property The Anchor authorizes the public keys of authentication credentials. It does not authorize the end-entity key, and it is not a publication of the end-entity certificate. This distinction produces the principal security property of this document. Consider an adversary who has obtained the end-entity private key. The adversary can mint a syntactically valid Delegated Credential, because the end-entity key is the delegating key; alone cannot prevent this. The credential the adversary mints, however, names a public key the adversary controls, and the adversary cannot cause the hash of that key to appear in the owner's DNSSEC-signed Anchor without also obtaining the ability to publish in that zone. Check 4 of therefore fails and the handshake is rejected. Conversely, an adversary who has obtained the ability to publish in the owner's zone can authorize a key of their choosing, but holds no certificate issued to the domain and no end-entity key with which to bind a credential to one. Impersonation therefore requires two capabilities that are independently held and, in a correct deployment, independently operated: possession of the end-entity private key, and the ability to publish in the DNSSEC-signed zone. This document refers to that as the Two-Control Property. It does not depend on any refresh interval; it follows from the Anchor authorizing credential keys and the relying party checking membership. It is preserved unchanged when the optional enhancement of is not in use. The property is forfeited if the two capabilities are co-located, which is why counsels against it.

Revocation Latency Withdrawal of an authorization is effective for a given relying party when that relying party next obtains the Anchor. Revocation is therefore not instantaneous, and this document does not claim that it is. It is bounded by the maximum revocation latency the Anchor declares, which in turn constrains how long a relying party may rely on a cached copy. The owner selects this bound, trading promptness against lookup volume. An owner requiring prompt invalidation publishes a short bound; an owner prioritizing cacheability publishes a longer one. A relying party MUST NOT rely on authorization state older than the declared bound, and MUST treat the Identity strand as failed if it cannot obtain state within it, subject to . Compared to the mechanisms this replaces, the relevant comparison is not with an idealized instantaneous revocation but with revocation that is soft-failed, not consulted, or unavailable. A bound that the owner sets and can rely upon is a different kind of guarantee from one that is nominally immediate and in practice unenforced.

Optional Enhancement: Short-Interval Credential Refresh An operator MAY elect to issue authentication credentials with a short validity period and re-mint them periodically, declaring the maximum credential validity in the Anchor. This is an enhancement to the base profile, not a component of it, and it is the mechanism that -00 required. It provides two things the base profile does not:

it bounds the exposure of a stolen credential key, which is the key most exposed to compromise because it is resident on serving hosts, without requiring the owner to notice the compromise and act; and
it provides a second bound on revocation latency, independent of relying party caching behavior, because an unrefreshed credential ceases to be valid on its own.

It costs a recurring operation: minting a credential and, where the credential key changes, updating the Anchor. Operators should weigh that against the two properties above. An operator who does not elect it retains the Two-Control Property, retains owner-controlled invalidation, and performs no recurring work; a stolen credential key then remains usable until the owner withdraws its authorization. Where this enhancement is in use, the recurring operation is a modification of a record in a zone the owner controls, on a schedule the owner chooses. It is not a transaction with a certification authority and is not gated by that authority's availability, rate limits, or validation procedures. Whether that relocation of work is an operational improvement depends on whether the operator already automates DNS, and this document does not claim it is universally so.

Optional Strand: Routing The Routing strand constrains a certificate to a network origin authorized in the routing system, defending against an adversary who diverts traffic by originating the victim's address space in order to present a certificate they hold. Its contribution is at use time. Diversion mounted to obtain a certificate at issuance time is addressed at the point of issuance by multi-perspective corroboration requirements, and independently by the Identity strand, whose Anchor never authorizes the resulting credential. A relying party does not perform validation of Resource Public Key Infrastructure objects in band. That validation is performed by relying party software that maintains a validated cache and distributes it to routers ; this document follows the same separation. Two validation methods are defined, selected by certificate and relying party policy:

Resolver-validated: The relying party consults a validating resolver or local gateway for the validation state of the connection's origin against the certificate's asserted constraints. No protocol presently allows a stub client to make this query; specifying one is companion work belonging to the DNS and routing communities, and is not defined here. Until it exists, this method is available where a local validator can be consulted directly.
Witness-corroborated: The relying party corroborates the certificate against independently reachable services co-located in the same prefix and treats a mismatch as evidence of diversion. This detects diversion in progress; it does not prevent a first connection through one. A certificate or policy requiring the resolver-validated method MUST NOT be satisfied by corroboration alone.

Address binding, where present, constrains the certificate to specific prefixes or addresses. It does not apply where the relying party connects through a terminating proxy or content delivery network, because the observed address is the intermediary's; such deployments omit it.

Optional Strand: Witness The Witness strand adds a circuit breaker held by a party other than the domain owner and the certification authority. The owner appoints the witness in the certificate; the witness co-signs an attestation that the certificate is authorized, anchored in a verifiable log using the signed-timestamp and Merkle-log structures of . This is the only circuit breaker in this document that a party other than the owner can trip. The authority is owner-appointed and owner-scoped: a relying party requires a witness only where the certificate names one, and a certificate names one only because its subscriber chose to be subject to it. A party the owner has not appointed acquires no ability to invalidate anything. This scoping is a requirement, not a convention: distributing invalidation authority without it would create a denial-of-service capability against arbitrary domains. The role is open to any party able to operate a signing key under sound key management and publish to a supported log. It requires no relationship to the WebPKI. The witness MUST be operationally independent of both the issuing certification authority and the subscriber, with separate key custody and separate administrative control; a witness that is a business unit of the issuing authority does not satisfy this requirement, because the value of the strand is that no single organization holds all the controls. By default a witness attestation is made once, when the certificate is provisioned, and remains effective until withdrawn. A deployment MAY instead give attestations a validity period and require renewal, which provides a bound on exposure analogous to and, correspondingly, a recurring cost and an availability dependency on the witness. Where renewal is required, a relying party MUST treat a lapsed attestation as withdrawn.

Negotiation and Certificate Selection BRAID requires TLS 1.3 or later , inherited from Delegated Credentials . A client that implements this document offers the braid_chain extension in its ClientHello. A server holding a BRAID certificate SHOULD select it when that extension is offered, and MUST select a conventional certificate otherwise. A BRAID certificate MUST NOT be configured as a listener's default or fallback certificate, and a server that cannot determine whether the extension was offered MUST serve the conventional certificate. Consequently a relying party that has not adopted BRAID is never shown a BRAID certificate and is unaffected by its deployment. Misconfiguration fails safely and visibly: a client shown a BRAID certificate it did not negotiate rejects it on the unrecognized critical extension, which is a loud failure rather than a silent acceptance with reduced checking. Negotiation creates a first-contact substitution surface: an adversary holding a conventional certificate for the domain may present it to a BRAID-capable client that has no prior knowledge of the domain's policy. Three mitigations are defined, in increasing strength. The owner MAY publish a DNSSEC-signed policy record declaring that the domain presents BRAID certificates, which a BRAID-capable client MUST enforce once validated. A client SHOULD cache an observed policy for its stated lifetime. A domain MAY be enrolled in a preloaded set distributed with client software, in the manner of , which protects first contact. Absent preloading, protection is second-impression, and this document does not claim otherwise.

DNSSEC Validation The Identity strand requires the relying party to obtain the Anchor with its DNSSEC validation status. This is the dependency with the least encouraging deployment history, and this document does not claim to have overcome it. It confines the work to the smallest form found and defines two modes with different trust assumptions, so that a deployment states which it relies upon.

Validated-material mode: The relying party verifies DNSSEC validation material for the Anchor itself, obtained from cached, stapled, or software-distributed authenticated snapshots, and identified by the reference transport of . It does not rely on an unauthenticated assertion of validation by a resolver. This mode is intended for relying parties that cannot trust their local resolution path.
Managed-resolver mode: The relying party relies on validation performed by a resolver it is configured to trust, reached over an authenticated and encrypted transport . This mode is appropriate where the resolver is operated under the same administrative policy as the relying party, and is not appropriate for a general-purpose client on an arbitrary network.

A relying party MUST NOT treat an unauthenticated assertion of DNSSEC validation from an arbitrary resolver as satisfying either mode. In-band transport of a DNSSEC chain in the manner of is OPTIONAL and is not a dependency of this document; that specification is Experimental and did not reach consensus for the standards track in this working group, and the base profile does not rest on it.

Proof Transport and Caching Anchor state and its validation material are transported by reference. The server sends compact identifiers in the braid_chain extension; the relying party resolves them from cache, and only on a miss obtains the material itself. Each reference is a cryptographic hash of the material it names, and a relying party MUST verify that any material it uses matches the reference before relying on it. Cache entries are therefore self-certifying and may be shared across connections and origins. This distinguishes BRAID from a queried status protocol. The relying party is not making a per-connection request to a third party about a particular certificate, and MUST NOT do so. On a cache miss it SHOULD obtain the material from the server it is already connecting to, which learns nothing new, and MAY use a shared repository only over a privacy-preserving transport such as or from a prefetched snapshot. The privacy failure that attended online status checking is thereby avoided by construction rather than by policy. The steady-state server flight carries the certificate chain, the authentication credential, and compact references, and remains within the initial congestion window . Because referenced material changes only when the owner changes it, the amortized per-connection cost approaches zero. A relying party MUST bound the number of references it will accept in a handshake to those required by the certificate's declared strands, MUST bound the size of material it will parse, and SHOULD negatively cache failed resolutions for a bounded interval.

Deployment Enforcement is staged, in the manner of : a domain progresses from monitor, in which relying parties evaluate and report but do not block, through staged, to strict. An operator enables strict only on the evidence of its own monitoring. The first stage requires no protocol implementation by anyone. An owner publishes an Anchor and compares, out of band, the credentials its endpoints actually serve against the keys it has authorized. This detects misconfiguration, unauthorized issuance, and stale edge state, and it exercises the withdrawal path before anything depends on it. It requires no change to any TLS implementation, certification authority, or root program.

Bounded degradation Where relying party policy permits, a relying party that cannot obtain Anchor state because of a verifiable and attributable infrastructure failure MAY degrade to conventional validation rather than failing closed. The evidence for such a failure MUST be unforgeable by an adversary who can merely cause requests to fail; an adversary positioned to withhold material can trivially manufacture the appearance of an outage, and a relying party MUST NOT accept, as evidence of outage, failures observed only over a path that adversary may control. Deployments requiring the strongest assurance SHOULD disable degradation.

Relationship to Existing Mechanisms

DANE TLSA with certificate usage 1 A domain owner may today publish, in DNSSEC, an association to its end-entity certificate , and may withdraw that record to invalidate the association. This is simpler than BRAID and is available now, and any mechanism in this space must state what it adds. What it adds is the Two-Control Property (). A certificate usage 1 association names the end-entity certificate. An adversary in possession of the end-entity private key presents the genuine certificate and proves possession of the genuine key; the association is satisfied and the relying party accepts. The association constrains which certification authority may have issued the certificate, which is a different and useful property, but it does not constrain who may use the key. A BRAID Anchor names authentication credential keys. An adversary in possession of the end-entity key can mint credentials but cannot authorize them, because authorization is published in a zone the adversary does not control. Impersonation requires both capabilities rather than either. Whether that additional property justifies the additional mechanism is a question this document poses rather than settles. It is offered as a genuine difference in what compromise is required, not as a reformulation.

The TLS Feature extension established the structural idea this document depends upon: a validation requirement signed into the certificate, which an on-path adversary cannot strip. Its deployment difficulty was that the requirement pointed at a dependency the subscriber did not operate, whose unavailability made hard failure untenable. BRAID retains the mechanism and reuses the extension, and changes the dependency to one the subscriber publishes and controls. Whether that is sufficient to make hard failure tenable is an empirical question, and the staged deployment of exists so that operators can answer it for themselves before enforcing.

Delegated Credentials This document uses unchanged as a credential container. It adds an authorization check on the credential's public key and, optionally, a scope constraint. It does not modify the credential format, define a new one, or alter the semantics of the existing one.

Wire Format The encodings of the braid_chain TLS extension, the BRAIDBinding certificate extension, the BRAID Anchor RRset and its TXT interim form, the policy record, and the credential scope binding of are not specified in this revision. They will be specified in a subsequent revision, informed by implementation of the deployment stage described in , which does not depend on them. The author considers it more useful to establish whether the architecture is sound before fixing its encodings, and notes that the mechanism described here can be exercised operationally, as described in , without any of them.

Security Considerations Two-Control Property. The property of holds only where the ability to publish in the DNSSEC-signed zone is not available from hosts holding the end-entity key. A deployment that automates Anchor publication from its TLS-terminating hosts has the outward appearance of BRAID and one control rather than two. Stolen credential keys. In the base profile, a stolen authentication credential key remains usable until its authorization is withdrawn. The base profile bounds the consequences of compromise by making withdrawal effective and unilateral; it does not bound them by expiry. Operators for whom unnoticed compromise is the dominant risk should elect , which bounds exposure without requiring the compromise to be noticed. Revocation is not immediate. applies. A deployment that requires immediate global invalidation is not served by this mechanism. Availability. Strict enforcement couples the reachability of a service to the availability of its DNSSEC-signed zone. This is a real coupling and the staged deployment of , the caching of , and the bounded degradation of reduce but do not eliminate it. Degradation is itself an attack surface and is constrained accordingly. Resolution path. applies to the Anchor as it does to any DNSSEC-dependent mechanism. A relying party that cannot establish the validation status of the Anchor by one of the two defined modes MUST treat the strand as failed rather than as satisfied. Distributed invalidation authority. The Witness strand permits a party other than the owner to invalidate a certificate. This is a capability the owner grants deliberately by naming that party, and it is available to no party the owner has not named. A witness that is unavailable, compromised, or coerced can deny service to the domains that appointed it, which is the risk an owner accepts in exchange for the assurance the strand provides. Downgrade. analyses first-contact substitution and states plainly that, absent preloading, protection begins at second contact. Privacy. No per-connection query is made to any third party about a certificate or a domain. constrains cache-miss resolution so that this remains true in the non-steady state.

Implementation Status This section records the status of implementation per . It is to be removed before publication. No implementation of the negotiated protocol exists. The deployment stage described in requires none, and an out-of-band monitor implementing it, which compares the credentials served by an endpoint against a DNSSEC-signed Anchor and reports the result, is under development by the author and is intended for demonstration at the IETF 126 Hackathon against infrastructure the author operates, including a domain, a private certification authority, and address space originated by the author's autonomous system. The components this document composes are individually deployed at scale: Delegated Credentials in a major browser and in widely used TLS libraries; DNSSEC validation in major recursive resolvers; Certificate Transparency logging and monitoring ; preload distribution in the manner of ; and issuance automation .

IANA Considerations This document requests, in a subsequent revision that specifies their encodings:

a TLS ExtensionType for braid_chain;
a single object identifier for the BRAIDBinding certificate extension, within which all parameters of this document are serialized, so that no additional certificate extension identifiers are required;
a DNS RRTYPE for the BRAID Anchor and a format for the policy record;
a log entry type for witness attestations; and
registries for policy modes and strand identifiers.

The Anchor and policy RRTYPEs require DNS expert review; the validated-origin query described in belongs to the DNS and routing communities; and the ASN.1 of BRAIDBinding, including its syntax-only import of the resource types of , warrants review by the working group responsible for PKIX maintenance.

Acknowledgements Eric Rescorla reviewed draft-davey-tls-braid-00 and identified that its mandatory credential refresh relocated rather than removed an operational burden, that operators would bear both that burden and conventional certificate renewal during any transition, that its reliance on client-side DNSSEC validation was not adequately addressed, and that its properties should be compared against publishing an end-entity association in DNSSEC directly. The architecture of this revision is a direct response to those observations, and the author is grateful for them.