Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

From: "John R. Levine" <[email-masked]>
Date: 11 Feb 2017 16:06:49 -0500

>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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Feb 2017 16:12:59 -0500

> On Feb 11, 2017, at 4:06 PM, John R. Levine <[email-masked]> wrote:
> 

This seems to me to be more restrictive than necessary, but I can live
with this as a rough consensus position if others prefer this option.

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Thu, 16 Feb 2017 07:30:32 -0800

> kinds of names, the CA has to constrain both.
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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Feb 2017 13:26:30 -0500

> On Feb 16, 2017, at 10:30 AM, Wei Chuang <[email-masked]> wrote:
> 
> 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.

Given that rfc822Name is a well-known legacy element, while SmtpUtf8Name
is a novel element, the prescription can be asymmetric.  Specifically,
all that's really needed (in the simpler model proposed by John) is
to disallow SmtpUtf8Name altnames when (only) rfc822Name constraints
are present.

The converse is not required, a parent CA that is SmtpUtf8Name aware
and wants to issue a child CA with SmtpUtf8Name constraints can and
should also include appropriate rfc822Name constraints that ensure
that the desired SmtpUtf8Name constraints are not bypassed via
unauthorized rfc822Name altnames.

The rfc822Name constraints can either permit only equivalent domain
names (LDH or A-label forms), or, if no rfc822Name can be compatible
with the SmtpUtf8Name constraints, permit only something like
"[email-masked]", thereby excluding all valid rfc822 addresses.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Feb 2017 20:16:40 +0000

Folks,

I've just reviewed the IETF LC for this draft. Thanks all for
the comments and discussion which I think have thrown up some
real issues.

As of now, it is not clear to me that we have finished the
work with this one, at least the issues to do with name
constraints seem to me to call for some more WG consideration.

I think Russ (as lamps WG chair) has a similar opinion
that we're not done yet.

That said, I had put this on the March 16th IESG telechat
for consideration. If we do manage to reach a clear enough
consensus on a published revision to the draft in say the
next week then that schedule should still be fine. So I'd
encourage the authors and others who've commented to try
again and see if, in that timeframe, we can get to where
we're happy that the issues raised have been handled well
enough.

But, if it looks (as it does to me today) as if this'll take
a bit longer to figure out, then I figure the right thing to
do will be to let the lamps WG figure out how to proceed.
(And that'll mean that my successor as the responsible AD
for the lamps WG will handle further actions with the doc.)

Bottom line: if this isn't settled in the next week or so,
I'll take it off the March 16th IESG telechat and let the WG
continue the discussion.

Cheers,
S.

PS: To add to the name constraints discussion, I did wonder
if anyone really wants to use those. So for example, if we
defined the new name form so that certificate chains with
any name constraints at all and one of those names anywhere
are always treated as invalid, then would that cause any
real breakage? (It certainly would cause theoretical breakage,
but if that's all then I'd be ok with that:-)

---

From: Wei Chuang <[email-masked]>
Date: Tue, 28 Feb 2017 03:11:47 -0800

On Thu, Feb 16, 2017 at 10:26 AM, Viktor Dukhovni <[email-masked]>
wrote:

> constraints.

Hi Viktor and everyone else on the thread,

Apologies about being pedantic.  If we specify the CA name constraints as
you describe above with the asymmetric requirements on SmtpUtf8Name, are
you okay with the draft's position on keeping separate name constraint
processing for rfc822Name and SmtpUtf8Name types?  In other words the above
is proposed to be the resolution for the issue raised in your email Feb
11th, second email, para 1-3 i.e. preventing evasion of name constraints.

thanks,
-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Feb 2017 11:30:36 -0500

> On Feb 28, 2017, at 6:11 AM, Wei Chuang <[email-masked]> wrote:
> 
> Apologies about being pedantic.  If we specify the CA name constraints as you describe above with the asymmetric requirements on SmtpUtf8Name, are you okay with the draft's position on keeping separate name constraint processing for rfc822Name and SmtpUtf8Name types?  In other words the above is proposed to be the resolution for the issue raised in your email Feb 11th, second email, para 1-3 i.e. preventing evasion of name constraints.  

Works for me.

-- 
	Viktor.