Bound Routing, Authority, and Identity Data (BRAID): Multi-Strand TLS Certificates with Structural, Owner-Controlled Revocation
draft-davey-tls-braid-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | George Davey | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-davey-tls-braid-00
TLS G. Davey
Internet-Draft Davey Group LLC
Intended status: Standards Track 3 July 2026
Expires: 4 January 2027
Bound Routing, Authority, and Identity Data (BRAID): Multi-Strand TLS
Certificates with Structural, Owner-Controlled Revocation
draft-davey-tls-braid-00
Abstract
This document defines BRAID, a negotiated profile and set of protocol
mechanisms for publicly trusted TLS server certificates whose
continued validity is bound to multiple independent "strands": the
issuing certificate authority's signature (the Authority strand), an
owner-controlled, DNSSEC-anchored freshness authorization carried by
a short-lived Delegated Credential (the Identity strand), and an
optional routing assertion that constrains the certificate to a
network origin authorized in the global routing system (the Routing
strand). An optional Witness strand adds an appointed third-party
co-signature. The requirement to satisfy each strand is signed into
the certificate, so the strands are load-bearing rather than
advisory: a certificate that is missing or has a withdrawn required
strand simply does not validate, and revocation becomes structural
and owner-controlled rather than an optional status check.
Impersonating a protected domain requires the concurrent compromise
of two independently held credentials --- the end-entity key and the
owner's DNS publication path --- not either alone. Because a
compromised certificate can be neutralized within a short freshness
window, BRAID certificates MAY be issued with multi-year validity
periods, subject to root-program policy. BRAID support is negotiated
in the handshake, so a server presents a BRAID certificate only to a
client that offers to validate it and presents a conventional
certificate otherwise; deployment therefore breaks no existing
client. To remain deployable, BRAID reuses existing standards and
certificate structures rather than reinventing them: short-lived keys
use Delegated Credentials (RFC 9345); the requirement flag reuses the
TLS Feature extension (RFC 7633); routing constraints reuse the ASN.1
resource types of RFC 3779 inside BRAID's own extension; witness
attestations reuse the Certificate Transparency signed-timestamp and
Merkle-log formats; routing validation is delegated to the client's
RPKI-validating resolver rather than performed in band; large
validation proofs are transported by reference with client-side
caching to stay within the initial congestion window; and enforcement
is staged from monitor to strict using a policy model adapted from
SPF, DKIM, and DMARC, including a graceful-degradation mode that
bounds the availability risk of fail-closed operation.
Davey Expires 4 January 2027 [Page 1]
Internet-Draft BRAID Multi-Strand Certificates July 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Security goals . . . . . . . . . . . . . . . . . . . . . 5
1.2. The braid metaphor and the strands . . . . . . . . . . . 5
1.3. BRAID profiles . . . . . . . . . . . . . . . . . . . . . 6
1.4. Requirements language . . . . . . . . . . . . . . . . . . 6
2. Security Invariant . . . . . . . . . . . . . . . . . . . . . 7
3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Negotiation and Certificate Selection . . . . . . . . . . . . 9
5. The BRAID Binding Certificate Extension . . . . . . . . . . . 10
6. What Each Strand Signs . . . . . . . . . . . . . . . . . . . 12
7. The Identity Strand: Owner-Controlled Liveness via Anchored
Delegated Credentials . . . . . . . . . . . . . . . . . . 13
7.1. Construction . . . . . . . . . . . . . . . . . . . . . . 13
7.2. The two-key security property . . . . . . . . . . . . . . 14
7.3. Delegated name constraints . . . . . . . . . . . . . . . 15
Davey Expires 4 January 2027 [Page 2]
Internet-Draft BRAID Multi-Strand Certificates July 2026
8. The Routing Strand: Resolver-Validated Origin and Address
Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. The Witness Strand: Appointed Co-Signing and Ledger
Pairing . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Witness eligibility and independence . . . . . . . . . . 19
9.2. Witnessed freshness . . . . . . . . . . . . . . . . . . . 19
9.3. Public verifiability with private use . . . . . . . . . . 20
10. Proof Transport: braid_chain and Reference-Based Caching . . 20
10.1. Resource management and denial of service . . . . . . . 21
11. Structural Revocation and Revocation Transparency . . . . . . 22
12. Validity Period . . . . . . . . . . . . . . . . . . . . . . . 22
13. Deployment Model and Graceful Degradation . . . . . . . . . . 23
14. Deployment Phases: Running Today, Strengthening Over Time . . 24
15. Deployment Profiles . . . . . . . . . . . . . . . . . . . . . 26
16. Comparison with Related Mechanisms . . . . . . . . . . . . . 27
17. Performance Considerations . . . . . . . . . . . . . . . . . 29
17.1. Handshake size and the initial congestion window . . . . 29
17.2. Cold start and caching . . . . . . . . . . . . . . . . . 30
17.3. Client computation . . . . . . . . . . . . . . . . . . . 31
17.4. Amplification and QUIC . . . . . . . . . . . . . . . . . 31
17.5. Server cost . . . . . . . . . . . . . . . . . . . . . . 31
18. Cryptographic Agility and Post-Quantum Migration . . . . . . 32
19. Security Considerations . . . . . . . . . . . . . . . . . . . 32
20. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 34
21. Implementation Status . . . . . . . . . . . . . . . . . . . . 34
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
23.1. Normative References . . . . . . . . . . . . . . . . . . 35
23.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
The maximum validity period of publicly trusted TLS certificates has
been reduced repeatedly and is scheduled to reach 47 days. The
stated motivation is to limit the exposure window of a stolen or mis-
issued certificate. This is a direct consequence of a deeper
failure: certificate revocation, the mechanism intended to cancel a
bad certificate before its natural expiry, has never worked reliably
at internet scale. Online status checks (OCSP) have been deprecated
by major browsers for privacy, latency, and "soft-fail" reasons, and
traditional certificate revocation lists are not consulted in a way
that protects users.
Shortening certificate lifetimes is a mitigation, not a remedy. It
imposes a permanent operational burden that falls hardest on small
and independent operators, and it does not repair the underlying
Davey Expires 4 January 2027 [Page 3]
Internet-Draft BRAID Multi-Strand Certificates July 2026
mechanism. This document takes the opposite approach: rather than
making certificates expire quickly so that broken revocation matters
less, it makes revocation structural and owner-controlled so that
certificates can safely live for years.
The core observation is that today's external checks are optional: a
TLS client will accept a certificate even when revocation information
is unavailable. The TLS Feature extension [RFC7633] ("must-staple")
demonstrated the right structural idea --- a validation requirement
signed into the certificate by the CA, which an on-path attacker
cannot strip --- but it failed in deployment because the requirement
pointed at an unreliable dependency: a third-party OCSP responder
whose outages made hard-fail enforcement untenable, so clients
enforced it softly or not at all. BRAID retains the signed-
requirement mechanism and replaces the dependency. The evidence a
BRAID certificate requires is published and refreshed by the
certificate's own owner, under keys and infrastructure the owner
controls, so the party that bears the availability risk is the party
with the power and incentive to manage it. An on-path attacker can
withhold a strand but cannot make the certificate validate without
it; a certificate missing a required strand is invalid. Fail-closed
is achieved by construction, subject to the bounded graceful-
degradation policy of Section 13.
Two design principles shape this revision. First, reuse over
reinvention: BRAID does not define a new short-lived key format, a
new requirement-flag extension, a new encoding for network resources,
or a new transparency-log format; it composes Delegated Credentials
[RFC9345], the TLS Feature extension [RFC7633], the resource-encoding
ASN.1 types of [RFC3779], and the Certificate Transparency structures
[RFC6962]/[RFC9162], each of which has deployed parsers and
operational history. Second, keep expensive validation off the
client's critical path: browsers do not parse DNSSEC or RPKI in band;
those functions live at the resolver and in dedicated relying-party
software, where they already run today.
BRAID changes nothing for parties that do not adopt it, and ---
because support is negotiated (Section 4) --- deploying it breaks
nothing for parties that have not yet adopted it. A client signals
in its ClientHello that it can validate BRAID; a server presents a
BRAID certificate only to such clients and presents a conventional
certificate to all others. A CA may keep issuing short-lifetime
certificates unchanged, and a client that does not implement BRAID
validates ordinary certificates exactly as before. The mechanism is
purely additive --- an enhanced option a CA MAY offer and an operator
MAY adopt to obtain long-lived, structurally revocable certificates
in exchange for running the supporting machinery. It is therefore
complementary to, not a replacement for, the prevailing move toward
Davey Expires 4 January 2027 [Page 4]
Internet-Draft BRAID Multi-Strand Certificates July 2026
shorter lifetimes: the two can coexist, and each operator chooses the
trade-off that fits it rather than being moved onto a single path.
Deployment is correspondingly phased (Section 14): the earliest phase
runs entirely on infrastructure deployed today, requiring no new
client, CA, or protocol code, and every subsequent phase delivers
standalone security value rather than a promise redeemed later.
1.1. Security goals
BRAID aims to provide, for operators that opt in:
* Structural revocation: a certificate cannot be used once its
owner-controlled freshness evidence lapses, without reliance on a
queried status service.
* Owner-controlled revocation: the domain holder, not only the CA,
can neutralize a certificate within a bounded freshness window.
* Multiple independent trust anchors: forging a valid certificate
requires defeating more than one of the WebPKI, the DNSSEC
hierarchy, and the routing system; and using a stolen end-entity
key requires additionally compromising the owner's DNSSEC-signed
zone (Section 7).
* Long-lived, low-churn certificates: validity periods of multiple
years without increasing the practical exposure window.
* Incremental, reversible, negotiated deployment: enforcement can be
adopted in stages, with telemetry, without breaking any reachable
site or any legacy client.
* Reuse over reinvention: the requirement flag, short-lived keys,
network-resource encoding, transparency structures, and routing
validation all rely on existing standards.
1.2. The braid metaphor and the strands
A single strand is weak; strands woven together are strong, and the
braid unravels if any required strand is cut. BRAID defines a base
of two strands plus optional enhancement strands an operator MAY add
when the deployment and threat model warrant. Each strand is an
independent attestation anchored in a distinct trust system:
* *Authority strand* (base) --- the X.509 certificate signed by a
publicly trusted CA [RFC5280], logged to Certificate Transparency
[RFC6962]/[RFC9162].
Davey Expires 4 January 2027 [Page 5]
Internet-Draft BRAID Multi-Strand Certificates July 2026
* *Identity strand* (base) --- an owner-controlled freshness
authorization: a short-lived Delegated Credential [RFC9345] whose
public key is authorized in a DNSSEC-signed BRAID Anchor record
under the domain holder's control (Section 7).
* *Routing strand* (optional) --- an assertion, checked against the
client's locally validated routing data, that the connection
originates from a network authorized in the Resource Public Key
Infrastructure (RPKI) [RFC6480]/[RFC6482], optionally narrowed to
a specific IP prefix or single address, expressed in the
certificate using the ASN.1 resource types of [RFC3779] carried
inside the BRAIDBinding extension (Section 8).
* *Witness strand* (optional) --- a counter-signature from an
appointed third party, anchored in a public log, a public
blockchain, or a secured private ledger, encoded as a signed-
timestamp structure in the manner of Certificate Transparency
(Section 9).
1.3. BRAID profiles
The strands compose into named profiles, each a strict superset of
the previous one, so operators adopt only the assurance they need:
* *BRAID-Base* --- Authority + Identity strands. Delivers owner-
controlled, structural revocation (Section 11) and is the broadly
deployable baseline.
* *BRAID-Routed* --- adds the Routing strand (with optional address
binding). Eligible for the extended validity period of
Section 12.
* *BRAID-Witnessed* --- adds the Witness strand, with an optional
private-use mode that keeps a certificate publicly verifiable
while gating its use to authorized parties (Section 9).
Profiles above BRAID-Base are enhanced options, not requirements; a
relying party enforces a strand only when it is marked REQUIRED in
the certificate or by the relying party's own policy.
1.4. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
and "MAY" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals.
Davey Expires 4 January 2027 [Page 6]
Internet-Draft BRAID Multi-Strand Certificates July 2026
2. Security Invariant
BRAID validation reduces to a single rule. Let R be the set of
strands marked REQUIRED by the certificate or by relying-party
policy. A certificate is valid for a connection if and only if every
required strand validates for that connection:
valid(cert, connection) <=> for all s in R : verify(s, cert, connection) = TRUE
This is a logical conjunction: there is no strand whose failure can
be compensated for by another. The only relaxation permitted is the
bounded graceful-degradation policy of Section 13, and only when the
relying party's configured policy explicitly allows it.
3. Threat Model
BRAID is designed against the following adversaries. Each row states
the attack and the strand or mechanism that mitigates it.
+================+=================================================+
| Attack | Primary mitigation |
+================+=================================================+
| Stolen end- | Identity strand: the DNSSEC-signed BRAID Anchor |
| entity private | authorizes specific Delegated Credential keys; |
| key | a thief holding only the end-entity key cannot |
| | place a credential key of their own into the |
| | owner's signed zone, so credentials the thief |
| | mints are rejected (Section 7) |
+----------------+-------------------------------------------------+
| Stolen | Bounded by the freshness window (at most seven |
| Delegated | days); owner rotates the Anchor to exclude it |
| Credential key | immediately |
+----------------+-------------------------------------------------+
| Mis-issued or | Identity strand mismatch with the owner's BRAID |
| fraudulent | Anchor; Certificate Transparency and Revocation |
| certificate | Transparency logging |
+----------------+-------------------------------------------------+
| CA compromise | Independent Identity strand: a CA-signed |
| | certificate not authorized by the owner's |
| | DNSSEC anchor does not validate |
+----------------+-------------------------------------------------+
| DNS/DNSSEC | Authority strand (CA validation) and, where |
| compromise at | present, Routing strand remain independent |
| the owner's | anchors; forging a usable certificate |
| zone | additionally requires a CA-signed certificate |
| | and its private key |
+----------------+-------------------------------------------------+
| Simultaneous | Witnessed freshness (optional): the witness's |
Davey Expires 4 January 2027 [Page 7]
Internet-Draft BRAID Multi-Strand Certificates July 2026
| compromise of | renewal lever is independent of both and stops |
| the owner's | the certificate within one window (Section 9.2) |
| DNS and the | |
| end-entity key | |
+----------------+-------------------------------------------------+
| BGP hijack at | Routing strand: origin-AS check against locally |
| connection | validated RPKI data; optional address binding |
| time (use-time | (Section 8) |
| hijack) | |
+----------------+-------------------------------------------------+
| BGP hijack to | Primarily mitigated at issuance by the CA/ |
| pass domain- | Browser Forum requirement for Multi-Perspective |
| control | Issuance Corroboration; the Identity strand |
| validation at | independently rejects the resulting |
| issuance | certificate, whose credentials the owner's |
| | Anchor never authorized |
+----------------+-------------------------------------------------+
| Stale or | Structural freshness: absence of current |
| unreachable | evidence fails the handshake within the |
| revocation | freshness window |
+----------------+-------------------------------------------------+
| Use of a valid | Witness strand private-use mode: authorization |
| certificate by | gate on session establishment |
| an | |
| unauthorized | |
| party | |
+----------------+-------------------------------------------------+
| Downgrade to a | BRAID Policy record and preloaded BRAID- |
| non-BRAID | required set (Section 4) |
| certificate | |
| against a | |
| BRAID-capable | |
| client | |
+----------------+-------------------------------------------------+
| Registry/ | Graceful-degradation policy (Section 13) with |
| resolver | proof-of-outage, bounded by relying-party |
| outage causing | policy |
| mass failure | |
+----------------+-------------------------------------------------+
Table 1
The Identity strand's headline property is stated precisely in
Section 7: neutralizing it requires the compromise of two
independently held secrets --- the end-entity private key and the
ability to publish in the owner's DNSSEC-signed zone --- not either
alone.
Davey Expires 4 January 2027 [Page 8]
Internet-Draft BRAID Multi-Strand Certificates July 2026
4. Negotiation and Certificate Selection
BRAID requires TLS 1.3 or later [RFC8446]; the Identity strand
inherits this floor from Delegated Credentials, which are defined
only for TLS 1.3 [RFC9345]. The BRAIDBinding extension is critical
(Section 5), so a client that does not implement BRAID will reject a
BRAID certificate. BRAID therefore MUST be negotiated, and a server
MUST NOT present a BRAID certificate to a client that has not offered
to validate it.
*Client signal.* A BRAID-capable client offers the braid_chain
extension (Section 10) in its ClientHello, alongside the
delegated_credential extension of [RFC9345] that the Identity strand
requires. The presence of braid_chain in the ClientHello is the
client's declaration that it implements this document and will
enforce the certificate's required strands.
*Server certificate selection.* A server operating a BRAID deployment
holds both a BRAID certificate and a conventional certificate for the
same identity (or serves populations of clients through distinct
endpoints). If the ClientHello offers braid_chain, the server SHOULD
select the BRAID certificate and respond with the braid_chain
extension; otherwise it MUST select the conventional certificate and
complete an ordinary TLS 1.3 handshake [RFC8446]. This mirrors the
certificate-selection model already deployed for Delegated
Credentials and for signature-algorithm negotiation, and it means
BRAID adoption is invisible to every legacy client, crawler, and
embedded device.
*Operational isolation of the BRAID certificate.* The remaining
deployment risk is server-side misconfiguration: a default-
certificate rule, an unsynchronized load-balancer fleet, or an SNI-
routing error that serves the BRAID certificate to a client that
never offered braid_chain. A BRAID certificate MUST NOT be
configured as the default or fallback certificate of any listener; it
is selected only on an affirmative braid_chain offer, and a server
that cannot determine the offer state MUST serve the conventional
certificate. Two properties bound the residual risk. The failure
direction is safe: a legacy client shown a BRAID certificate rejects
it loudly on the unrecognized critical extension --- a hard, visible
handshake failure, never a silent acceptance with weakened
validation. And the failure is observable before it matters: the
misconfiguration manifests as a spike of such alerts in exactly the
aggregate reporting that the monitor phase of Section 13 requires
operators to run before enforcement.
Davey Expires 4 January 2027 [Page 9]
Internet-Draft BRAID Multi-Strand Certificates July 2026
*Downgrade resistance.* Negotiation creates a first-contact downgrade
surface: an attacker who has stolen a conventional certificate for
the domain could strip the client's braid_chain offer or simply
answer with the stolen conventional certificate. BRAID closes this
in three graduated ways. First, the owner publishes a DNSSEC-signed
BRAID Policy record (Section 13) whose strict mode instructs BRAID-
capable clients that the domain MUST present a BRAID certificate; a
BRAID-capable client that has validated such a record MUST reject a
conventional certificate for that domain. Second, domains MAY be
enrolled in a preloaded BRAID-required set distributed with client
software, in the manner of HSTS [RFC6797], which protects even the
first contact. Third, a client SHOULD cache a domain's observed
BRAID policy for its stated lifetime, so that any subsequent
downgrade within that lifetime fails. Note that the conventional
certificate a BRAID operator holds for legacy clients is, by design,
short-lived under prevailing root-program rules, so the residual
downgrade exposure against BRAID-capable clients is bounded by the
shorter of the policy-record lifetime and the conventional
certificate's own lifetime.
*Coexistence rationale.* This dual-certificate model is a feature,
not a transition cost: the long-lived BRAID certificate eliminates
renewal churn for the population of clients that can enforce its
guarantees, while the conventional certificate covers the long tail.
As BRAID-capable clients become the majority, the conventional
certificate becomes a fallback artifact whose short lifetime matters
less because it serves less traffic.
5. The BRAID Binding Certificate Extension
A BRAID certificate carries a critical X.509 extension, BRAIDBinding,
declaring which strands are REQUIRED and the minimal parameters
needed to locate and verify them. Because the extension is marked
critical [RFC5280], any client that does not understand BRAID MUST
reject the certificate rather than treat it as an ordinary
certificate; this prevents a silent downgrade to single-strand
validation. Presentation of such a certificate to non-BRAID clients
is prevented by the negotiation of Section 4, so criticality never
strands a legacy client.
BRAID deliberately keeps BRAIDBinding small by expressing every
parameter that has an existing, deployed X.509 encoding in that
encoding rather than a new one:
* *Requirement flag.* In addition to the criticality of BRAIDBinding
itself, the certificate SHOULD carry the TLS Feature extension
[RFC7633] listing the braid_chain ExtensionType, declaring in the
long-standing "must-staple" idiom that the handshake is required
Davey Expires 4 January 2027 [Page 10]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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);
Davey Expires 4 January 2027 [Page 11]
Internet-Draft BRAID Multi-Strand Certificates July 2026
* 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).
Davey Expires 4 January 2027 [Page 12]
Internet-Draft BRAID Multi-Strand Certificates July 2026
* *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.
7.1. Construction
The mechanism composes three parts, of which only the third is new:
1. *The Delegated Credential, per [RFC9345] 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 [RFC9345] 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
(Section 5), 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 [RFC8555], 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.
Davey Expires 4 January 2027 [Page 13]
Internet-Draft BRAID Multi-Strand Certificates July 2026
3. *The client's conjunctive check.* A client requiring the Identity
strand MUST verify all of: (a) the Delegated Credential validates
under [RFC9345] 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.
7.2. The two-key security property
The check in step 3(c) is what converts [RFC9345] 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 --- [RFC9345]
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.
Davey Expires 4 January 2027 [Page 14]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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.
7.3. Delegated name constraints
A Delegated Credential inherits the full name scope of the end-entity
certificate that signs it: [RFC9345] 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 [RFC5280]
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 (Section 5), expressed
in the GeneralSubtrees syntax of [RFC5280], 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 [RFC6125]: 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 [RFC9345] 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
(Section 15) materially safer at no added handshake cost.
Davey Expires 4 January 2027 [Page 15]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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
Davey Expires 4 January 2027 [Page 16]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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
Davey Expires 4 January 2027 [Page 17]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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.
Davey Expires 4 January 2027 [Page 18]
Internet-Draft BRAID Multi-Strand Certificates July 2026
9.1. 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
Section 9.2, sustain) a usable certificate. A witness that is a
business unit of the issuing CA does not satisfy this requirement.
9.2. 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
(Section 7); 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 Section 13 applies to verifiable witness outages as it does to
other strand infrastructure.
Davey Expires 4 January 2027 [Page 19]
Internet-Draft BRAID Multi-Strand Certificates July 2026
9.3. 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 Section 20).
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 Section 13.
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.
Davey Expires 4 January 2027 [Page 20]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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.
10.1. 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
(Section 10) 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 (Section 13) --- 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 [RFC9458] 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.
Davey Expires 4 January 2027 [Page 21]
Internet-Draft BRAID Multi-Strand Certificates July 2026
In-band stapling of a full DNSSEC chain, in the style of the
experimental TLS DNSSEC Chain Extension [RFC9102], is supported only
as an OPTIONAL fallback. BRAID does not make [RFC9102] --- 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 Section 17.
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
Davey Expires 4 January 2027 [Page 22]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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
Davey Expires 4 January 2027 [Page 23]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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
Davey Expires 4 January 2027 [Page 24]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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
Davey Expires 4 January 2027 [Page 25]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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 | Phase 1 | Phases 2--4 (public web) |
| | (observe) | (closed | |
| | | ecosystems) | |
+===========+===========+=============+===========================+
| Authority | Enforced | Enforced | Enforced (as today) |
| | (as | (as today) | |
| | today) | | |
+-----------+-----------+-------------+---------------------------+
| Identity | Advisory, | Enforced in | monitor -> staged -> |
| | out of | managed | strict (Section 13) |
| | band | clients | |
+-----------+-----------+-------------+---------------------------+
| Routing | Not | Optional, | Policy-selected method |
| | evaluated | via local | (Section 8); preventive |
| | | validator | form arrives with Phase 4 |
+-----------+-----------+-------------+---------------------------+
| Witness | Not | Enforced | Optional per profile |
| | evaluated | where | (Section 1.3) |
| | | profiled | |
+-----------+-----------+-------------+---------------------------+
Table 2
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).
Davey Expires 4 January 2027 [Page 26]
Internet-Draft BRAID Multi-Strand Certificates July 2026
* *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).
Davey Expires 4 January 2027 [Page 27]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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.
+============+======+==========+========+============+==============+
|Capability |TLS/ |OCSP |DANE |Delegated | BRAID |
| |WebPKI|Must- | |Creds (RFC | |
| | |Staple | |9345) | |
| | |(RFC | | | |
| | |7633) | | | |
+============+======+==========+========+============+==============+
|Independent |No |No |Yes |No | Layered |
|of CA trust | | | | | (multi- |
| | | | | | anchor) |
+------------+------+----------+--------+------------+--------------+
|Owner- |No |No |Yes |No | Yes |
|controlled | | | | | |
|revocation | | | | | |
+------------+------+----------+--------+------------+--------------+
|Revocation |No |Signed- |Optional|N/A | Yes |
|is mandatory| |in, but | | | (structural) |
|to use | |soft- | | | |
| | |failed in | | | |
| | |practice | | | |
+------------+------+----------+--------+------------+--------------+
|Freshness |n/a |CA's OCSP |Owner |Operator | Owner |
|evidence | |responder |(DNS) |(unanchored)| (DNSSEC |
|controlled | | | | | anchor) |
|by | | | | | |
+------------+------+----------+--------+------------+--------------+
|Safe for |Yes |Yes |Yes |Yes | Yes |
|legacy | | | | | (negotiated; |
Davey Expires 4 January 2027 [Page 28]
Internet-Draft BRAID Multi-Strand Certificates July 2026
|clients | | | | | Section 4) |
+------------+------+----------+--------+------------+--------------+
|Routing- |No |No |No |No | Yes |
|aware | | | | | (optional) |
+------------+------+----------+--------+------------+--------------+
|In-band |No |No |Yes |No | No |
|browser | | |(issue) | | (resolver- |
|DNSSEC/RPKI | | | | | side) |
|parsing | | | | | |
+------------+------+----------+--------+------------+--------------+
|Steady-state|Low |Low + |High |Low (+~1 KB)| Low |
|handshake | |staple |(in-band| | (references |
|overhead | | |DNSSEC) | | + DC) |
+------------+------+----------+--------+------------+--------------+
|Short-lived |n/a |n/a |n/a |Yes | Yes (uses |
|key reuse of| | | | | RFC 9345) |
|a standard | | | | | |
+------------+------+----------+--------+------------+--------------+
|Long-lived |No |No |Partial |n/a | Yes (up to 5 |
|certificate,| | | | | yr; |
|low churn | | | | | Section 12) |
+------------+------+----------+--------+------------+--------------+
Table 3
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.
17.1. Handshake size and the initial congestion window
The relevant constraint is the IW10 initial congestion window of
approximately 14,600 bytes (ten segments) [RFC6928]: 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.
Davey Expires 4 January 2027 [Page 29]
Internet-Draft BRAID Multi-Strand Certificates July 2026
+======================+================+=====================+
| Server's first- | In-band design | This document |
| flight component | (rejected) | (steady state) |
+======================+================+=====================+
| Authority | ~3 KB | ~3 KB |
| certificate chain | | |
+----------------------+----------------+---------------------+
| Delegated Credential | n/a | ~0.5--1 KB |
| (Identity) | | |
+----------------------+----------------+---------------------+
| DNSSEC chain to | 1.5--3 KB | 0 (by reference; |
| BRAID Anchor | stapled | resolver-validated) |
+----------------------+----------------+---------------------+
| RPKI objects | 2--5 KB | 0 (resolver-side; |
| (Routing) | stapled | not on client) |
+----------------------+----------------+---------------------+
| Witness / inclusion | 1--2 KB | ~32--100 B |
| proofs | | (reference) |
+----------------------+----------------+---------------------+
| braid_chain | n/a | ~100--300 B |
| references | | |
+----------------------+----------------+---------------------+
| *Total server | *~10--15+ KB* | *~4--4.5 KB* |
| flight* | | |
+----------------------+----------------+---------------------+
Table 4
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 [RFC8446]. Reference-based transport (Section 10) and
resolver-side routing validation (Section 8) are precisely what
remove the multi-kilobyte components that would otherwise overflow
the window.
17.2. 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 (Section 10). 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
Davey Expires 4 January 2027 [Page 30]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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.
17.3. 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 [RFC9345] 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 (Section 7); 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 [RFC6810]/[RFC8210]. 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.
17.4. 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.
17.5. 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 [RFC9345] already
entails.
Davey Expires 4 January 2027 [Page 31]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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.
Davey Expires 4 January 2027 [Page 32]
Internet-Draft BRAID Multi-Strand Certificates July 2026
*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.
Davey Expires 4 January 2027 [Page 33]
Internet-Draft BRAID Multi-Strand Certificates July 2026
*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:
Davey Expires 4 January 2027 [Page 34]
Internet-Draft BRAID Multi-Strand Certificates July 2026
* 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
23.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/rfc/rfc3779>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
Davey Expires 4 January 2027 [Page 35]
Internet-Draft BRAID Multi-Strand Certificates July 2026
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/rfc/rfc6125>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <https://www.rfc-editor.org/rfc/rfc7633>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/rfc/rfc9345>.
23.2. Informative References
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/rfc/rfc6482>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>.
Davey Expires 4 January 2027 [Page 36]
Internet-Draft BRAID Multi-Strand Certificates July 2026
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/rfc/rfc6797>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
DOI 10.17487/RFC6810, January 2013,
<https://www.rfc-editor.org/rfc/rfc6810>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/rfc/rfc6928>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/rfc/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/rfc/rfc7489>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 1",
RFC 8210, DOI 10.17487/RFC8210, September 2017,
<https://www.rfc-editor.org/rfc/rfc8210>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
Davey Expires 4 January 2027 [Page 37]
Internet-Draft BRAID Multi-Strand Certificates July 2026
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/rfc/rfc8914>.
[RFC9102] Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M.
Shore, "TLS DNSSEC Chain Extension", RFC 9102,
DOI 10.17487/RFC9102, August 2021,
<https://www.rfc-editor.org/rfc/rfc9102>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[RFC9458] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/rfc/rfc9458>.
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.
Davey Expires 4 January 2027 [Page 38]
Internet-Draft BRAID Multi-Strand Certificates July 2026
* 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
Davey Expires 4 January 2027 [Page 39]
Internet-Draft BRAID Multi-Strand Certificates July 2026
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
George Davey
Davey Group LLC
Email: BRAID@cpu.io
Davey Expires 4 January 2027 [Page 40]