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 "sample@xxxxxxxxxxx". 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
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
