[cabfpub] Clarification on BR 7.1.4.2.2 (commonName) and IDNs

[Ryan Sleevi]

On Tue, Jan 26, 2016 at 9:04 AM, Peter Bowen <pzb at amzn.com> wrote:

> 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.”
>
> 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.
>
> 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?
>

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".
That said, it sounds like that's an easy thing to put forward as a ballot
to correct and clarify.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160126/26c0127c/attachment.html