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

[Viktor Dukhovni <[e-mail]>]

On Sat, Feb 11, 2017 at 01:42:02PM -0500, Russ Housley wrote:

> Wei is arguing that the two (ffc822Name and SmtpMUtf8Name) should be
> completely separate.

This introduces a means to evade name constraints placed on existing
(intermediate) CAs whose issuer (parent CA) was/is not SmtpUtf8 aware.
Software that introduces such bypass mechanisms would rate a CVE.
OpenSSL will not implement the proposal in its current form.

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.

Once again, I am not concerned about A-labels, U-labels, etc.,
rather, if a CA is constrained to example.com (an ordinary LDH
domain) email addresses via rfc822Name, and no SmtpUtf8Name
constraints are present, then the CA in question MUST NOT be able
to bypass that constraint via SmtpUtf8Name altnames with a domain
part of "example.com".

> You are arguing for some crossover, but I do not understand how A-labels
> in the rfc822Name are handled in your proposal.

So far, I've said nothing about about A-labels in rfc822Name
constraints.  Now that you ask, my view is that in the absence of
SmtpUtf8 constraints, an rfc822Name constraint that restricts a CA
to issue EE altnames with a domain part of xn--b1adqpd3ao5c.org
means that the CA should only be only issue rfc822Name altnames with
that verbatim A-label form only.  Thus, that same hypotheical CA would
not be able to issue SmtpUtf8Names with a domain part of духовный.org,
because that UTF-8 name does not match the literal rfc822Name constraint.

> If rfc822Name permits 'xn--fa-hia.de’ then it would need to be translated
> to 'faß.de’ for comparison in SmtpUtf8Name.

I did not want to conflate the rfc822Name constraint bypass issue
with the issue of A-label/U-label conversions.  My take is still
that conversions are not a good idea, and that a reference identifier
should be found verbatim in the certificate as a matching presented
identifier with no conversions.  With that a 'faß.de' SmtpUtf8Name
altname would not be allowed for a CA constrained to just
'xn--fa-hia.de'.

A CA that wants to start issuing 'faß.de' altnames can use a
suitable new intermediate certificate with appropriate additional
SmtpUtf8 constraints.

Requiring conversions from rfc822Name constraints that are A-labels
to correspoding U-label constraints would IMHO be a mistake, and
would require the introduction into OpenSSL and other X.509 stacks
of code that converts from A-labels to U-labels.  I think such
complexity is unwarranted, and I'd very much like to avoid the
need for any such conversions.

-- 
	Viktor.