Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

[John C Klensin <[e-mail]>]

--On Tuesday, January 24, 2017 02:01 +0000 John Levine
<[e-mail]> wrote:

> In article <[e-mail]>
> you write:
>>> I think this needs to be discussed a bit more in the LAMPS
>>> WG, but you have a good point here.
>> 
>> I would extend to 'starting in "XX--" where X can be any
>> ascii character" because who knows whether we need a
>> completely different prefix one day.
> 
> I hope you mean X can be any ascii letter or digit.  After
> all, Ctrl/C is an ASCII character.

Let me made the suggestion differently.   The restriction is in
2.3.1 of RFC 5890.  This document should either incorporate that
restriction by reference and say as little as possible itself or
be sure that whatever it does say is _exactly_ consistent with
the definition there.   In doing that, note that Figure 1 is a
little bit confusing about R-LDH because there is no box for, or
formal name assigned to, non-XN R-LDH labels.

That said, if X and Y are letters or digits, "XY--" is
prohibited because it is an R-LDH label that is not an A-label.
If X and/or Y are something else (an ASCII graphic that is
neither a letter nor a digits, or  even some C0 control) then
whether it is prohibited because the third and fourth characters
are hyphens or prohibited because the characters are not letters
or digits is of the most pedantic interest only because it is
prohibited nonetheless.  It is actually important to not get
wrapped around that axle because "----foo" is prohibited too and
that string consists entirely of so-called LDH characters.

>> Or you should explicitly note that ascii-only mailboxes do
>> imply the literal value and those strings MUST NOT be
>> interpreted as A-Labels.
> 
> Urrgh.  As far as I know, this is an entirely valid ASCII
> address:
> 
>   [e-mail]
> 
> That domain name happens to be the A-label for ex᭰le.com but
> so what?

Have you read the spec, or are you just responding to my notes
and/or Patrik's?    The LAMPS WG apparently decided that it
wanted to insist on U-labels when IDN labels were concerned and
that doing so would make comparison rules easier.  I wasn't part
of their discussions, but believe the issue was that they
concluded that certificates should contain one form or the
other, but not both (or either on a per-cert basis), and then
selected the U-label form.  Doing that avoids their having to
decide whether [e-mail] and fred@ex᭰le.com were
equal and, I assume, a whole set of even more complex issues
about hashes and signatures over certificates.

I can argue for the choice of A-labels rather than U-labels (or
vice versa), but the choice is a matter of taste and I'm happy
to accept the WG's analysis and decision.

What started the discussion about how to state the prohibition
on A-labels is that, unless there is a good reason not to, one
needs a rule that does not allow what RFC 5890 calls "Fake
A-labels" to be treated as valid strings even while valid
A-labels are not.  The stronger restriction, i.e., "nothing with
'--' in the third or fourth positions", is actually somewhat
easier to state and far easier to implement in practice than
splitting hairs.  Again, unless someone can think of a good
reason to allow a Fake A-label in a cert while valid A-labels
are not allowed.

best,
   john