Re: [Spasm] Fwd: New Version Notification for draft-ietf-lamps-eai-addresses-09.txt

[Viktor Dukhovni <[e-mail]>]

On Mon, Apr 17, 2017 at 04:35:55PM -0700, Jim Schaad wrote:

> > > An updated draft of "Internationalized Email Addresses in X.509 
> > > certificates" with the latest comments is now posted.  Comments welcome.
> > 
> > This version is I think flawed.
> > 
> >     * It fails to describe how rfc822Name name constraints are to
> >       be used to restrict SMTPUtf8Name altnames.  (By decoding any
> >       U-labels in the rfc822Name constraint and then applying to
> >       the SMTPUtf8Name with byte-for-byte comparison whole domain
> >       or ancestor domain as appropriate).
> > 
> >     * It incorrectly asserts that SMTPUtf8Name is only for addresses
> >       with a non-ASCII localpart, while in fact even ASCII localparts
> >       at UTF-8 domains can be used with SMTPUtf8Name, whenever the
> >       relevant email address employs a UTF-8 domain name.
> > 
> [JLS] Based on previous mails on the list.  It is my understanding that the
> WG position is correctly reflected in the document.  

What position is that? I don't recall any discussion of, let alone
consensus for, storing addresses with ASCII localparts and UTF-8
domains in rfc822Name SANs.

The description of how to apply rfc822Name constraints to SMTPUtf8Name
is a much-to-concise reference to section 5, but that deals with
comparison of reference identifiers and SANs, and not domain-valued
rfc822Name constraints against SANs.  Even if some of the steps
are similar I think a separate description is called for.


>     * The new text of section 6 is confusing.  There seems to be
>       a misunderstanding here, that may account for both the
>       technical errors and the confusing explanatory text.
> 
> [JLS]  I am still trying to find the energy to go through the document, but
> I agree that there does need to be some editing  before the document
> progresses.

In particular section 6 needs work.  Perhaps shorter, focused much
more on the protocol, and less on the rationale (which could be
touched on briefly at the end).

Why is the example (2nd pair of addresses) showing A-labels in the
domain part of the SMTPUtf8Name SAN element?  I thought those were
supposed to be stored as UTF-8.  Why is there an rfc822Name SAN
element with A-labels?  I thought that all domains were to be stored
as UTF-8 U-labels and use SMTPUtf8Name when that representation is
non-ASCII.

Surely the second part of the example should have a UTF-8 domain
part and have only a SMTPUtf8Name and no rfc822Name?

-- 
	Viktor.