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

[Wei Chuang <[e-mail]>]

On Thu, Apr 27, 2017 at 5:19 PM, Russ Housley <[e-mail]> wrote:

>
> > On Apr 27, 2017, at 6:25 PM, Nico Williams <[e-mail]>
> wrote:
> >
> > On Thu, Apr 27, 2017 at 05:42:27PM -0400, Russ Housley wrote:
> >>
> >>> On Apr 27, 2017, at 5:40 PM, Nico Williams <[e-mail]>
> wrote:
> >>>
> >>> On Thu, Apr 27, 2017 at 05:32:41PM -0400, Russ Housley wrote:
> >>>>> Option 3: Always include both, rfc822Name with A-labels and
> SmtpUTF8Name
> >>>>> with U-labels.
> >>>>
> >>>> Putting data that is supposed to be “the same” in two different
> >>>> formats in the certificate leads to failure cases where the relying
> >>>> party does not agree that they are actually the same.  I’d like to
> >>>> avoid the possibility of such consistency concerns.
> >>>
> >>> Multiple SANs aren't supposed nor required to be different
> >>> representations of the same notional name.
> >>
> >> But, that is what you are offering as option 3 whenever there is an
> >> IDN in use, carry it in both U-Label and A-Label form.
> >
> > I don't understand your concern.
> >
> > Is it not the case that I could have a cert with multiple SANs of any
> > one type?  Of course I could.  If I was sending email as
> > <[e-mail]> and presented to an MSA a certificate that has an
> > rfc822Name SAN for <[e-mail]> and also an rfc822Name SAN for
> > <[e-mail]> then why should the MSA complain that one of those
> > SANs does not match?!  Of course it should not.
> >
> > Now if I try to send email as <foo@bár.example> and present a
> > certificate with a <[e-mail]> rfc822Name SAN and a
> > <foo@bár.example> smtpUTF8Name SAN, it should be the same story.
> >
> > Option 3 has the advantage that the relying party has to do no
> > conversions to find a matching SAN provided the referrent name is
> > already canonical, whether using A-labels or U-labels (but not a mix,
> > natch).  But more than that, it means that for ASCII local-parts the CA
> > doesn't have to know that some MSA for that domain still doesn't handle
> > smtpUTF8Name, and if that happens to be the case this cert will work.
>
> 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.

-Wei