Re: [openpgp] Dnsdir last call review of draft-ietf-openpgp-crypto-refresh-12

[Daniel Kahn Gillmor <[e-mail]>]

Hi David--

On Thu 2023-11-16 06:05:45 -0800, David Blacka via Datatracker wrote:
> The sole mention of DNS is in 5.2.3.24 "Notation Data", where it says:
>
>> Names in the user namespace consist of a UTF-8 string tag followed by
>> "@" followed by a DNS domain name. Note that the tag MUST NOT contain
>> an "@" character. For example, the "sample" tag used by Example
>> Corporation could be "[e-mail]". Names in a user space are
>> owned and controlled by the owners of that domain. Obviously, it's
>> bad form to create a new name in a DNS space that you don't
>> own. Since the user namespace is in the form of an email address,
>> implementers MAY wish to arrange for that address to reach a person
>> who can be consulted about the use of the named tag. Note that due to
>> UTF-8 encoding, not all valid user space name tags are valid email
>> addresses.
>
> This is clear on the surface -- if one is using a "user namespace" identifier,
> it should look like an email address.  This is likely to be sufficient in
> practice.  However, as a DNS person, one wonders what is meant by "DNS domain
> name" *precisely*.  In particular, is it supposed to be an existing DNS domain
> name?  Is it dangerous if not?  Are there limits on the length of the domain
> name part (or the username part)?  How does "UTF-8" encoding mesh with standard
> DNS domain name formats?  Do we expect the domain name part to be
> "letters-digits-hyphens"? or can it be anything, differing from standard DNS
> presentation format by UTF-8 encoding of non-ascii characters instead of
> decimal encoding?
>
> My guess is that what is meant is that the DNS domain name part of the
> identifier is an existing (at the time) domain name that SHOULD be controlled
> by the user. Saying it is existing (or did exist) brings along many
> restrictions that then need not be stated.
>
> These are very minor questions about a very minor part of this draft, however.

Thanks for these notes!

This is text that was inherited from RFC 4880, which this document
revises, but the WG wasn't really chartered to fix these sort of
ambiguities in the standard unless they didn't take , and no one
proposed a concrete improvement either.

For the future, If anyone from the DNSDIR or within the OpenPGP
community feels inclined to clarify some of these ambiguities, one good
place might be the internet draft i started which outlines similar
concerns about ambiguities and lack of clarity in User ID conventions:

  https://datatracker.ietf.org/doc/draft-dkg-openpgp-userid-conventions/

In practice, i don't think anyone has identified real-world confusion in
the namespacing of OpenPGP notation names, and in fact the practice of
User ID conventions also doesn't have much in the way of real-world
confusion.  The only issue is that the documentation doesn't currently
align with real-world practice.

I agree with David's consensus that these aren't issues that need to be
solved for the crypto-refresh draft, but i wanted to point out a
potential locus of work for anyone who does feel inclined to clean this
stuff up in the future.

      --dkg