Re: [Spasm] Different EAI options for carrying IDNs

[Viktor Dukhovni <[e-mail]>]

> On May 7, 2017, at 6:42 PM, Wei Chuang <[e-mail]> wrote:
> 
> To resolve the direction of the EAI draft, I've tried to summarize the different
> options from the earlier mail threads on draft-ietf-lamps-eai-addresses-09 and
> highlight particular features that might help differentiate the approaches.  In
> particular there might have been confusion with the earlier Option 1, so this
> describes draft -09 take on it.  This then tries to summarize the two very
> different approaches of carrying IDNs solely as A-label (Option 2) and U-label
> (Option 4).  This also describes the option of providing both SAN forms
> rfc822Name and SmtpUTF8Name that was brought up in the thread as well (Option 3). 
> I've tried CC'ing the folks who proposed these different options, in case I've missed
> anything in the summary.  Comments welcome, particularly about about a preferred
> direction.

This is clearly a difficult area to pin down without being *very* precise in
one's language.  Some of the alternatives described, that are attributed to
me differ from what I actually attempted to propose.  So whatever we ultimately
agree on, it will be very important that the draft describe it clearly, in detail,
with good examples, and with strategic redundancy (i.e. repetition) that it will
be unlikely to be misconstrued.

My preference at this point is I think roughly option 1.  That is:

1.  When the localpart is ASCII, store the SAN as an rfc822Name SAN with
    U-labels in the domain part encoded as A-labels.

    1.1.  The CA must make sure that the U-labels corresponding to any A-labels
    used are valid IDNA2008 U-labels (without application of any "mappings").
    All A-labels must be lower-case ASCII.

    1.2.  When comparing against the reference identifier, decode the A-labels
    in the SAN back to U-labels (this just requires a punycode decoder,
    and does not require an IDN library).  Likewise convert any A-labels
    in the From address back to U-labels.  Then compare NR-LDH labels
    case-insensitively, but compare U-labels byte for byte.

    1.3  The comparison with rc822Name constraints is case-insensitive as
         it has always been.

2.  When the localpart is not ASCII, store the SAN as SMTPUtf8Name with
    U-labels replacing any A-labels in the domain part.

    2.1.  The CA must make sure that the U-labels are valid IDNA2008 U-labels
          (without application of any "mappings")

    2.2.  When comparing an SMTPUTF8Name SAN against the From address, decode
          any A-labels in the From address to U-labels.  The compare the result
          with the SAN, comparing NR-LDH labels case insensitively, and U-labels
          byte for byte.

    2.3   The comparison with rfc822Name constraints is done by decoding A-labels
          in the name constraint to U-labels and comparing with the labels in the
          SAN as above (case-insensitive for NR-LDH, verbatim for U-labels).

Note that I am careful to avoid all U-label -> A-label conversions.  Rather all
conversions are from A-labels to U-labels, and trusted CAs are expected to only
generate A-labels that decode to valid IDNA2008 U-labels.  This avoids the whole
question of IDNA2003 transitional form and all that.  All that one needs is a
punycode decoder.

-- 
-- 
	Viktor.