Network Working Group K. Ranjbar Internet-Draft Whisper Security (viaGraph B.V.) Intended status: Standards Track 22 July 2026 Expires: 23 January 2027 Rooting Decentralized Identifiers in DNSSEC: A DANE-EE Key-Binding Profile draft-ranjbar-dane-did-00 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 SHA-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 23 January 2027. Ranjbar Expires 23 January 2027 [Page 1] Internet-Draft Rooting DIDs in DNSSEC July 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 SHA-256(1), with a Fallback . . . . . . . . 6 3.4. DNSSEC Requirement . . . . . . . . . . . . . . . . . . . 7 4. Owner Name Convention . . . . . . . . . . . . . . . . . . . . 7 5. Binding a Record to a Verification Method . . . . . . . . . . 7 6. Scope of the Assertion: Name to Key to Document, and No Further . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Applicability to DID Methods . . . . . . . . . . . . . . . . 8 7.1. did:web . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. did:dns . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. did:webvh . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Key Rotation . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10.1. Trust in the DNSSEC Chain . . . . . . . . . . . . . . . 10 10.2. Continuity of Holding . . . . . . . . . . . . . . . . . 10 10.3. No Attestation Beyond the Key Binding . . . . . . . . . 12 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 13.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Ranjbar Expires 23 January 2027 [Page 2] Internet-Draft Rooting DIDs in DNSSEC July 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 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 Expires 23 January 2027 [Page 3] Internet-Draft Rooting DIDs in DNSSEC July 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 [RFC8499] 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 is itself a domain (for example did:web and did:dns), the DID DNS name is that domain. 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 SHA-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. Ranjbar Expires 23 January 2027 [Page 4] Internet-Draft Rooting DIDs in DNSSEC July 2026 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. 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 is an open question 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 Expires 23 January 2027 [Page 5] Internet-Draft Rooting DIDs in DNSSEC July 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. 3.3. Matching Type SHA-256(1), with a Fallback A publisher MUST publish the bound key with matching type SHA-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. SHA-256(1) is also the one matching type that is mandatory to implement ([RFC7671], Section 2), so it is the most interoperable choice, and SHA-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 SHA-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. A deployment that anticipates digest-algorithm agility MAY additionally publish a record with a stronger matching type alongside the SHA-256(1) record; verifiers process the strongest matching type they support ([RFC7671], Section 9). Ranjbar Expires 23 January 2027 [Page 6] Internet-Draft Rooting DIDs in DNSSEC July 2026 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. MAY hold one TLSA record for each verification method to be bound; a relying party selects the record whose digest matches the verification method it is evaluating. A method that requires per-key addressing MAY instead publish each record under a label derived from the verification method's identifier, as _._did., where is derived from the fragment of the verification method's id. A referencing method MUST specify which of these two placements it uses so that resolution is deterministic. 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); Ranjbar Expires 23 January 2027 [Page 7] Internet-Draft Rooting DIDs in DNSSEC July 2026 3. computes the SHA-256 digest of the DER-encoded SubjectPublicKeyInfo of the verification-method key from the DID document; and 4. accepts the key as bound if and only if a securely validated 3 1 1 TLSA record under that name carries a matching digest. If no securely validated matching record is present, the key is not bound under this profile, and the relying party MUST NOT treat the DANE binding as established for that key. Referencing methods define whether an unbound 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. 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 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. 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. Ranjbar Expires 23 January 2027 [Page 8] Internet-Draft Rooting DIDs in DNSSEC July 2026 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., 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. 7.2. did:dns did:dns already serves verification-method material from underscore- scoped DNS resource records and recommends DNSSEC. A did:dns profile that references this document tightens DNSSEC from a recommendation to a requirement for trust-bearing keys (Section 3.4) and adds a 3 1 1 TLSA record binding each verification-method key. 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. 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 and watchers, 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. 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. Ranjbar Expires 23 January 2027 [Page 9] Internet-Draft Rooting DIDs in DNSSEC July 2026 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, a revocation takes effect within the record's TTL; operators SHOULD choose TTLs short enough that revocation is timely for their threat model. This is revocation of the key binding, effective at DNS TTL for relying parties that validate live DNS. 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. 10.2. Continuity of Holding This profile binds a key to a name under the name's current DNSSEC delegation. It deliberately does not attest continuity of holding: it carries no evidence that the party controlling the name today is the party that controlled it when a binding was first recorded. A legitimate key rotation by the same holder and a key change by a new holder after a registrar transfer, a dispute-driven transfer, or a lapse and re-registration are, to an offline verifier, indistinguishable, because DNSSEC certifies current delegation, not custody over time. [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 Ranjbar Expires 23 January 2027 [Page 10] Internet-Draft Rooting DIDs in DNSSEC July 2026 exactly what a transfer changes. For a short-lived, continuously re-validated credential such as a TLS certificate issued under [RFC8555], this 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. The question therefore has an answer, and this profile states where it lives rather than leaving it silent: * The authoritative record of a name changing hands is not in the DNS; it is at the registry, exposed through RDAP [RFC7480] [RFC9082] [RFC9083] 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). * 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 historical DNSSEC validation chain (the TLSA record together with its RRSIG, DNSKEY, and DS records up to the publicly archived root trust anchor) MAY be stapled to the proof at the time it is made, in the manner of the serialized DNSSEC chain of [RFC9102] (an Experimental mechanism defined for TLS, whose chain serialization is the reusable part here), so that a later verifier can confirm which key the name published at that time. This staple attests historical validity; it is distinct from the live-DNS revocation of Section 9. * Continuity MAY additionally be made self-contained, rather than registry-observable, by recording the sequence of a name's key bindings in a witnessed, append-only transparency log of the shape defined for certificates in [RFC6962] and [RFC9162], in which independent witnesses countersign the log so that a split or forked view is detectable. This profile treats such a log as an OPTIONAL companion and makes no claim about a specific log's witness quorum; a deployment states the assurance its live witness set provides and no more. Accordingly, a relying party that relies on a binding it recorded earlier SHOULD bound the lifetime of that cached binding and re- resolve and re-validate the TLSA and DNSSEC chain before reuse, and for higher-assurance or cross-organization decisions SHOULD check for an RDAP transfer or expiration event, or a transfer or redemption status, more recent than the binding it cached, treating any such change as a signal to re-establish trust rather than to continue it. Ranjbar Expires 23 January 2027 [Page 11] Internet-Draft Rooting DIDs in DNSSEC July 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 [RFC7626]. 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 used in Section 4 was introduced by the earlier "High Assurance DIDs with DNS" work [HIGH-ASSURANCE-DIDS], whose IANA registration lapsed when that draft expired. This document requests that IANA register _did for the TLSA RR type in the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552], with this document as the reference, reconciling with any existing or pending _did entry for other RR types. 13. References 13.1. Normative References [DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Ranjbar Expires 23 January 2027 [Page 12] Internet-Draft Rooting DIDs in DNSSEC July 2026 [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, . [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, . [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . 13.2. Informative References [DID-DNS] Danube Tech, "The did:dns Method", n.d., . [DID-WEB] W3C Credentials Community Group, "did:web Method Specification", n.d., . [DID-WEBVH] Decentralized Identity Foundation, "did:webvh DID Method (did:web + Verifiable History) v1.0", n.d., . Ranjbar Expires 23 January 2027 [Page 13] Internet-Draft Rooting DIDs in DNSSEC July 2026 [HIGH-ASSURANCE-DIDS] Carter, J. and J. Latour, "High Assurance DIDs with DNS", n.d., . [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, . [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, . [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, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [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, . [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [RFC8056] Gould, J., "Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping", RFC 8056, DOI 10.17487/RFC8056, January 2017, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, January 2019, . Ranjbar Expires 23 January 2027 [Page 14] Internet-Draft Rooting DIDs in DNSSEC 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, . [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, . [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, . [RFC9102] Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M. Shore, "TLS DNSSEC Chain Extension", RFC 9102, DOI 10.17487/RFC9102, August 2021, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . 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 author thanks the participants of the W3C Credentials Community Group who encouraged a single shared DANE-EE profile, and thanks Anivar Aravind for the continuity-of-holding question that shaped Section 10.2. Author's Address Kaveh Ranjbar Whisper Security (viaGraph B.V.) Netherlands Email: kaveh@whisper.security Ranjbar Expires 23 January 2027 [Page 15]