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.