Re: [Spasm] Spasm Digest, Vol 13, Issue 21

[Wei Chuang <[e-mail]>]

On Thu, Apr 27, 2017 at 12:10 PM, Viktor Dukhovni <[e-mail]>
wrote:

> On Thu, Apr 27, 2017 at 08:38:45AM -0400, Russ Housley wrote:
>
> > Viktor has suggested that we consider the pros and cons of two ways of
> > encoding the SubjectAltName when the left-hand side contains non-ASCII
> > characters.
>
> To be clear, the issue is how to store the email identity (not name
> constraints, but the email-valued subjectAltName) in the certificate
> when the localpart (left-hand side if you like) DOES NOT contain
> non-ASCII characters.  Or, to doubly make sure we're on the same
> page, and avoid a double-negative, when the localpart contains ONLY
> 7-bit ASCII characters.
>

Agreed.  Just to restate the others benefit, the -09 draft calls only for
using SmtpUTFName when non-ASCII local-part is present and otherwise always
using rfc822Name.


>
> Had the localpart contained non-ASCII UTF-8, as with:
>
>     пользователь@духовный.org <http://xn--b1adqpd3ao5c.org>
>
> there would be no choice but to store the presented identifier in
> the certificate as an SMTPUtf8Name subjectAltName element.
>
> > Option 1 is the way described in the current draft, where IDNs are
> carried
> > as U-Labels.
>
> Well, the "current" draft, Section 3, bottom of page 3, says the
> opposite:
>
>    Due to operational reasons described shortly and name constraint
>    compatibility reasons described in its section, SmtpUTF8Name
>    subjectAltName MUST only be used when the local part of the email
>    address contains UTF-8.  When the local-part is ASCII, rfc822Name
>    subjectAltName MUST be used instead of SmtpUTF8Name.  The use of
>    rfc822Name rather than SmtpUTF8Name is currently more likely to be
>    supported.  Also use of SmtpUTF8Name incurs higher byte
>    representation overhead due to encoding with otherName and the
>    additional OID needed.  This may be offset if domain requires non-
>    ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name
>    supports A-label.
>
> [ The comment about encoding overhead makes no clear case in either
>   direction, is irrelevant, mand should be deleted ]
>

Will do.


>
> The draft seems to suggest that email addresses with ASCII localparts
> should be converted to A-label form, but fails to then explain all
> the associated steps needed to be performed by CAs and relying
> parties.
>

In paragraph 2 of that section 6, it calls for using section 5 including
any setup specified there.  Section 5 says with SHOULD to convert to
U-label.  It does note that that RFC5280 calls for converting to A-label
which could be used instead.


>
> > Victor gave this example:
> > all ASCII:
> >
> >       ietf-dane@духовный.org
> >
> > With Option 1, U-Labels need to be converted to A-Labels when a name
> > constraints extension is present that constrains the rfc822Name.
>
> In Chicago, IIRC the consensus was to convert the A-labels in
> rfc822Name name constraints to U-label form for comparison against
> the non-converted email address.  Not conversion of the address to
> A-labels for comparison with rfc822Name constraints.  Of course
> the two implementation strategies can be functionally equivalent
> (absent "mappings" in the U->A direction).
>

Agreed the drafts calls for conversion to U-label with SHOULD.  If this
recommendation (as noted immediately above) needs to change, we'd like to
hear about it.


>
> > Option 2 is the way described in Viktor�s message, where IDNs are carried
> > as A-Labels.
>
> And the in the *current* draft, not described in sufficient detail.
>
> > Victor gave this example, even though the left-hand-side is all ASCII:
>
>         s/even though/precisely when/
>
> >       [e-mail]
> >
> > With Option 2, U-Labels need to be converted to A-Labels no conversion is
> > needed when a name constraints extension is present that constrains the
> > rfc822Name.
>
> Indeed the domains in the SAN and the rfc822Name constraint can
> just be compared in a case-insensitive manner.
>
> > However, A-Labels need to be converted to U-Labels to compare
> > the SmtpUTF8Name to the email address that appears in the FROM field of
> > a message.
>
> Right, and possibly the domain in the RFC2822.From header may need
> mappings to be normalized to a valid UTF-8 domain.  This is up to
> the application.
>
> > From my perspective, doing conversion only to enforce name constraints is
> > the more desirable of the two.  What do others think?
>
> I am slightly in favour of storing A-labels in an rfc822Name SAN
> whenever the localpart (when all ASCII) permits.  This is more
> consistent with how IDNA domains already appear in DNS-ID, and
> is more likely to interoperate in mixed-mode use-case when a
> sender has both user@<utf-8-fqdn> and user@<a-label-fqdn>
> email addresses routed to the same mailbox, and uses the a-label
> form as needed.
>
> That said, pick one or the other, but just be clear about which,
> and describe the consequences in the draft in more detail.
>

Perhaps this part of the thread needs to be pulled out into its own
discussion on the merits of one representation versus another (as opposed
to issues in the draft).

-Wei