Victor, Wei Chuang, and IESG,
The more this discussion goes on, the more I become convinced
that this document should make an explicit reference to the IDNA
2008 and SMTPUTF8 documents, say that strings in certificates
MUST conform to whatever is allowed there and then, other than
making a statement about preference for U-labels over A-labels
(or vice versa), say as little as possible. The problem is that
use of forms that might have coded meanings without knowing what
those meanings are is an opportunity for mischief, something
that should be of special concern for a piece of work that is
security-specific.
I note that "prohibit everything that has a prefix consisting of
two ASCII letters followed by '--' unless the letter sequence is
specifically allowed" has been discussed at length and then
agreed on in at least three WGs specialized about the
identifiers, not just their embeddings (original IDN, IDNbis,
and PRECIS). Even if there were a growing consensus that a
different rule would be more appropriate (and, AFAICT, there
definitely is not), it would be a bad idea for LAMPS or other
certificate-related work to get ahead of that consensus and
specify something inconsistent with the identifier standards
themselves.
Phill's proposal, independent of its merits, is almost
irrelevant to the question. From the standpoint of the present
work, it is one of many proposals to do interesting things with
the DNS by using ACE-style (or trick-prefix) labels. If the
community concludes that it is a good idea and has a plausible
chance of global deployment, the DNS/IDNA and SMTP (or SMTPUTF8)
specs will need to be modified to allow the prefix. The LAMPS
"eai" spec should be written so that, if those specifications
are modified, whatever they allow should be allowed in certs,
but should, again, not be allowed to get ahead. If that means
we are now in need of an IANA registry of such prefixes (with
exactly one initial entry plus maybe one long-deprecated one),
that ought to be easy to do.
As to "put all the alternate forms in the cert", we've been
there too and it hasn't ended happily. Fully-qualified DNS
names are part of a hierarchy. Transcoding between A-labels
and U-labels is an algorithmic matter, not a hierarchy of
choices but, if there are even two choices for the form of a
label at each of several different levels of the hierarchy, one
rapidly gets to a combinatorial explosion. I trust everyone
here can do the arithmetic. If listing all of the possible
variations on an FQDN in the certificate is the solution, then
the WG -- on behalf of those who issue, certify, validate, and
check certificates -- needs to be prepared for certs with
dozens, sometimes hundreds, of names in them, not just the
examples that have been floated with perhaps two or three.
Remembering that, if, as Porky Pig, I can get a cert issued to
me with Mickey Mouse as an alternate name that is treated as a
synonym for all purposes, much of the value of certification is
lost and, IMO, we are all in big trouble. If the WG wants to
encourage alternate name behavior, I think it is imperative that:
(i) The document contain explicit instructions to
certificate issuers and CAs about what should be checked
and to client systems about what should be
believed/trusted and under what circumstances.
(ii) Certificate provisions to specify certification
levels and exactly what is being certified need to be
reexamined and probably expanded to identify trust
levels and accountability around alternate names.
(iii) The "Security Considerations" section of the I-D
should be expanded to explicitly discuss these cases and
the risks.
The document should not be approved until that work is complete
and reaches consensus.
best,
john
--On Wednesday, February 1, 2017 21:01 +0000 Viktor Dukhovni
<ietf-dane@xxxxxxxxxxxx> wrote:
> On Tue, Jan 24, 2017 at 07:31:09PM -0000, John Levine wrote:
>
>> > My impression is that there is little problem with the
>> > intended underlying spec, but the document text needs some
>> > tuning.
>>
>> Agreed. The subsequent section on comparing names would
>> likely benefit from clearer instructions, e.g.
>>
>> a) if the domain contains A-labels, turn them into U-labels
>> b) if the domain still contains R-LDH labels, stop, not a
>> valid name. c) if the domain contains NR-LDH labels, make
>> them all the same case d) do a straight byte comparison of
>> the addresses
>
> I think that restricting R-LDH labels that are not A-labels is
> too strict, see for example Phil Hallam-Baker's proposed
> encapsulation of email addresses with "the mesh" (attached).
>
> TL;DR:
> alice@xxxxxxxxxxxxxx--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE
>
> The "mm" R-LDH namespace (if/when implemented) or some other
> future namespace should probably not be excluded at this time.
>
> If the intent is to canonicalize A-labels to U-labels, then
> perhaps only "xn--" labels should be proscribed, if any.
>
> On the other hand, I see there is some support for allowing
> certificates to contain whatever form is actually used in email
> headers, and perhaps more than just one such form. If so,
> there is no need to proscribe any names at all. The client
> performs no conversions, and the certificate would need to be
> inclusive of any addresses that are in actual use.