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

[Nico Williams <[e-mail]>]

On Fri, Apr 28, 2017 at 04:59:14PM +0000, Viktor Dukhovni wrote:
> On Fri, Apr 28, 2017 at 06:57:17AM -0700, Wei Chuang wrote:
> > 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!  

However, it doesn't do this.  The problem is that there may exist
certificates that have rfc822Name and not smtpUTF8Name that relying
parties should nonetheless support.

So I think option 3 is out because it adds no value even though it
should not cause any problems.

I believe only options 2 and 3 are acceptable, but option 3 is useless,
therefore only option 2 should be considered, and that's no option.

Nico
--