On Feb 28, 2017, at 6:11 AM, Wei Chuang <weihaw(_at_)google(_dot_)com> wrote:
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
"nouser@nodomain.invalid", thereby excluding all valid rfc822 addresses.
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.