| Internet-Draft | DANE-Anchored Identity | July 2026 |
| Ranjbar | Expires 22 January 2027 | [Page] |
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.¶
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 22 January 2027.¶
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.¶
Identity for autonomous agents, connected devices, and machine workloads is
being specified in many venues at once. A recurring pattern is visible across
them: the identity of an endpoint, its signing or authentication key, is
bootstrapped over the Web PKI and discovered through an HTTPS fetch of a
.well-known resource, through a scheme-specific certificate authority, or
through a centralized registry that the relying party must call at verification
time. Examples include agent cards fetched over HTTPS, HTTP Message Signature
key directories, content-provenance trust anchors published as a JSON Web Key
Set, and per-scheme device PKIs.¶
Each of these mechanisms works, and this document does not seek to replace any of them. For a relying party that is itself a web client, already operating inside a WebPKI-secured transaction with the origin it is verifying, discovering the key over that same web endpoint is the pragmatic choice, and anchoring it elsewhere buys little: the transaction rides on the WebPKI regardless. The limitations below bite in a different setting, one these schemes increasingly have to serve: verification that happens outside any such transaction. Examples include an agent verifying another agent, a workload authenticating across an organizational boundary, a non-HTTP protocol, or a key directory that lives in a different trust domain than the resource being accessed. There, the authority's web endpoint is a distinct trust and availability dependency, not a free side effect of a connection the verifier was making anyway.¶
In that setting, the following limitations follow from where the key is anchored rather than from how it is used:¶
Domain-takeover exposure. When trust in a key rests on the ability to serve an HTTPS resource under a domain, an adversary who transiently controls that domain (through a lapsed registration, a hijacked name server, or a mis-issued certificate) controls the identity.¶
Call-home dependency and privacy. Verifying an identity by fetching a document from the subject's server reveals to the subject which relying parties are checking it, and fails when that server is unreachable.¶
No cross-organization verifiability. Keys anchored in a private or scheme-specific root cannot be validated outside the ecosystem that operates the root; cross-organization trust requires out-of-band cross-certification.¶
Weak or absent revocation. Several device-identity profiles issue long-lived credentials with no CRL or OCSP, leaving no timely off-switch.¶
DNSSEC-signed DNS [RFC4033] [RFC9364] together with DANE [RFC6698]
[RFC7671] addresses these at the anchor for the party positioned to use it: an
operator that already controls, and can sign, the zone under which its
identities live. For such an operator, DNSSEC is not an additional deployment
step bolted onto identity provisioning; it is the same act, the identity and its
signed anchoring record provisioned together. This document does not propose
that the long tail of unsigned web origins adopt DNSSEC to participate. Where an
origin is unsigned and the verifier is a web client, an HTTPS .well-known
fetch remains the reasonable path. This document describes the anchor for the
complementary case, operator-controlled, cross-organization, and non-transaction
verification, where a key published as a TLSA record under a DNSSEC-signed name
is verifiable by any party from the DNS root of trust, without contacting the
subject and without a private CA; can be removed, revoking the identity, within
a DNS TTL; and is verifiable across every organizational boundary because the
name is part of the global DNS. This is the model the DANCE working group has developed
for DNS-bound client and device identity [I-D.ietf-dance-architecture]
[I-D.ietf-dance-client-auth]. This document generalizes that model into an
identity anchor that agent-, device-, and content-identity schemes can adopt,
and describes the additional bindings (a routable address and RDAP registration
metadata) that make the anchor a complete, operable identity.¶
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].¶
The public key of an endpoint, published as a TLSA record under a DNSSEC-signed name and thereby verifiable from the DNS root of trust.¶
The DNSSEC-signed domain name under which an endpoint's TLSA record is published. In this document the anchoring name is derived from a routable address assigned to the endpoint (see Section 4.2).¶
Any party that verifies an endpoint's identity. A relying party needs only a validating DNS resolver; it needs no account, API key, or membership in a private trust ecosystem.¶
The mechanisms surveyed in Section 5 anchor an endpoint's key in one of three
places: the Web PKI plus an HTTPS .well-known document, a scheme-specific
certificate authority, or a centralized registry. None of these anchors is the
DNS, and so none inherits DNSSEC's properties. That is not by itself a
deficiency: DNSSEC deployment is uneven, and for a verifier already inside a
WebPKI transaction with a web origin, an .well-known fetch over that
transaction is lower-friction than requiring the origin to sign its zone. The
gap this document addresses is narrower and does not depend on universal DNSSEC.
It is the case where (a) the identity operator controls the anchoring zone, so
signing it is part of provisioning the identity rather than an external
prerequisite, and (b) the relying party verifies outside any WebPKI-secured
transaction with the subject, so the web origin's continued control and
availability are a real, separate dependency.¶
The goal of this document is to describe a single anchor that, for operators who
sign their own anchoring zones, (a) is verifiable by any relying party from the
DNS root of trust, (b) requires no call-home to the subject, (c) is valid across
organizational boundaries, and (d) can be revoked worldwide within a DNS TTL,
adoptable underneath the existing agent-, device-, and content-identity schemes
without disturbing their transports or object formats. It is explicitly not a
proposal to require DNSSEC of parties that do not already operate signed zones,
nor a replacement for .well-known discovery in the web-client case.¶
An endpoint holds a key pair whose private half never leaves the endpoint. The
endpoint's public key is published as a TLSA record [RFC6698] under a
DNSSEC-signed anchoring name. The RECOMMENDED TLSA usage is DANE-EE with a
SubjectPublicKeyInfo selector and a SHA-256 matching type (3 1 1), which binds
the identity to the key itself rather than to any issuing authority, consistent
with [I-D.ietf-dance-architecture]. A relying party retrieves the TLSA record,
validates the DNSSEC chain from the root, and thereby learns the endpoint's
authentic public key with no dependency on the Web PKI and no fetch from the
endpoint.¶
Because the binding is to the SubjectPublicKeyInfo, an endpoint MAY present the same key it already uses at another layer (for example the key in a TLS client certificate, an application-instance certificate, or a signed object), so that adopting a DANE anchor requires no re-keying of already-deployed endpoints.¶
This document specifies the TLSA record [RFC6698] as the anchoring record because it is deployable today with existing DNS and DANE-aware tooling, and because the DANCE architecture [I-D.ietf-dance-architecture] already defines its use for endpoint keys. The TLSA record carries an implication of TLS use. Where the anchored key serves a non-TLS purpose, for example an HTTP message signature, a purpose-specific resource record type, or a signed identity envelope carried in a TXT record so that the record type itself asserts nothing, may be a cleaner long-term binding; this is noted as an open design question, not resolved here. The anchoring model, a DNSSEC-signed name binding a key by its SubjectPublicKeyInfo, is independent of the record type chosen to carry it.¶
To make the identity reachable as well as verifiable, the anchoring name is
associated with a routable address assigned to the endpoint. The address's
reverse name (for IPv6, under ip6.arpa) is served from a DNSSEC-signed zone
and resolves to the anchoring name, and the anchoring name resolves back to the
address. The endpoint's TLSA record is published relative to this name. An
address bound in this way is not a disposable label that an intermediary can
rotate: it is a cryptographic fact that only the holder of the corresponding
private key can stand behind, because a relying party that reaches the address
can require the peer to prove possession of the DANE-anchored key. The address
is chosen as the anchor because it is the one identifier actually present,
unforgeably, on every packet the endpoint sends. When an endpoint egresses or
opens a connection, the wire carries a source address, not a name, so a relying
party can attribute and verify the peer at the moment it acts, with no
out-of-band lookup and nothing to trust first. A name has to be asserted and
then resolved; the address asserts itself. Binding the DNSSEC-signed anchoring
name to that address carries this property into a form any relying party can
verify from the DNS root of trust.¶
This document does not mandate a particular address assignment or key-to-name derivation. It requires only that the anchoring name be DNSSEC-signed, that the TLSA record bind the endpoint's public key, and that the reverse/forward names be mutually consistent.¶
Contact, holder, and status metadata for the identity are published through RDAP [RFC7480] [RFC9082] [RFC9083] anchored on the address. RDAP gives a relying party a standard, machine-readable way to answer "who is accountable for this identity" without a proprietary lookup service, and complements the DNS anchor with the registration-data layer that DANE alone does not carry.¶
An identity is revoked by removing or replacing its TLSA record. Because relying parties validate against live DNS, a revocation propagates within the record's TTL, giving a global off-switch on the order of seconds to minutes rather than the lifetime of a certificate. Operators SHOULD choose TTLs that balance revocation latency against resolver load, and SHOULD treat the anchoring zone's DNSSEC key management as security-critical (see Section 8).¶
The anchor described in Section 4 is deliberately independent of any single application. The following schemes each define a place where an endpoint's key is asserted; each can carry, or be complemented by, a DANE-anchored identity without changing its wire format:¶
Autonomous agents. Agent-interoperability protocols publish an "agent card" whose signature key is discovered over HTTPS; a DANE anchor lets a counterparty verify that the key belongs to the claimed domain from DNS, independent of transport TLS. The Agent Identity & Discovery convention [AID] already places an agent record in DNS TXT but does not require DANE; DANE closes that gap.¶
Automated HTTP clients. HTTP Message Signature key directories
[I-D.meunier-web-bot-auth-architecture] are fetched over HTTPS only; a DANE
anchor provides a DNS-rooted alternative to the .well-known directory.¶
Connected devices and industrial assets. Device identity profiles bind a
globally unique name to a certificate held by the device (for example an OPC
UA ApplicationUri, an IEEE 802.1AR IDevID, or an IEEE 2030.5 LFDI); a DANE
anchor makes that key-bound name publicly verifiable and revocable across the
vendor/integrator/operator boundary.¶
Network functions. In service-based architectures a function's instance identifier already appears in its certificate; anchoring it via DANE makes peer identity verifiable at trust boundaries independent of a private operator PKI.¶
Content provenance. Content-provenance trust anchors published as an HTTPS-fetched JSON Web Key Set [C2PA-WDTA] can instead, or additionally, be anchored in DNSSEC via DANE, removing the domain-takeover and call-home exposure the authors themselves note.¶
In every case the DANE anchor is complementary: it changes where the key is rooted, not how the application uses it.¶
This document is consistent with, and depends on, the DANCE architecture
[I-D.ietf-dance-architecture] and client-authentication work
[I-D.ietf-dance-client-auth]; it can be read as a deployment-oriented
generalization of that architecture to agent and content identity. It is
complementary to workload-identity efforts [I-D.ietf-wimse-arch], which define
identity documents and their exchange but not a DNS anchor, and to the did:dns
method [DID-DNS], which stores decentralized-identifier data in DNS but does
not mandate DNSSEC or use DANE. Where those efforts define the identity object
or its exchange, this document defines the anchor beneath them.¶
The model has been implemented and operated in production on real, registered
address space. The operator announces an IPv6 space under a public Autonomous
System, serves DNSSEC-signed forward and reverse zones for per-endpoint
addresses, publishes DANE-EE TLSA records binding each endpoint's key, and
exposes RDAP for each address. Relying parties verify identities using only
dig, kdig, and curl against public resolvers, with no account. This
demonstrates that the anchor is operable with existing DNS, DNSSEC, and
RDAP infrastructure, and that verification is possible from unmodified client
tooling. Detailed operational parameters are out of scope for this document.¶
The security of a DANE-anchored identity rests on the DNSSEC validation chain of the anchoring zone. Relying parties MUST validate DNSSEC and MUST NOT accept a TLSA record whose chain does not validate to a trusted anchor. The operator of the anchoring zone MUST protect the zone-signing and key-signing keys accordingly; compromise of those keys is equivalent to compromise of every identity anchored in the zone.¶
Because the anchor binds an endpoint's public key rather than an issued certificate, there is no issuing-CA layer to compromise, but there is also no external party attesting to the subject's real-world identity beyond the RDAP registration data; applications that require such attestation MUST obtain it by other means and treat the DANE anchor as proof of key control, not of provenance.¶
Revocation depends on DNS propagation; an operator cannot revoke faster than the TTL previously served. Operators SHOULD keep anchoring-record TTLs short enough that revocation is timely for their threat model.¶
This anchor complements, and does not replace, transport-layer and application-layer authentication (for example mutual TLS or object signatures); it changes where a key is rooted, and provides a verification and revocation path, but it does not by itself authenticate individual protocol messages.¶
A DANE-anchored identity is, by construction, public: the anchoring name, the TLSA record, and the RDAP registration are visible to anyone. This is a deliberate trade that removes the call-home privacy problem of fetch-based discovery. Relying parties learn nothing that the subject reveals to them, and the subject learns nothing about which relying parties verify it. However, publishing a stable, enumerable identity for an endpoint enables correlation of that endpoint's activity [RFC7626]. Deployments that assign one anchoring name per endpoint SHOULD consider whether such correlation is acceptable for their use case, and MAY rotate or scope anchoring names where it is not. RDAP registration data SHOULD be minimized to what accountability requires.¶
This document has no IANA actions.¶
This work builds on the DANE Authentication for Network Clients Everywhere (DANCE) working group's architecture and on decades of DNSSEC, DANE, and RDAP deployment experience in the operator community. The author thanks Ben Schwartz and Eric Rescorla, whose comments sharpened the scoping of this document as a complement to, rather than a replacement for, WebPKI-based mechanisms; Wes Hardaker for guidance on where this work belongs; and Geoff Huston for a candid reading that shaped the plain-language framing. Acknowledgment here reflects review and discussion, not endorsement.¶