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

[Rob Stradling]

On 26/01/16 18:00, Ryan Sleevi wrote:
> On Tue, Jan 26, 2016 at 9:04 AM, Peter Bowen 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".

Ryan,

I don't think the current language is specific enough to mandate that 
interpretation.

Given that the precise meaning of "value" is not defined, I think it 
would be equally valid to say that the U-label and A-label are 
equivalent encodings of the *same* "value".

> That said, it sounds like that's an easy thing to put forward as a
> ballot to correct and clarify.

+1 to clarifying this.

My preference is to explicitly permit the Subject.CN to carry either an 
A-label or U-label (that is equal or equivalent to one of the 
SAN.dNSName A-labels).

> Speaking from the client behaviour side
<snip>

We've been putting the U-label in the Subject.CN since pre-BRs.  Our 
reasons for doing so were:
   - we saw at least one other CA do this.
   - it caused at least one browser (old versions of either IE or 
Firefox, I think) to show the U-label rather than the A-label.

I don't know if any current versions of any browsers are similarly affected.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online