On Sat, Feb 11, 2017 at 1:06 PM, John R. Levine <johnl@xxxxxxxx> 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
<<attachment: smime.p7s>>