--On Tuesday, February 09, 2016 05:07 -0500 Paul Wouters
<paul(_at_)nohats(_dot_)ca> wrote:
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 ietf(_at_)ietf(_dot_)org mailing lists by
2016-02-22. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org 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.
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