]> Whisper Security (viaGraph B.V.)

NL kaveh@whisper.security

Independent Researcher

India ping@anivar.net

Security DANE DNSSEC TLSA decentralized identifier did:web did:dns verification method 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.

Introduction A recurring pattern spans the Decentralized Identifier (DID) methods that root trust in the Domain Name System. 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 assembles a DID document directly from DNS resource records and recommends, but does not require, DNSSEC. 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 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 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 , sharing that document's key-binding record while adding the DID-specific owner-name, verification-method, and scope-ceiling rules.

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 when, and only when, they appear in all capitals, as shown here. This document uses DNS terminology from and DID terminology from , 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 . 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 ).

Bound key:

The public key of a verification method in a DID document that this profile binds to the DID DNS name.

The DANE-EE Key-Binding Profile A bound key is published as a TLSA record 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 . The record MUST be published under a DNSSEC-signed name (see ), and a relying party MUST validate the DNSSEC chain to a trust anchor before relying on it (see ). 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 . DANE and the TLSA record are defined for authenticating TLS endpoints . 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 , 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 (Section 2.1); the DNSSEC validation-state rules of (Section 4.1) as restated in and ; the DANE-EE(3) semantics of (Section 5.1); and the rollover procedure of (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 (Sections 8 and 9) except as restated in , 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 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.

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" (, 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.

Selector SubjectPublicKeyInfo(1) The selector MUST be SubjectPublicKeyInfo(1). The record therefore binds the DER-encoded SubjectPublicKeyInfo of the verification-method key (, Section 2.1.2), not a full certificate. Selector SPKI(1) "is compatible with raw public keys and the resulting TLSA record need not change across certificate renewals with the same key" (, Section 5.1). 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 ; for ECDSA keys per , using the uncompressed point form; for RSA keys per . A key type without a defined deterministic SubjectPublicKeyInfo encoding cannot be bound under this profile until one is specified.

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 (, 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 (, 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. 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 (, Section 9), subject to the per-key restriction of .

DNSSEC Requirement TLSA records under this profile MUST be served from a DNSSEC-signed zone . 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 (, 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.

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 and with the prior _did usage in . 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 (). 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 (, 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 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 (Section 7) is SHOULD-strength, and Section 4 of that document invites application profiles to specify tighter guidance, which this paragraph does.

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 . A relying party evaluating a verification method: determines the DID DNS name for the DID being verified, as specified by the referencing method; retrieves the TLSA RRset under the _did owner name and validates its DNSSEC chain to a trust anchor (); computes, from the DID document, the DER-encoded SubjectPublicKeyInfo of the verification-method key () and its digest under each matching type present in the RRset; and 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. Because one RRset MAY hold records for several distinct keys (), the digest-algorithm agility procedure of (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 (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 (). 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.

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. ( 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 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 and . 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.

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.

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

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 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 (), 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 .

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.

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 (, 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 .

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 (, 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; (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 .

Security Considerations

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.

Continuity of Holding

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. (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: (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 . The second is key continuity: 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. (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.

Two Questions, Not One Evidence of continuity answers one of two distinct questions, and MUST be labeled as to which. 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 , 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.

Mechanisms None of the following are part of the DANE-EE binding itself. Each answers one of the two questions in , and a specification or deployment invoking any of them MUST state which.

Registry-Observable Continuity (RDAP) A relying party MAY query RDAP 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 (, Section 4.5) and as status values such as pending transfer, client transfer prohibited, redemption period, and pending delete (, Section 4.6; , Section 2). 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.

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 and stapled to the artifact itself, so that a later verifier can confirm which key the name published at that time. 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 , and it MUST NOT be presented as, or accepted as, evidence of present continuity.

Witnessed Continuity Log The sequence of a name's key bindings MAY be recorded in an append-only log of the shape described in and , 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. 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 () 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. (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 . did:webvh, discussed in , 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.

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 (); identify which mechanism or mechanisms in it relies on; state which question in each relied-upon mechanism answers; where the witnessed-log mechanism () 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.

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 .

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

IANA Considerations This document defines no new DNS resource record type and no new TLSA field values; it profiles existing values from and . The _did underscored node name was introduced by the earlier "High Assurance DIDs with DNS" work ; 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 , with this document as the reference, following the precedent of the _dane entry registered for TLSA by . Use of the _did subtree with other RR types by DID methods (see ) is unaffected by this registration and is left to those methods to register for their own record types.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records. This document updates the format of the IANA registry created by RFC 6698. This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. W3C This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s). This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. This document describes the mapping of the Extensible Provisioning Protocol (EPP) statuses with the statuses registered for use in the Registration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated by DNSSEC and that are needed to perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial-of-existence proof that can be validated. This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Whisper Security (viaGraph B.V.) A rapidly growing set of protocols for autonomous agents, connected devices, and machine workloads bootstraps trust in an endpoint's public key over the Web PKI together with an HTTPS .well-known fetch, a bespoke certificate authority, or a centralized registry. These approaches inherit domain-takeover exposure, depend on a reachable call-home endpoint, are not verifiable across organizational boundaries, and frequently provide no timely revocation. This document describes a complementary identity model in which an endpoint's key is anchored directly in DNSSEC-signed DNS using DANE (a TLSA record), bound to a routable address whose reverse and forward names are served from a signed zone, and described by RDAP. The model, consistent with the architecture developed in the DANE Authentication for Network Clients Everywhere (DANCE) working group, lets any relying party verify an endpoint's identity from stock DNS tooling with no account or private trust root, and lets the identity's holder revoke it worldwide at DNS TTL. It is intended as an anchor that existing agent-, device-, and content-identity schemes can adopt without abandoning their own transports or object formats. Independent Researcher This document requests registration of opr, an OPTIONAL, descriptive JWT claim that marks the operator of record, that is, whether a human or an agent operated a credential presentation or drove a decision. Its purpose is record integrity. Under agent operation a wallet key- binding proof is cryptographically indistinguishable from a human- operated one, and no presentation protocol marks the difference; opr records the distinction. A Policy Decision Point MUST ignore opr for the allow/deny decision; interpretation and any resulting authorization behavior are deployment-local and out of scope. This document defines representation only. It defines no remedy, adjudication, obligation, or authorization mandate. Independent Researcher This document defines dsub, an OPTIONAL, descriptive claim naming the *decision subject*, the party an automated agent's action is taken _upon_, as distinct from the acting agent (act) and the delegating principal (sub). Its purpose is *audit legibility*: letting a record name the party a decision concerns, which is the precondition for that record ever being made legible to them. The claim is privacy- minimizing by construction and is NOT an input to the authorization decision; a Policy Decision Point MUST ignore it. This document defines representation only. W3C Credentials Community Group Danube Tech Decentralized Identity Foundation W3C Decentralized Identifier Working Group

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.