Re: [Spasm] Different EAI options for carrying IDNs

[Dmitry Belyavsky <[e-mail]>]

Dear Victor,

On Tue, May 9, 2017 at 8:32 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > 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.
>

Are you ready to link openssl with punycode decoder or implement the
necessary functions in it?

Doesn't the Option 2 fit better? In that case the punycode decoder is
linked with applications
where we need it for visualization purpose, not with the library itself.

Thank you!

-- 
SY, Dmitry Belyavsky