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

[Viktor Dukhovni <[e-mail]>]

On Fri, Apr 28, 2017 at 06:57:17AM -0700, Wei Chuang wrote:

> > I have a problem with you saying that the common practice for an email
> > address that includes an IDN is to put both the A-Lable for and the U-Label
> > for in the certificate.  This leads to more checks than are needed to make
> > sure that both conform to the name constraints, and  it might lead to other
> > surprises because some relying parties use on form while other relying
> > parties use the other.  I’m just arguing for the normal practice to be the
> > use of one of the encodings, not both.
> 
> +1
> 
> Option 3, while agreed it has some nice properties, causes a lot more
> complexity and creates a lot more room for implementation and operational
> errors.  You can see that complexity in the earlier draft -08 in the
> example section where we tried to enumerate most of the cases:
> https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08
> It called for special casing name constraints for backwards compatibility
> by the SmtpUTF8Name aware issuer.  That draft also called for SmtpUTF8Name
> aware path verifiers to help "police" those name constraint.

Actually, no!  The complexity in draft 8 is entirely due to using
two types of *name constraints*.  There is no such complexity when
using both types of SANs.

Both types of SANs need to be supported anyway, so what "option 3"
does is make it possible to compare the reference identifier against
the SAN *without* conversions.  That is, the certificate is populated
with all the email identities that the sender intends to use, and the
relying party performs no conversions!  

When the reference identifier has no U-labels, and the localpart
is all ASCII, only rfc822Name SANs are checked (with domain parts
compared in a case-insensitive manner).

When the reference identifier has U-labels, or the localpart is
not all ASCII, only SMTPUtf8Name SANs checked (with U-labels in
the domain parts compared byte for byte and NR-LDH or A-labels in
a case-insensitive manner).

A sender who wants working certificate authentication should not
use addresses that don't appear verbatim (modulo case of NR-LDH or
A-labels of domains) in your certificate.  Or equivalently, a sender
should obtain a certificate with all the desired address forms.

Instead of placing the burden on all the verifiers, place it on
the party obtaining the certificate from the CA.

-- 
	Viktor.