<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 9:04 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the BRs, for commonName, it says "If present, this field MUST contain a single IP address or Fully‐Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension.”<br>
<br>
RFC 5280 requires the SAN and domainComponent DN attribute to contain the punycode (e.g. xn—) form of Internationalized Domain Names.  However it is silent on commonName.<br>
<br>
Is it allowable to have the commonName contain the Unicode string for IDNs in the SAN or must it only include the punycode form from the SAN?<br></blockquote><div><br></div><div>With my "strict interpretation" hat on, I would argue it does not permit the CN to contain the IDN, because it's "equivalent but not equal".</div><div>That said, it sounds like that's an easy thing to put forward as a ballot to correct and clarify.</div><div><br></div><div>Speaking from the client behaviour side, Chrome, Firefox, and Safari (OS X and iOS) will all fail to validate a certificate that _only_ contains a CN in IDN form, because they do not translate the CN field to the Punycode equivalent.</div><div><br></div><div>This is also true with respect to the logic in nameConstraints - that is, if only a CN is present, Chrome and Firefox constrain the possible DNS/IP interpretations of the CN to the set of effective nameConstraints within the certificate for that field type, and do not translate the IDN from U-Label to A-Label. That's OK, though, because the U-Label form will not validate against the A-Label form that these libraries validate certificates against.</div><div><br></div><div>Internet Explorer (and, by extension, CryptoAPI) does normalize the CN from U-Label to A-Label, in the absence of a SAN, and thus will validate a (U-Label/A-Label) hostname against a U-Label-in-CN certificate. It is the only implementation I'm aware of that does this. From memory, at least as of Windows XP RTM, CryptoAPI did not constrain the U-Label-CN against the A-Label-nameConstraints, but this may have been fixed in a subsequent service pack or security fix.</div><div><br></div><div>Firefox and Chrome both translate the A-Label punycoded CN to U-Label form for display. I believe, but haven't confirmed, that Safari behaves similarly. I have not tested IE's behaviour in this respect.</div><div> </div></div></div></div>