Network Working Group K. Ranjbar Internet-Draft Whisper Security (viaGraph B.V.) Intended status: Informational 21 July 2026 Expires: 22 January 2027 DANE-Anchored Identity for Network Clients, Devices, and Autonomous Agents draft-ranjbar-dane-anchored-identity-00 Abstract 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. 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 22 January 2027. Ranjbar Expires 22 January 2027 [Page 1] Internet-Draft DANE-Anchored Identity 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. DANE-Anchored Identity . . . . . . . . . . . . . . . . . . . 5 4.1. Anchoring a Key to a Name . . . . . . . . . . . . . . . . 5 4.2. Binding the Name to a Routable Address . . . . . . . . . 6 4.3. Registration Metadata via RDAP . . . . . . . . . . . . . 6 4.4. Revocation at DNS TTL . . . . . . . . . . . . . . . . . . 7 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Relationship to Existing Work . . . . . . . . . . . . . . . . 8 7. Deployment Experience . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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. Ranjbar Expires 22 January 2027 [Page 2] Internet-Draft DANE-Anchored Identity July 2026 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 Ranjbar Expires 22 January 2027 [Page 3] Internet-Draft DANE-Anchored Identity July 2026 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. 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]. DANE-anchored identity: 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. Anchoring name: 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). Relying party: 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. 3. Problem Statement 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 Ranjbar Expires 22 January 2027 [Page 4] Internet-Draft DANE-Anchored Identity July 2026 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. 4. DANE-Anchored Identity 4.1. Anchoring a Key to a Name 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 Ranjbar Expires 22 January 2027 [Page 5] Internet-Draft DANE-Anchored Identity July 2026 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. 4.2. Binding the Name to a Routable Address 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. 4.3. Registration Metadata via RDAP 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. Ranjbar Expires 22 January 2027 [Page 6] Internet-Draft DANE-Anchored Identity July 2026 4.4. Revocation at DNS TTL 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). 5. Applicability 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. Ranjbar Expires 22 January 2027 [Page 7] Internet-Draft DANE-Anchored Identity July 2026 6. Relationship to Existing Work 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. 7. Deployment Experience 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. 8. Security Considerations 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. Ranjbar Expires 22 January 2027 [Page 8] Internet-Draft DANE-Anchored Identity July 2026 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. 9. Privacy Considerations 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. 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . Ranjbar Expires 22 January 2027 [Page 9] Internet-Draft DANE-Anchored Identity July 2026 [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, . [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, . 11.2. Informative References [AID] agentcommunity.org, "Agent Identity & Discovery (AID)", n.d., . [C2PA-WDTA] Paquin, C., "C2PA Explorations: Web Domain Trust Anchor", n.d., . [DID-DNS] Tech, D., "The did:dns Method", n.d., . [I-D.ietf-dance-architecture] Wilson, A., Huque, S., Johansson, O. E., and M. Richardson, "An Architecture for DNS-Bound Client and Sender Identities", Work in Progress, Internet-Draft, draft-ietf-dance-architecture-10, 2 December 2025, . [I-D.ietf-dance-client-auth] Huque, S. and V. Dukhovni, "TLS Client Authentication via DANE TLSA records", Work in Progress, Internet-Draft, draft-ietf-dance-client-auth-12, 6 July 2026, . Ranjbar Expires 22 January 2027 [Page 10] Internet-Draft DANE-Anchored Identity July 2026 [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.meunier-web-bot-auth-architecture] Meunier, T. and S. Major, "HTTP Message Signatures for automated traffic Architecture", Work in Progress, Internet-Draft, draft-meunier-web-bot-auth-architecture- 05, 2 March 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, . [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . Acknowledgments 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. Author's Address Ranjbar Expires 22 January 2027 [Page 11] Internet-Draft DANE-Anchored Identity July 2026 Kaveh Ranjbar Whisper Security (viaGraph B.V.) Netherlands Email: kaveh@whisper.security Ranjbar Expires 22 January 2027 [Page 12]