I have been reading Identity Assertion v1.2 (15 December 2025) and the open domain-anchoring
thread (#57, #101, #201, and the recent #274). I would like to put a DNSSEC/DANE option on the
table, because I do not see it raised yet and it is a standardized, widely deployed way to do
the exact thing #57 is scoped around: anchor a signer's key to a web domain without a CA.
Section 8 already leaves the door open for this: "Other specifications MAY define additional
signer_payload.sig_type values and the corresponding definition of signature, subject to
restrictions described in Section 5.3, 'Labels'." What follows is a proposal for one such value.
What the group already solves (so I am not re-proposing it)
#101's <domain>/.well-known/c2pa.jwks approach genuinely delivers the "signed by example.com"
outcome, and #274's X.509 + TRQP path handles governed publishers well. The interim Mozilla
S/MIME + IPTC list in the X.509 trust model is a sensible bridge. None of that needs replacing.
The observation is narrower. A key fetched from .well-known over HTTPS is only as strong as
the WebPKI certificate on that HTTPS connection, so the binding still leans on a CA and on the
endpoint being reachable at validation time. There is a different trust root available for
"this key belongs to this domain" that validators already rely on for everything else: the
domain's own DNSSEC chain.
The mechanism: DANE-EE
DANE (RFC 6698, updated by RFC 7671) binds a public key to a DNS name via a DNSSEC-signed TLSA
record. Using the DANE-EE profile (the "DANE-EE" mnemonic is from RFC 7218) with a 3 1 1
record, that is TLSA usage 3 (DANE-EE, end-entity, no CA in the path), selector 1
(SubjectPublicKeyInfo), matching type 1 (SHA-256), a validator confirms the signer's key by:
- resolving the TLSA record at a DNSSEC-signed anchoring name,
- validating the DNSSEC chain from the root down to that name, and
- checking the signer key's SubjectPublicKeyInfo SHA-256 against the record.
No account, no private CA, no new fetch protocol. Stock tooling (dig, kdig, curl with DNSSEC
validation) is enough. This is DANE binding a key to a domain via TLSA, deliberately not SMIMEA
(RFC 8162 is Experimental and binds to an email local-part under _smimecert), which is the
wrong tool here.
Revocation is "remove or replace the TLSA record": it propagates within the DNS TTL for any
party validating against live DNS. I am not claiming offline or stapled revocation. For offline
or single-shot validation there is an optional pattern, DNSSEC chain stapling (RFC 9102), but it
is Experimental on the Independent stream, so I would flag it as an option, not a dependency.
How it maps onto the current spec
It slots into the same shape the identity-claims-aggregation validator already uses, "a list of
trust anchors ... that the validator considers trusted", except the anchor is the DNSSEC root
chain rather than a curated issuer list. That matters given the spec's own note that "as of this
writing, the Creator Assertions Working Group has not provided guidance about which identity
claims aggregators to consider trusted." A DNSSEC-anchored option gives a validator a
mechanical, no-list way to answer "is this key bound to a domain the publisher controls."
Proposed shape:
- A new sig_type. I would suggest CAWG define
cawg.dane (Section 5.3 reserves cawg.* for the
group). In the interim, an experimental deployment can prototype under a reverse-DNS label such
as security.whisper.dane, which Section 5.3 already permits for entity-specific labels.
signer_payload carries the anchoring name; signature is verified by binding the signing
key's SPKI to the DANE-EE TLSA record under the DNSSEC-validated name, with forward and reverse
(ip6.arpa) names required to be mutually consistent when the anchor is bound to an address.- RDAP (RFC 7480 / 9082 / 9083) can expose the registration side per address for anyone who wants
to cross-check ownership.
Honest tradeoff: DANE requires the publisher's zone to be DNSSEC-signed, which not every domain
is, so this is a complement to #101, not a replacement. Where DNSSEC exists, it removes the CA
and the HTTPS round-trip from the trust path.
Why I can speak to this
We run it in production. Whisper Security operates AS219419,
announcing IPv6 space under a public ASN, serving DNSSEC-signed forward and reverse zones per
endpoint (per /128), and publishing each endpoint's public key as a DANE-EE 3 1 1 TLSA record
under a DNSSEC-signed anchoring name bound to a routable address, with RDAP exposed per address.
A live example verifiable with stock tooling, no account and no private CA:
dig +dnssec TLSA _443._tcp.ae3b051ff3bf7f478.tdc38e7c55bad3306a92b830f9bb1e4f9.agents.whisper.online
We also have an Internet-Draft we are bringing to the IETF DANCE working group, "DANE-Anchored
Identity for Network Clients, Devices, and Autonomous Agents", that generalizes this pattern
beyond TLS endpoints to devices and autonomous agents.
Ask
Is a DNSSEC/DANE sig_type worth defining, or would you rather fold it into #57 as the "DNSSEC
variant" of the lightweight-PKI-anchored-to-a-domain work? Either way I am happy to write it up
as a PR against the credential-types section and to join CAWG as a DIF Contributor to do it
under the charter. Glad to demo the live setup if that is useful.
Kaveh
Whisper Security
I have been reading Identity Assertion v1.2 (15 December 2025) and the open domain-anchoring
thread (#57, #101, #201, and the recent #274). I would like to put a DNSSEC/DANE option on the
table, because I do not see it raised yet and it is a standardized, widely deployed way to do
the exact thing #57 is scoped around: anchor a signer's key to a web domain without a CA.
Section 8 already leaves the door open for this: "Other specifications MAY define additional
signer_payload.sig_typevalues and the corresponding definition ofsignature, subject torestrictions described in Section 5.3, 'Labels'." What follows is a proposal for one such value.
What the group already solves (so I am not re-proposing it)
#101's
<domain>/.well-known/c2pa.jwksapproach genuinely delivers the "signed by example.com"outcome, and #274's X.509 + TRQP path handles governed publishers well. The interim Mozilla
S/MIME + IPTC list in the X.509 trust model is a sensible bridge. None of that needs replacing.
The observation is narrower. A key fetched from
.well-knownover HTTPS is only as strong asthe WebPKI certificate on that HTTPS connection, so the binding still leans on a CA and on the
endpoint being reachable at validation time. There is a different trust root available for
"this key belongs to this domain" that validators already rely on for everything else: the
domain's own DNSSEC chain.
The mechanism: DANE-EE
DANE (RFC 6698, updated by RFC 7671) binds a public key to a DNS name via a DNSSEC-signed TLSA
record. Using the DANE-EE profile (the "DANE-EE" mnemonic is from RFC 7218) with a
3 1 1record, that is TLSA usage 3 (DANE-EE, end-entity, no CA in the path), selector 1
(SubjectPublicKeyInfo), matching type 1 (SHA-256), a validator confirms the signer's key by:
No account, no private CA, no new fetch protocol. Stock tooling (dig, kdig, curl with DNSSEC
validation) is enough. This is DANE binding a key to a domain via TLSA, deliberately not SMIMEA
(RFC 8162 is Experimental and binds to an email local-part under
_smimecert), which is thewrong tool here.
Revocation is "remove or replace the TLSA record": it propagates within the DNS TTL for any
party validating against live DNS. I am not claiming offline or stapled revocation. For offline
or single-shot validation there is an optional pattern, DNSSEC chain stapling (RFC 9102), but it
is Experimental on the Independent stream, so I would flag it as an option, not a dependency.
How it maps onto the current spec
It slots into the same shape the identity-claims-aggregation validator already uses, "a list of
trust anchors ... that the validator considers trusted", except the anchor is the DNSSEC root
chain rather than a curated issuer list. That matters given the spec's own note that "as of this
writing, the Creator Assertions Working Group has not provided guidance about which identity
claims aggregators to consider trusted." A DNSSEC-anchored option gives a validator a
mechanical, no-list way to answer "is this key bound to a domain the publisher controls."
Proposed shape:
cawg.dane(Section 5.3 reservescawg.*for thegroup). In the interim, an experimental deployment can prototype under a reverse-DNS label such
as
security.whisper.dane, which Section 5.3 already permits for entity-specific labels.signer_payloadcarries the anchoring name;signatureis verified by binding the signingkey's SPKI to the DANE-EE TLSA record under the DNSSEC-validated name, with forward and reverse
(ip6.arpa) names required to be mutually consistent when the anchor is bound to an address.
to cross-check ownership.
Honest tradeoff: DANE requires the publisher's zone to be DNSSEC-signed, which not every domain
is, so this is a complement to #101, not a replacement. Where DNSSEC exists, it removes the CA
and the HTTPS round-trip from the trust path.
Why I can speak to this
We run it in production. Whisper Security operates AS219419,
announcing IPv6 space under a public ASN, serving DNSSEC-signed forward and reverse zones per
endpoint (per /128), and publishing each endpoint's public key as a DANE-EE
3 1 1TLSA recordunder a DNSSEC-signed anchoring name bound to a routable address, with RDAP exposed per address.
A live example verifiable with stock tooling, no account and no private CA:
We also have an Internet-Draft we are bringing to the IETF DANCE working group, "DANE-Anchored
Identity for Network Clients, Devices, and Autonomous Agents", that generalizes this pattern
beyond TLS endpoints to devices and autonomous agents.
Ask
Is a DNSSEC/DANE sig_type worth defining, or would you rather fold it into #57 as the "DNSSEC
variant" of the lightweight-PKI-anchored-to-a-domain work? Either way I am happy to write it up
as a PR against the credential-types section and to join CAWG as a DIF Contributor to do it
under the charter. Glad to demo the live setup if that is useful.
Kaveh
Whisper Security