Re: Introduction: Kaveh Ranjbar, DNS-anchored trust for did:web and did:dns

Kaveh has posted the profile as an Internet-Draft, and I do not think it
has been linked here yet:

https://datatracker.ietf.org/doc/draft-ranjbar-dane-did

It does what this thread asked for. One normative DANE-EE profile, TLSA
usage 3, selector SPKI, matching SHA-256, under a DNSSEC-signed name, that
did:web high assurance and did:dns can both point at rather than each
carrying its own slightly different version.

Brian, section 7.3 takes up did:webvh directly and lands about where you
would expect: the DANE binding can only ever be an optional anchor
alongside the witnesses, never a stand-in for the SCID chain.

Section 10.2 states what the binding does not attest, which I think is the
part worth arguing over. A key binding certifies that the name currently
controls the key. It says nothing about whether the party holding the name
now is the party that held it when an earlier record was made, and a lapsed
registration or an ordinary sale produces a new, validly DNSSEC-signed
record that is indistinguishable at the protocol level from a routine
rotation by the same holder. I wrote that section, so read it as an
interested party.


Anivar

On Tue, Jul 21, 2026 09:38 PM, Anivar Aravind <ping@anivar.net> wrote:

> Hi Kaveh,
>
> A normative DANE-EE profile that did:web high assurance and did:dns can
> both
> point at seems clearly worth doing, and doing once. I came at DNS from the
> other
> end, as a member of the Neo-Brahmi Generation Panel on the Neo-Brahmi root
> zone LGRs,
>  so mostly what a label is permitted to be rather than what a key is bound
> to.
>
> One question from that side, and it may already be in scope for you.
>
> DNSSEC and DANE bind a key to a name and let a verifier check it offline.
> What
> they do not carry is anything about the holding of the name. Registrant
> lapse
> and a drop catch, a UDRP transfer, or a registry level failure all move
> the name
> to a different party, and the new holder publishes their own TLSA record.
> Every
> signature verifies. The chain to the IANA root is intact. The anchor has
> changed
> hands and no relying party that trusted it last week is told.
>
> For a TLS certificate this matters less, because sessions are short and the
> certificate has its own lifetime and revocation story. For an identifier
> that
> other parties have already recorded and may re-verify much later, agent to
> agent
> or across an organisational boundary, the same silence is a different kind
> of
> gap: the verifier gets a correct answer to the question it asked, and no
> signal
> that it is now asking about a different party.
>
> Is continuity of holding something you see the profile addressing, even as
> a
> statement of what it deliberately does not cover? I am not suggesting DANE
> should carry registry state. But a verifier that caches a binding might
> reasonably want to know that the question has an answer somewhere, and
> today I
> do not think it does.
>
> Happy to help on the DNS side text if useful.
>
> Anivar A. Aravind
>
> --
> https://anivar.net
> Newsletter: http://layer8.anivar.net/
> LinkedIn: https://www.linkedin.com/in/anivar/
>
>
> On Fri, Jul 17, 2026 07:14 PM, Kaveh Ranjbar <kaveh@whisper.security>
> wrote:
>
>> Hi all,
>>
>> I have just joined the group and wanted to introduce myself. My
>> background is the internet's naming and numbering layer, six years on the
>> ICANN Board and fifteen at the RIPE NCC, so I come at credentials from the
>> DNS and registry side rather than the wallet side.
>>
>> What brought me here is the DNS-anchored trust question. I recently
>> started contributing to the did:dns method, on making DNSSEC normative and
>> adding an optional DANE-EE / TLSA key binding, so a verification method's
>> key can be checked against a DNSSEC-signed name and chained to the IANA
>> root.. Reading around, I keep seeing the same primitive surface on this
>> side of the fence: did:web already stands on a DNS name, today via the
>> WebPKI certificate at that name, and the "High Assurance DIDs with DNS"
>> draft from Jesse Carter and Jacques Latour at CIRA reaches past that to
>> DNSSEC and DANE/TLSA to harden it.
>>
>> That overlap is the part I find interesting. I would like to help make
>> the DNS side of it rigorous and, ideally, shared: one normative DANE-EE
>> profile (3 1 1, per RFC 7671 and 7218, chaining back to RFC 6698) that both
>> did:web high-assurance and did:dns could point at, rather than each
>> reinventing it. I have running code for this at the per-name level, so I
>> can bring implementation experience rather than just opinions.
>>
>> To put a concrete question on the table: is there appetite to converge
>> did:web high-assurance and did:dns on a common DANE-EE key-binding profile,
>> or are these better kept as method-specific choices? I am happy to bring it
>> to a Tuesday call if that is the better venue.
>>
>> For context only, I co-founded Whisper Security, but I am here as a DNS
>> person and not to pitch anything.
>>
>> Kaveh Ranjbar
>>
>