Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalize

On Sat, Feb 11, 2017 at 1:06 PM, John R. Levine <johnl(_at_)iecc(_dot_)com> 
wrote:

> Once again, a CA with *ONLY* rfc822Name constraints should not be
> > able to able issue EE certificates with SmtpUtf8Name altNames that
> > conflict with its rfc822Name constraints.
> How about if a CA with only rfc822Name constraints can't issue certs
> with SmtpUTF8Names at all, and of course vice versa.  If you want both
> kinds of names, the CA has to constrain both.
>
> R's,
> John
I had asked a few folks at Google for an opinion about the name
constraints.  Let me post Ryan Sleevi's (CC'ed) opinion:

https://mailarchive.ietf.org/arch/msg/ietf/ngUOjvCHubjcyiG4uZ0w16-5-fg [the
above] basically says option 3 [the acceptable approach of the 3], but
unfortunately suffers from 'legacy' - namely, you cannot assume that all
rfc822Name clients will be updated to support SmtpUtf8Name, and short of
marking it critical (which would mean its undeployable), you can't assume
that an SmtpUtf8Name nameConstraint will constrain an rfc822Name.

...

There are a few approaches you could try:
- "Monkey Patch" RFC5280, 6.1.4 (g) (1) and (2) [and 6.1.2 (b) and (c)]
such that an rfc822Name present in the permittedSubtrees/excludedSubtrees
(or initial-permitted-subtrees / initial-excluded-subtrees, for 6.1.2) but
an Smtp8Utf8Name is not, or if an Smtp8UtfName is present but an rfc822Name
is not, then set permitted to the empty set for that name type / set
excluded to the wildcard set. However, https://tools.ietf.
org/html/draft-ietf-lamps-eai-addresses-06#section-6 leaves me completely
confused as to whether you support the empty set / wildcard set
construction.
- Require post-processing validation, namely
  - For each certificate in the validated certificate chain, clients that
recognize SmtpUtf8Name MUST NOT accept any certificate which contains an
nameConstraint that asserts a constraint for an rfc822Name in either the
permittedSubtrees or excludedSubtrees if it does not also assert a
nameConstraint for an SmtpUtf8Name in the same section. Similarly, clients
that recognize SmtpUtf8Name MUST NOT accept any certificate which contains
a nameConstraint for an SmtpUtf8Name ... if it does not also assert a
nameConstraint for an rfc822Name in the same section.

=====

We can update the draft to include the validation steps to preclude the
unexpected legacy path.

-Wei

smime.p7s
Description: S/MIME Cryptographic Signature