Rooting Decentralized Identifiers in DNSSEC: A DANE-EE Key-Binding Profile
draft-ranjbar-dane-did-01
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) | |
|---|---|---|---|
| Authors | Kaveh Ranjbar , Anivar A Aravind | ||
| Last updated | 2026-08-01 | ||
| 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-ranjbar-dane-did-01
Network Working Group K. Ranjbar
Internet-Draft Whisper Security (viaGraph B.V.)
Intended status: Standards Track A. A. Aravind
Expires: 2 February 2027 Independent Researcher
1 August 2026
Rooting Decentralized Identifiers in DNSSEC: A DANE-EE Key-Binding
Profile
draft-ranjbar-dane-did-01
Abstract
Several Decentralized Identifier (DID) methods root trust in a DNS
name: did:web binds an identifier to a domain and today verifies its
keys over the Web PKI, did:dns serves DID data from DNS resource
records, and did:webvh retrieves its history from an HTTPS location
derived from a name. Each either depends on the Web PKI, treats
DNSSEC as an optional recommendation, or does not bind the
verification-method key to the name at all. This document defines a
single, normative DANE-EE key-binding profile that any DNS-anchored
DID method can point at rather than reinventing: a verification
method's public key is published as a TLSA record with certificate
usage DANE-EE(3), selector SubjectPublicKeyInfo(1), and matching type
SHA2-256(1) under a DNSSEC-signed name, so that a relying party can
confirm the key from the DNS root of trust with no certificate
authority and no fetch from the subject. The profile binds a name to
a key and the key to the specific DID document it signs, and no
further; it states precisely what it does not cover, including
continuity of holding, and points to where those answers live.
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 2 February 2027.
Ranjbar & Aravind Expires 2 February 2027 [Page 1]
Internet-Draft Rooting DIDs in DNSSEC August 2026
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
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. The DANE-EE Key-Binding Profile . . . . . . . . . . . . . . . 4
3.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 5
3.2. Selector SubjectPublicKeyInfo(1) . . . . . . . . . . . . 5
3.3. Matching Type SHA2-256(1), with a Fallback . . . . . . . 6
3.4. DNSSEC Requirement . . . . . . . . . . . . . . . . . . . 7
4. Owner Name Convention . . . . . . . . . . . . . . . . . . . . 7
5. Binding a Record to a Verification Method . . . . . . . . . . 8
6. Scope of the Assertion: Name to Key to Document, and No
Further . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Applicability to DID Methods . . . . . . . . . . . . . . . . 10
7.1. did:web . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. did:dns . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. did:webvh . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Key Rotation . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. Trust in the DNSSEC Chain . . . . . . . . . . . . . . . 12
10.2. Continuity of Holding . . . . . . . . . . . . . . . . . 13
10.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . 13
10.2.2. Two Questions, Not One . . . . . . . . . . . . . . . 13
10.2.3. Mechanisms . . . . . . . . . . . . . . . . . . . . . 14
10.2.4. Requirements on Conformant Use . . . . . . . . . . . 16
10.3. No Attestation Beyond the Key Binding . . . . . . . . . 17
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Ranjbar & Aravind Expires 2 February 2027 [Page 2]
Internet-Draft Rooting DIDs in DNSSEC August 2026
1. Introduction
A recurring pattern spans the Decentralized Identifier (DID) methods
that root trust in the Domain Name System. did:web [DID-WEB] binds a
DID to a fully qualified domain name and, in current deployments,
establishes trust in the keys in its DID document through the Web PKI
certificate presented when the document is fetched over HTTPS.
did:dns [DID-DNS] assembles a DID document directly from DNS resource
records and recommends, but does not require, DNSSEC. did:webvh
[DID-WEBVH] derives an HTTPS retrieval location from a name but
deliberately relocates trust onto a self-certifying, hash-chained
history rather than onto the name. The individual "High Assurance
DIDs with DNS" draft [HIGH-ASSURANCE-DIDS] pointed the way here. It
reached for DNSSEC and DANE/TLSA to harden exactly this surface, and
it introduced the _did scoping this document reuses. As an
individual submission it expired before adoption and left the profile
to be completed: it pinned the TLSA selector but carried the
certificate usage and matching type only in its examples, kept DNSSEC
as a recommendation, and left its Security Considerations as a
placeholder. This document takes up that direction and carries it to
a complete profile, naming and defending each TLSA field, requiring
DNSSEC for trust-bearing keys, and writing the security
considerations that were left open.
Across all of these, the same primitive keeps surfacing: a public key
that ought to be bound to a DNS name in a way any party can verify
from the root, without a certificate authority in the path and
without contacting the subject. This document specifies that
primitive once, as a profile that a DNS-anchored DID method can
reference normatively instead of each method reinventing a slightly
different DNS key binding. The DID Resolution specification
[DID-RESOLUTION] reflects the division of labor: it standardizes how
a DID is resolved to a DID document but leaves the authenticity of
that document, and of the verification-method keys it carries, to the
applicable DID method. For methods rooted in a DNS name, this
profile supplies that authenticity.
The profile is deliberately narrow. It defines how a verification
method's key is published in DNS and verified, and it fixes the scope
of the resulting assertion: the name controls the key, and the key
signed a specific DID document, and nothing beyond that. It is
complementary to each method's existing mechanisms rather than a
replacement for any of them, and it is the DID-facing companion to
the general DANE-anchored identity model
[I-D.ranjbar-dane-anchored-identity], sharing that document's key-
binding record while adding the DID-specific owner-name,
verification-method, and scope-ceiling rules.
Ranjbar & Aravind Expires 2 February 2027 [Page 3]
Internet-Draft Rooting DIDs in DNSSEC August 2026
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses DNS terminology from [RFC9499] and DID terminology
from [DID-CORE], including "DID", "DID document", "verification
method", and "DID controller".
DID DNS name: The DNSSEC-signed domain name under which a DID's TLSA
records are published. For a method whose identifier contains a
domain (for example did:web and did:dns), the DID DNS name is that
domain, with any port component stripped; identifiers that differ
only in port or in path components share one DID DNS name, with
the consequences given in Section 7.1. For a method whose trust
is not rooted in the name (for example did:webvh), the DID DNS
name is the domain from which the DID's document is retrieved, and
the binding is treated as an OPTIONAL anchor (see Section 7).
Bound key: The public key of a verification method in a DID document
that this profile binds to the DID DNS name.
3. The DANE-EE Key-Binding Profile
A bound key is published as a TLSA record [RFC6698] with certificate
usage DANE-EE(3), selector SubjectPublicKeyInfo(1), and, by default,
matching type SHA2-256(1), the combination written "3 1 1" in the
mnemonics of [RFC7218]. The record MUST be published under a DNSSEC-
signed name (see Section 4), and a relying party MUST validate the
DNSSEC chain to a trust anchor before relying on it (see
Section 3.4). Each of the three fields is chosen deliberately, and
the reasoning is given with each below, because a profile that cannot
defend a field invites that field to be renegotiated. The matching
type carries a sanctioned fallback under the robustness principle,
given in Section 3.3.
DANE and the TLSA record are defined for authenticating TLS endpoints
[RFC6698]. This profile reuses the TLSA record as the carrier for a
DNSSEC-anchored key binding outside any TLS handshake: a relying
party confirms a verification-method key against the record rather
than authenticating a TLS peer. Publishing under the _did owner name
of Section 4, which carries no port or transport label, signals that
non-TLS use. The TLSA requirements this profile imports are,
exactly: the RDATA syntax and field semantics of [RFC6698]
(Section 2.1); the DNSSEC validation-state rules of [RFC6698]
Ranjbar & Aravind Expires 2 February 2027 [Page 4]
Internet-Draft Rooting DIDs in DNSSEC August 2026
(Section 4.1) as restated in Section 3.4 and Section 5; the DANE-
EE(3) semantics of [RFC7671] (Section 5.1); and the rollover
procedure of [RFC7671] (Section 8.1). The TLS-specific requirements
of both documents, including port/transport owner naming, SNI and
reference-identifier rules, and the RRset-wide procedures of
[RFC7671] (Sections 8 and 9) except as restated in Section 5, do not
apply. A purpose-specific resource record, or a key carried in a
record whose type asserts nothing about transport, may be a cleaner
long-term binding; that open question is shared with
[I-D.ranjbar-dane-anchored-identity] and is not resolved here. The
key-binding itself, a DNSSEC-signed name committing to a
SubjectPublicKeyInfo, does not depend on the record type chosen to
carry it.
3.1. Certificate Usage DANE-EE(3)
The certificate usage MUST be DANE-EE(3). Under DANE-EE, "the
binding of the server public key to its name is based entirely on the
TLSA record association" ([RFC7671], Section 5.1): there is no PKIX
certification path to validate, no issuing certificate authority to
trust, and no requirement that any name in a certificate match a
reference identity. The trust in the key chains only through the
DNSSEC delegation hierarchy to the root, not through the Web PKI.
The other certificate usages are unsuitable for this profile because
each reintroduces an issuer. Usages PKIX-TA(0) and PKIX-EE(1)
require the presented certificate to also validate through the Web
PKI, keeping a certificate authority in the trust path. Usage DANE-
TA(2) designates a domain-operated trust anchor, which is a
certificate authority that every party relying on names in the zone
must trust, together with a chain to validate. Only DANE-EE(3)
removes the issuer entirely and makes the DNSSEC-signed name the sole
authority for the key. Because cross-organization identity requires
a single globally agreed root of trust that is not a commercial
certificate authority, and the DNS root is the only such root, DANE-
EE(3) is the certificate usage that expresses this profile's trust
model rather than an incidental parameter of it.
3.2. Selector SubjectPublicKeyInfo(1)
The selector MUST be SubjectPublicKeyInfo(1). The record therefore
binds the DER-encoded SubjectPublicKeyInfo [RFC5280] of the
verification-method key ([RFC6698], Section 2.1.2), not a full
certificate. Selector SPKI(1) "is compatible with raw public keys
[RFC7250] and the resulting TLSA record need not change across
certificate renewals with the same key" ([RFC7671], Section 5.1).
Ranjbar & Aravind Expires 2 February 2027 [Page 5]
Internet-Draft Rooting DIDs in DNSSEC August 2026
A DID verification method expresses a bare public key, for example as
a publicKeyJwk or as a Multikey publicKeyMultibase value, and
typically has no X.509 certificate at all. Selector Full(0) presumes
a certificate and so cannot bind such a key; selector SPKI(1) binds
exactly the object a verification method carries. Binding the key
rather than a certificate also lets a controller present the same key
at more than one layer, so adopting this profile requires no re-
keying of already-deployed verification methods.
The digest input is the DER-encoded SubjectPublicKeyInfo of the
verification-method key. For keys expressed as publicKeyJwk or as a
Multikey publicKeyMultibase value, publisher and relying party MUST
derive the SubjectPublicKeyInfo deterministically: for Ed25519 and
X25519 keys per [RFC8410]; for ECDSA keys per [RFC5480], using the
uncompressed point form; for RSA keys per [RFC3279]. A key type
without a defined deterministic SubjectPublicKeyInfo encoding cannot
be bound under this profile until one is specified.
3.3. Matching Type SHA2-256(1), with a Fallback
Except as provided below, a publisher MUST publish the bound key with
matching type SHA2-256(1): the SHA-256 digest of the
SubjectPublicKeyInfo ([RFC6698], Section 2.1.3), a fixed 32 octets
whatever the size of the key.
The reason to hash is that the DID document already carries the key.
The record only has to confirm it, not to carry it, so a digest is
enough. Full(0) would republish the whole key in DNS for no gain,
and for a large post-quantum key it risks an oversized response.
SHA2-256(1) is also the one matching type that is mandatory to
implement ([RFC7671], Section 2), so it is the most interoperable
choice, and SHA2-512(2) buys no real strength for a key commitment of
this kind. Keeping the record to a digest keeps DNS in the role of
confirming a key the method carries, rather than holding a second
copy of it that can drift from the document.
Following the robustness principle, a relying party SHOULD also
accept a securely validated DANE-EE(3), SPKI(1), Full(0) record, that
is "3 1 0", for the same key, so that a publisher that has already
exposed the unhashed SubjectPublicKeyInfo, for example to let the key
be recovered directly from DNS or because it followed the earlier
"High Assurance DIDs with DNS" examples, still interoperates. Where
SHA2-256(1) genuinely cannot be used, a publisher MAY publish "3 1 0"
instead. The exact match carries the whole key rather than its
digest, so it is larger but not weaker; this profile prefers "3 1 1"
for size and uniformity and treats "3 1 0" as a sanctioned fallback,
not a second first-class form.
Ranjbar & Aravind Expires 2 February 2027 [Page 6]
Internet-Draft Rooting DIDs in DNSSEC August 2026
A deployment that anticipates digest-algorithm agility MAY
additionally publish a record with a stronger matching type alongside
the SHA2-256(1) record; verifiers process Full(0) records and the
records of the strongest digest algorithm they support ([RFC7671],
Section 9), subject to the per-key restriction of Section 5.
3.4. DNSSEC Requirement
TLSA records under this profile MUST be served from a DNSSEC-signed
zone [RFC4033] [RFC9364]. A relying party MUST validate the DNSSEC
chain from a trust anchor and MUST NOT rely on a TLSA record whose
validation state is not secure. A TLSA response whose DNSSEC
validation state is bogus MUST cause the verification to fail
([RFC6698], Section 4.1). Where a referencing DID method today
expresses DNSSEC as a recommendation, adopting this profile makes
DNSSEC validation a requirement for keys carried under it.
4. Owner Name Convention
TLSA records under this profile are published under the globally
scoped underscore label _did (0x5F 0x64 0x69 0x64) prepended to the
DID DNS name, consistent with the underscored-name scoping of
[RFC8552] and with the prior _did usage in [HIGH-ASSURANCE-DIDS].
Publishing under a dedicated _did name, rather than under a transport
name such as _443._tcp, keeps the binding independent of any
assumption that the key is used for TLS.
The RRset at _did.<did-dns-name> MAY hold one TLSA record for each
verification method to be bound; a relying party selects the record
whose association data matches the verification method it is
evaluating (Section 5). A method that requires per-key addressing
MAY instead publish each record under a per-method label, as _<vm-
label>._did.<did-dns-name>, where <vm-label> is derived from the
fragment of the verification method's id as follows: the fragment is
lowercased; every octet outside the set a-z, 0-9, and hyphen is
replaced by the two lowercase hexadecimal digits of its value; and if
the resulting label would exceed 62 octets, the label is instead the
lowercase hexadecimal SHA-256 digest of the original fragment
truncated to 32 octets. A referencing method MUST specify which of
the two placements it uses so that resolution is deterministic.
Zones publishing per-method labels SHOULD NOT contain wildcard
records that can synthesize responses within the _did subtree
([RFC8552], Section 1.4); a synthesized answer is validly signed and
would bind whatever the wildcard carries.
The _did subtree is also used, with URI records under per-identifier
labels, by the did:dns method. The two uses coexist by record type:
this profile's records are TLSA records, and a relying party under
Ranjbar & Aravind Expires 2 February 2027 [Page 7]
Internet-Draft Rooting DIDs in DNSSEC August 2026
this profile ignores records of other types at the same owner name.
A did:dns deployment adopting this profile SHOULD choose per-method
labels that do not collide with its existing identifier labels.
Aliases are permitted, subject to a single relying-party check on the
signer. A relying party MAY follow CNAME or DNAME redirection when
resolving the _did owner name, provided every link in the alias chain
has a DNSSEC validation status of "secure". After validating the
TLSA RRset, the relying party MUST confirm that the signer of that
RRset's covering RRSIG is the zone containing the DID DNS name or a
descendant of that zone; if it is any other zone, verification MUST
fail. A relying party MUST NOT fall back to querying the original
owner name when no TLSA record exists at the expanded name. This
check permits intra-zone aliases, for example a canonical per-
verification-method name, and delegation to a child zone, where the
change of authority is visible in the DNSSEC chain of trust, while
rejecting redirection into any zone the DID DNS name does not sit
above. Operators who hand authority to another party SHOULD use an
NS delegation rather than an alias. The alias-following behaviour of
[RFC7671] (Section 7) is SHOULD-strength, and Section 4 of that
document invites application profiles to specify tighter guidance,
which this paragraph does.
5. Binding a Record to a Verification Method
For each verification method to be bound, the controller computes the
SHA-256 digest of the DER-encoded SubjectPublicKeyInfo of that
method's public key and publishes it as a 3 1 1 TLSA record under the
owner name of Section 4.
A relying party evaluating a verification method:
1. determines the DID DNS name for the DID being verified, as
specified by the referencing method;
2. retrieves the TLSA RRset under the _did owner name and validates
its DNSSEC chain to a trust anchor (Section 3.4);
3. computes, from the DID document, the DER-encoded
SubjectPublicKeyInfo of the verification-method key (Section 3.2)
and its digest under each matching type present in the RRset; and
4. accepts the key as bound if and only if a securely validated TLSA
record under that name with certificate usage DANE-EE(3) and
selector SPKI(1) matches the key under that record's matching
type: by carrying the DER-encoded SubjectPublicKeyInfo itself for
Full(0), or its digest for a hashed matching type.
Ranjbar & Aravind Expires 2 February 2027 [Page 8]
Internet-Draft Rooting DIDs in DNSSEC August 2026
Because one RRset MAY hold records for several distinct keys
(Section 4), the digest-algorithm agility procedure of [RFC7671]
(Section 9) MUST NOT be applied across the RRset as a whole: a record
is discarded as a weaker duplicate only relative to other records
matching the same key, never because a stronger record exists for a
different key. The publisher-side RRset-consistency requirement of
[RFC7671] (Section 8), which presumes all records describe one
server's chain, likewise does not apply across records for distinct
keys; it applies per key during rotation (Section 8).
The distinct outcomes of the lookup MUST be kept apart. The key is
bound only on a securely validated matching record. The key is
established as not published under this profile only when the absence
of a matching record is itself securely validated, by a DNSSEC-
validated negative response for the owner name or a securely
validated RRset containing no matching record. A lookup whose
validation state is bogus, insecure, or indeterminate establishes
neither, and MUST be treated as a verification failure for this
profile, not as absence; treating a stripped or downgraded response
as "not published" would let an on-path attacker demote every binding
to the referencing method's fallback. Referencing methods define
whether a securely-established-absent key is usable by other means;
this profile makes no such key bound.
6. Scope of the Assertion: Name to Key to Document, and No Further
The assertion established by this profile is bounded and MUST be
treated as such. A securely validated 3 1 1 record establishes that
the DID DNS name controls the bound key. Together with a signature
made by that key over the DID document (as defined by the referencing
method), it establishes that the name controls a key that signed that
specific document. It establishes nothing further.
The second step of that assertion exists only where the referencing
method defines how a DID document is signed by a bound key, for
example with a data-integrity proof carried in the document. A
referencing method that claims the document-level assertion MUST
define that mechanism. For a method that defines none, the assertion
under this profile stops at name-controls-key, the remainder of a
retrieved DID document is authenticated only by whatever channel
delivered it, and the referencing method SHOULD state that limit
explicitly rather than leave it to be discovered. (Section 10.2.4
applies the same discipline to continuity: a stated non-goal is not a
gap.)
In particular, this profile does not, by itself, establish the real-
world identity of the DID subject, the identity or accountability of
the DID controller, any delegated authority or scope, or any
Ranjbar & Aravind Expires 2 February 2027 [Page 9]
Internet-Draft Rooting DIDs in DNSSEC August 2026
reputation or history associated with the DID. Each of those is a
separate claim that carries its own evidence, validity interval, and
revocation, and a relying party MUST NOT infer any of them from a
valid key binding alone. Anything not asserted remains not
established, rather than being read as true or as false; a relying
party SHOULD fail closed on an unmet dependency, so that, for
example, a revoked delegation fails even while the TLSA record and
the document signature still validate.
The same boundary applies to who acted through the key. A valid
binding shows that a key signed a document; it does not show whether
a human or an agent operated that key, nor who any decision made with
it concerns. Those are descriptive, non-authorizing facts that
belong in separate records, such as the operator-of-record and
decision-subject claims of [I-D.aravind-oauth-operator-of-record] and
[I-D.aravind-oauth-decision-subject]. This profile neither carries
nor depends on them, and a relying party MUST NOT infer them from the
binding.
Referencing specifications and conformance tests SHOULD include a
negative fixture that pins this ceiling: one securely validated name
and key, and two DID documents with different subjects signed such
that the key signed only one of them; a conforming verifier accepts
only the document the key actually signed and fails closed on the
other. A profile or implementation that accepts both is overreaching
the assertion this binding makes.
7. Applicability to DID Methods
This profile is a single reference that DNS-anchored DID methods can
point at. It is complementary: it changes where a key is rooted and
how a relying party confirms it, not how a method otherwise operates.
7.1. did:web
did:web's live trust rests on the DNS-to-TLS binding of the domain in
its identifier, and its DNSSEC guidance is a non-normative
recommendation. A did:web profile that references this document
binds each DID-document verification-method key as a 3 1 1 record
under _did.<domain>, giving a DNS-rooted confirmation of the key that
does not depend on the Web PKI certificate used to retrieve the
document. A deployment MAY additionally require that the certificate
presented when retrieving the DID document validate against a DANE-EE
record for the retrieval endpoint; that transport hardening is a
separate, did:web-specific application and is not the key binding
this profile defines.
Ranjbar & Aravind Expires 2 February 2027 [Page 10]
Internet-Draft Rooting DIDs in DNSSEC August 2026
A did:web identifier may carry path components
(did:web:example.com:user:alice). For such an identifier the DID DNS
name is the domain alone, so the party able to publish and sign the
TLSA record is the domain operator, not the DID controller named by
the path. The binding then attests that the domain operator vouches
for the key. That is a hosted arrangement: the operator is the
accountable party of record, and nothing in the DNS distinguishes one
path-based subject's binding from another's. A deployment in which
the subject is to be the attested party gives the subject a delegated
name (for example did:web:alice.example.com, with
_did.alice.example.com in a zone cut the subject controls or that the
operator delegates per subject), so the binding sits in a namespace
scoped to that subject. A referencing profile SHOULD state which of
the two arrangements it provides, because a relying party cannot tell
them apart from the RRset alone.
7.2. did:dns
did:dns assembles a DID document by resolution: it publishes URI
records under underscore-scoped labels in the _did subtree whose
values are did:key identifiers, each dereferenced to a verification
method, and its resolution steps say DNSSEC SHOULD be used. A
did:dns profile that references this document tightens that SHOULD to
the requirement of Section 3.4 for trust-bearing keys and adds a 3 1
1 TLSA record binding each verification-method key. The bound object
is the SubjectPublicKeyInfo of the public key encoded in the did:key
value (Section 3.2), not the did:key string or the URI record.
Consistent with did:dns keeping DID-document keys independent of
DNSSEC zone keys, the record binds the verification-method key, never
the zone-signing or key-signing key. Coexistence with did:dns's URI
records in the same subtree is per Section 4.
7.3. did:webvh
did:webvh deliberately roots trust in a self-certifying, hash-
chained, optionally witnessed history rather than in its DNS name,
and instructs clients not to infer control from the domain. For
did:webvh this profile MUST be treated as an OPTIONAL additional
anchor, at the same level as its witnesses (parties whose proofs over
log entries gate publication) and watchers (parties that observe
resolution over time), and never as a replacement for its self-
certifying history. A did:webvh deployment MAY bind the keys of an
equivalent did:web representation using this profile, giving DNS-
rooted assurance to relying parties that consume that representation,
without altering did:webvh's own trust model.
Ranjbar & Aravind Expires 2 February 2027 [Page 11]
Internet-Draft Rooting DIDs in DNSSEC August 2026
8. Key Rotation
To rotate a bound key without a verification gap, a controller
publishes the 3 1 1 record for the new key alongside the record for
the current key at least two TTLs before the new key is presented,
then removes the old record after the transition ([RFC7671],
Section 8.1). During the overlap both keys validate, and relying
parties converge on the new key as caches expire.
Rotation under this profile changes which key the name currently
authorizes. It does not, by itself, attest that the party
controlling the name after a rotation is the same party that
controlled it before; see Section 10.
9. Revocation
A bound key is revoked by removing or replacing its TLSA record.
Because relying parties validate against live DNS, withdrawal takes
effect for them within the record's TTL; but a DNSSEC-signed RRset
cannot be securely revoked before its signatures expire ([RFC7671],
Section 11), so a withdrawn RRset remains replayable to any verifier
not querying the authoritative path until the RRSIG validity period
ends. Revocation latency under this profile is therefore bounded by
the larger of the TTL and the remaining signature validity.
Operators publishing bound keys SHOULD choose short TTLs and short
signature validity periods, re-signing frequently; [RFC7671]
(Section 11) suggests lifetimes of a few days, with daily re-signing,
for high-value keys. This is revocation of the key binding. It is
not offline or stapled revocation, and it is not per-signature
revocation; a signature made earlier is not retroactively invalidated
by withdrawing the binding, which is why verification of a past proof
is treated separately in Section 10.
10. Security Considerations
10.1. Trust in the DNSSEC Chain
The security of a binding rests entirely on the DNSSEC validation
chain of the DID DNS name. A relying party MUST validate DNSSEC to a
trust anchor and reject any non-secure result. The operator of the
zone MUST protect its zone-signing and key-signing keys accordingly;
compromise of those keys is equivalent to compromise of every key
bound under the zone. This profile moves part of the trust onto the
DNS operator, the parent zone, and the registrar of the name;
registrar or zone compromise is the corresponding failure mode. The
profile is therefore an additional, independent root that a relying
party MAY require, not a claim to be stronger than, or a replacement
for, the mechanisms a referencing method already uses.
Ranjbar & Aravind Expires 2 February 2027 [Page 12]
Internet-Draft Rooting DIDs in DNSSEC August 2026
10.2. Continuity of Holding
10.2.1. Scope
This profile binds a key to a name under the name's current DNSSEC
delegation. It certifies one fact: the name presently controls this
key. That is a controller snapshot, valid at the moment it is
checked. It carries no evidence that the party controlling the name
today is the party that controlled it when a binding was first
recorded. [RFC6698] (Section 2.1.1) calls usage 3 a "domain-issued
certificate", one a domain name administrator can issue without a
third-party CA; the administrator it trusts is whoever controls the
zone at the moment of the query, which is exactly what a transfer
changes.
Two adjacent problems are out of scope here and should not be
confused with this one. The first is the illegitimate takeover:
[RFC7671] (Section 11) names the risk of a rogue registrar initiating
an unauthorized domain transfer and recommends a registrar lock
against it. This section addresses the legitimate case instead, a
lapsed registration and a drop-catch, a UDRP transfer, or an ordinary
sale, each producing a new, validly DNSSEC-signed TLSA record under
the same name, indistinguishable at the protocol level from the
routine rotation described in Section 8. The second is key
continuity: [RFC5011] and trust-on-first-use key-continuity
management answer whether the key has changed against a cached value.
The question here is whether the party behind the name changed, which
no key comparison can answer, because a new holder's key is validly
signed too.
The gap is sharper under this profile than under a CA-issued binding.
[RFC7671] (Section 5.1) requires that with DANE-EE(3) the expiration
date of the server certificate MUST be ignored, and that the validity
period of the key binding is determined by the validity period of the
TLSA record's DNSSEC signatures. The binding therefore has no
lifetime independent of the zone, and the zone is under the control
of whoever holds the name now. A new holder republishes, and the
binding is freshly valid, with no residual signal from the prior
holder's tenure.
This profile MUST NOT be read as providing continuity of holding, and
implementers MUST NOT assume it absent explicit continuity evidence
per this section.
10.2.2. Two Questions, Not One
Evidence of continuity answers one of two distinct questions, and
MUST be labeled as to which.
Ranjbar & Aravind Expires 2 February 2027 [Page 13]
Internet-Draft Rooting DIDs in DNSSEC August 2026
Currency: is the binding a relying party is about to act on still the
one presently published for the name? This can be answered only at
or near the time of reliance. It decays with time, and MUST be re-
checked before use in any decision where the interval since the last
check is material to the relying party.
Historical validity: was the binding valid at some earlier, fixed
point, for example when a signature, decision, or credential was
produced? This is answered once, at or soon after that point. It
does not decay, and it cannot be re-checked later against the live
name.
Evidence answering the historical-validity question MUST NOT be
presented or accepted as evidence answering the currency question. A
stapled proof from six months ago demonstrates that the binding was
valid six months ago. It says nothing about whether the name has
changed hands since, and a relying party checking currency MUST NOT
treat it as sufficient.
For a short-lived, continuously re-validated credential such as a TLS
certificate issued under [RFC8555], the distinction matters little,
because control is re-proven at each issuance and the credential
expires on its own. It matters for a DID, which another party may
record once and re-verify much later, where no re-proof of current
control is forced.
10.2.3. Mechanisms
None of the following are part of the DANE-EE binding itself. Each
answers one of the two questions in Section 10.2.2, and a
specification or deployment invoking any of them MUST state which.
10.2.3.1. Registry-Observable Continuity (RDAP)
A relying party MAY query RDAP [RFC7480] [RFC9082] [RFC9083] for the
name at or near the time of reliance, and check for transfer,
redemption, or expiration events more recent than the reference
binding it holds. The authoritative record of a name changing hands
is not in the DNS; it is at the registry, exposed as eventAction
values including registration, transfer, and expiration ([RFC9083],
Section 4.5) and as status values such as pending transfer, client
transfer prohibited, redemption period, and pending delete
([RFC9083], Section 4.6; [RFC8056], Section 2).
Ranjbar & Aravind Expires 2 February 2027 [Page 14]
Internet-Draft Rooting DIDs in DNSSEC August 2026
Coverage is uneven by design, and implementers are advised not to
over-rely on it. Expiration events are mandatory under ICANN's gTLD
RDAP profile; transfer events are recorded at the registry's
discretion; and outside the gTLD contract there is no equivalent
obligation, so ccTLD support is inconsistent.
This mechanism answers the currency question. It requires trusting
the registry's live state at query time, and is not usable offline or
against a cached binding without a fresh query.
10.2.3.2. Stapled Historical Proof
To verify a proof as it stood at an earlier time, a relying party
cannot fetch a past TLSA or DNSKEY from live DNS, which serves only
current state. A proof, credential, or signed record MAY instead
carry the DNSSEC validation chain and TLSA record that were current
at the time it was produced (the TLSA record together with its RRSIG,
DNSKEY, and DS records up to the publicly archived root trust
anchor), serialized in the manner of [RFC9102] and stapled to the
artifact itself, so that a later verifier can confirm which key the
name published at that time. [RFC9102] is an Experimental mechanism
defined for TLS; its chain serialization is the reusable part here.
This mechanism answers the historical-validity question only. It is
distinct from the live-DNS revocation of Section 9, and it MUST NOT
be presented as, or accepted as, evidence of present continuity.
10.2.3.3. Witnessed Continuity Log
The sequence of a name's key bindings MAY be recorded in an append-
only log of the shape described in [RFC6962] and [RFC9162], such that
a relying party can check a binding against a log entry.
This mechanism answers the currency question, but only to the extent
that the log's independence from the party publishing the binding is
itself verifiable. A log that is append-only but maintained solely
by the operator whose bindings it records MUST NOT be treated as
satisfying this mechanism. An operator who controls both the binding
and its log can suppress or omit an entry without detection, and a
consistency proof will not reveal it: a consistency proof establishes
that the log is append-only between two states, not that the log
presents the same state to every party that checks it.
A conformant log MUST therefore expose an externally-anchored
commitment, for example periodic publication of its state to a log
operated by a different party, against which a verifier can check
that the view it was served is the view others were served.
Ranjbar & Aravind Expires 2 February 2027 [Page 15]
Internet-Draft Rooting DIDs in DNSSEC August 2026
Implementers should note that no IETF specification currently defines
such a mechanism. The nearest existing instantiation is outside the
IETF: did:webvh's witness and watcher roles (Section 7.3) supply
independent parties whose proofs and observations bound what a log
operator can misrepresent, though that specification, too, stops
short of defining how a verifier confirms that the view it was served
is the view others were served. [RFC9162] (Section 11.3)
acknowledges that a misbehaving log can show inconsistent views to
different clients and places the mechanisms that would detect this
outside its scope. Deployments relying on this mechanism therefore
MUST state how the log's independence is established, per
Section 10.2.4.
did:webvh, discussed in Section 7.3, reaches the same property within
its own method, by rooting trust in a verifiable history rather than
in the name. Where this profile is used alongside that method, the
method's history is the continuity mechanism and this profile is an
OPTIONAL key anchor beside it, not a substitute for it.
10.2.4. Requirements on Conformant Use
A specification or deployment that addresses continuity of holding
for a binding under this profile MUST:
* state explicitly that the base DANE-EE key binding does not itself
provide continuity of holding (Section 10.2.1);
* identify which mechanism or mechanisms in Section 10.2.3 it relies
on;
* state which question in Section 10.2.2 each relied-upon mechanism
answers;
* where the witnessed-log mechanism (Section 10.2.3.3) is used,
state how the log's independence from the publishing operator is
established.
A specification that does not address continuity of holding SHOULD
say so explicitly, rather than leave the property unaddressed by
omission. Silence reads as a gap only the affected relying parties
discover the hard way. A stated non-goal does not.
Ranjbar & Aravind Expires 2 February 2027 [Page 16]
Internet-Draft Rooting DIDs in DNSSEC August 2026
10.3. No Attestation Beyond the Key Binding
Because the binding is to a public key and not to an issued
certificate, there is no issuing authority attesting to the subject
beyond what registration data provides. Applications that require
identity, controllership, or delegation assurances MUST obtain them
by other means and MUST treat a valid binding as proof of key control
under the current delegation only, per Section 6.
11. Privacy Considerations
A binding is public by construction: the _did name, the TLSA record,
and any associated registration data are visible to anyone. This
removes the call-home privacy exposure of fetching a key from the
subject, at the cost of publishing a stable, enumerable key binding
whose activity can be correlated [RFC9076]. Deployments that publish
one binding per DID or per verification method SHOULD consider
whether such correlation is acceptable and MAY scope or rotate names
where it is not. Registration data exposed through RDAP SHOULD be
minimized to what accountability requires.
12. IANA Considerations
This document defines no new DNS resource record type and no new TLSA
field values; it profiles existing values from [RFC6698] and
[RFC7218].
The _did underscored node name was introduced by the earlier "High
Assurance DIDs with DNS" work [HIGH-ASSURANCE-DIDS]; no _did entry
for any RR type appears in the registry at the time of writing. This
document requests that IANA register the node name _did for the TLSA
RR type in the "Underscored and Globally Scoped DNS Node Names"
registry [RFC8552], with this document as the reference, following
the precedent of the _dane entry registered for TLSA by [RFC7671].
Use of the _did subtree with other RR types by DID methods (see
Section 7.2) is unaffected by this registration and is left to those
methods to register for their own record types.
13. References
13.1. Normative References
[DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", 2022,
<https://www.w3.org/TR/did-core/>.
Ranjbar & Aravind Expires 2 February 2027 [Page 17]
Internet-Draft Rooting DIDs in DNSSEC August 2026
[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>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <https://www.rfc-editor.org/rfc/rfc3279>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/rfc/rfc5480>.
[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>.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
Conversations about DNS-Based Authentication of Named
Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April
2014, <https://www.rfc-editor.org/rfc/rfc7218>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.
[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>.
[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed448, X25519, and X448 for Use in the Internet
X.509 Public Key Infrastructure", RFC 8410,
DOI 10.17487/RFC8410, August 2018,
<https://www.rfc-editor.org/rfc/rfc8410>.
Ranjbar & Aravind Expires 2 February 2027 [Page 18]
Internet-Draft Rooting DIDs in DNSSEC August 2026
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/rfc/rfc8552>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/rfc/rfc9364>.
13.2. Informative References
[DID-DNS] Danube Tech, "The did:dns Method", n.d.,
<https://danubetech.github.io/did-method-dns/>.
[DID-RESOLUTION]
W3C Decentralized Identifier Working Group, "Decentralized
Identifier Resolution (DID Resolution)", n.d.,
<https://www.w3.org/TR/did-resolution/>.
[DID-WEB] W3C Credentials Community Group, "did:web Method
Specification", n.d.,
<https://w3c-ccg.github.io/did-method-web/>.
[DID-WEBVH]
Decentralized Identity Foundation, "did:webvh DID Method
(did:web + Verifiable History) v1.0", n.d.,
<https://identity.foundation/didwebvh/v1.0/>.
[HIGH-ASSURANCE-DIDS]
Carter, J. and J. Latour, "High Assurance DIDs with DNS",
n.d., <https://datatracker.ietf.org/doc/draft-carter-high-
assurance-dids-with-dns/>.
[I-D.aravind-oauth-decision-subject]
Aravind, A. A., "Decision-Subject Representation for Agent
Authorization", Work in Progress, Internet-Draft, draft-
aravind-oauth-decision-subject-00, 19 July 2026,
<https://datatracker.ietf.org/doc/html/draft-aravind-
oauth-decision-subject-00>.
[I-D.aravind-oauth-operator-of-record]
Aravind, A. A., "Operator-of-Record: an Origination Marker
for Agent-Operated Presentations and Decisions", Work in
Progress, Internet-Draft, draft-aravind-oauth-operator-of-
record-00, 19 July 2026,
<https://datatracker.ietf.org/doc/html/draft-aravind-
oauth-operator-of-record-00>.
Ranjbar & Aravind Expires 2 February 2027 [Page 19]
Internet-Draft Rooting DIDs in DNSSEC August 2026
[I-D.ranjbar-dane-anchored-identity]
Ranjbar, K., "DANE-Anchored Identity for Network Clients,
Devices, and Autonomous Agents", Work in Progress,
Internet-Draft, draft-ranjbar-dane-anchored-identity-00,
21 July 2026, <https://datatracker.ietf.org/doc/html/
draft-ranjbar-dane-anchored-identity-00>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/rfc/rfc5011>.
[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>.
[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>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/rfc/rfc7480>.
[RFC8056] Gould, J., "Extensible Provisioning Protocol (EPP) and
Registration Data Access Protocol (RDAP) Status Mapping",
RFC 8056, DOI 10.17487/RFC8056, January 2017,
<https://www.rfc-editor.org/rfc/rfc8056>.
[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>.
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
DOI 10.17487/RFC9076, July 2021,
<https://www.rfc-editor.org/rfc/rfc9076>.
Ranjbar & Aravind Expires 2 February 2027 [Page 20]
Internet-Draft Rooting DIDs in DNSSEC August 2026
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/rfc/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/rfc/rfc9083>.
[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>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/rfc/rfc9499>.
Acknowledgments
This profile builds on the DANE and DNSSEC deployment experience of
the operator community, on the "High Assurance DIDs with DNS" work of
Jesse Carter, Jacques Latour, Mathieu Glaude, and Tim Bouma, and on
the did:web, did:dns, and did:webvh method specifications. The
authors thank the participants of the W3C Credentials Community Group
who encouraged a single shared DANE-EE profile.
Authors' Addresses
Kaveh Ranjbar
Whisper Security (viaGraph B.V.)
Netherlands
Email: kaveh@whisper.security
Anivar A. Aravind
Independent Researcher
India
Email: ping@anivar.net
Ranjbar & Aravind Expires 2 February 2027 [Page 21]