Subject: Re: [dane] Last Call: <draft-ietf-dane-openpgpkey-07.txt> (Using DANE to Associate OpenPGP public keys with email addresses) to Experimental RFC

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Feb 2016 05:07:08 -0500 (EST)

On Mon, 8 Feb 2016, The IESG wrote:

> The IESG has received a request from the DNS-based Authentication of
> Named Entities WG (dane) to consider the following document:
> - 'Using DANE to Associate OpenPGP public keys with email addresses'
>  <draft-ietf-dane-openpgpkey-07.txt> as Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2016-02-22. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

As an author, I followed the directions of the WG with respect to the
lowercasing or not of the LHS. Consensus on the issue was very confusing
and changed multiple times, and I do believe the chairs made a wrong
call at some point for calling for the removal of the LHS lowercasing.

Without restarting the discussion here, I would like the IESG to take
a close look at whether or not to recommend that the document be changed
to do lowercasing of the LHS when possible.

The implementation status section shows 3 implementations (2 written by
me, the third one being gnupg) that use a lowercase call in the
implementation.

Paul

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Feb 2016 14:33:28 -0500

--On Tuesday, February 09, 2016 05:07 -0500 Paul Wouters
<[email-masked]> wrote:

>> The IESG has received a request from the DNS-based
>> Authentication of Named Entities WG (dane) to consider the
>> following document: - 'Using DANE to Associate OpenPGP public
>> keys with email addresses'
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action. Please send
>> substantive comments to the [email-masked] mailing lists by
>> 2016-02-22. Exceptionally, comments may be sent to
>> [email-masked] instead. In either case, please retain the

Without restarting the discussion here, please note, again, that
putting "SHOULD lowercase the LHS" in this document would:

(1) Be inconsistent with RFC 5321, not because that document
recommends preserving case distinctions (it doesn't) but because
it forbids systems other than the delivery MTA from guessing
whether that server recognizes strings that use different
character case (or any of a broad number of other things) as
distinct.   The last paragraph of Section 4 of the current draft
explicitly cites that RFC 5321 restriction.

If the intent of the suggestion above is to effectively modify
5321 to require case-insensitivity in [ASCII] local parts, then
this document should be explicit about that and should
explicitly note it is updating 5321.  Personal opinion: good
luck with that, but we should at least be consistent.  Of
course, updating/changing 5321 would be inconsistent with the
current LC for experimental.

(2) Be inconsistent with RFC 6530/6531, which forbid operations
like "lowercasing" because it is unclear what that operation
means once the LHS (local part) contains characters outside the
ASCII repertoire. 

(3) Be inconsistent with both IDNA (both IDNA2003 and IDNA2008)
and PRECIS in preferring "lowercasing" to "case folding".   For
multiple reasons, I'm not a big fan of the latter, but doing
something different seems to me to require at least an
explanation and justification.

It also seems to me that, partially as a corollary to (2) and
(3) above, that, if this document is to do any character
manipulation at all other than restricting itself to ASCII,
doing bit-string matching only, or both, an Internationalization
Considerations section should be required.  

Finally, I renew my concern about using a truncated hash of the
local-part as the lowest-level label in the owner of this key.
Since there is noting in RFC 5321 (or 5322) that would prevent
an arbitrary 28-character string being used as a local-part, the
SHA-256 transformation essentially violates the prohibition on
transforming local-parts because there would be ambiguity as to
whether such a strong should be assumed to represent a UTF-8
string or to be a local-part in its own right.   Knowing how
serious that would be requires a much more complete analysis of
use cases than this document provides.

Nits and smaller concerns:

* This document should explicitly indicate that any labels in
the domain-part of an email address that contain non-ASCII
characters MUST be stored in the DNS in IDMA A-label form and
not, e.g., stored in UTF-8 encoding.  The text could be
interpreted as mandating the latter.

* The reference to DNAME is troubling without further discussion
because cross-tree aliases could easily result in an FQDN that
was intended to be treated as a key lacking the label structure
that this document specifies.

    john

    john

---

From: Warren Kumari <[email-masked]>
Date: Tue, 09 Feb 2016 20:30:58 +0000

> > beginning of the Subject line to allow automated sorting.
<DANE chair hat>

> and changed multiple times,

Good gods, yes. This was a contentious and confusing discussion, with many
people talking past each other, many religious views, and a number of
instances where the chairs procrastinated because we couldn't see a clear
consensus.

> and I do believe the chairs made a wrong

Entirely possible.
Determining consensus was tricky, and at least one of the chairs believed
that LHS lowercasing was the right thing to do - we may have swung too far
trying to avoid our biases.

> to do lowercasing of the LHS when possible.

Yes please!

> me, the third one being gnupg) that use a lowercase call in the

I believe that many of us knew that this is what implementations would do,
but there was a strong contingent pointing at documents saying that this
was not allowed / violated chapter and verse.

We (the chairs) are more than fine being told that we got this wrong...

W
</chair hat>