Re: dane-openpgp 2nd LC resolution

[E Taylor <[e-mail]>]

Hi Stephen,

> The tl;dr version is: once a revision addresses the
> substantive issues raised as per below, taking into
> account reactions to this summary, and we have a chance to
> take a quick look at -08 (I'll extend the LC to the date
> of the -08 version plus one week), then if no new
> substantive issues arise, I think we have rough consensus
> to go forward with this experiment (and others to come)
> and let the IESG review the document.

Thanks for producing this summary and these suggestions, with specific
sections of text to be added, which gives a clear picture of what we're
discussing.  I was initially concerned that your additions, and the
general process of updating the drafts to reach consensus, might have
made the document become an unruly patchwork, but I took the time to
re-read it, in light of what you propose, and it actually holds together
remarkably well.

In particular, I think your judgement on the casing / i18n issue is
sound, and seeing it in the context of the whole document makes it feel
like the most technologically neutral and acceptable solution.  It puts
no undue burdens on the traditions and best practices of the DNS
community, nor on the email community.  As you say, more work in a
future Standards Track document can be done to extend the approach
specified in the draft, but "doing so is also not required to determine
the outcome of this experiment".

One thing I wanted to bring to wider attention, though, was an
observation I made in looking at RFC 4398 (which is referenced in
section 1.1 of the draft).  That RFC, Storing Certificates in the Domain
Name System (DNS), says:

>    OpenPGP signed keys (certificates) use a general character string
>    User ID.  However, it is recommended by OpenPGP that such names
>    include the RFC 2822 email address of the party, as in "Leslie
>    Example <[e-mail]>".  If such a format is used, the CERT
>    ought to be under the standard translation of the email address into
>    a domain name, which would be leslie.host.example in this case.  If
>    no RFC 2822 name can be extracted from the string name, no specific
>    domain name is recommended.

(internal references removed).  This is interesting because not only
does it not consider a non-ASCII (or even give an example of a
non-alphabetic) local-part, but it also happily lower-cases the
local-part, "under the standard translation of the email address into a
domain name".

Admittedly this RFC is from 2006, and of course it is good that the IETF
is now thinking harder about non-ASCII use cases, but I think that the
fact that this RFC was accepted onto the Standards Track, with that
approach to email addresses, reinforces your point that the experiment
of dane-openpgp can safely go ahead while leaving some questions open
until further data has been accumulated from wider deployment of this
technology.

I look forward to the closing of the extended LC, and to reading the
IESG's review of the -08 draft.

Best regards,
Edwin