[cabfpub] Question about CN and SAN encoding

Tim Hollebeek tim.hollebeek at digicert.com
Wed May 23 18:48:35 UTC 2018

Yup, that matches my memory.


But yeah, there be dragons in this area.  It doesn’t really affect the ballot, which is good, but it’s good to help people understand the complexity here, because these sorts of issues tend to be highly complicated and difficult to get right, and hence a common source of software bugs.  CAs that try to display internationalized domain names within their own validation UI, for example, need to do so with caution.




From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, May 23, 2018 2:10 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; García Jimeno, Oscar <o-garcia at izenpe.eus>
Subject: Re: [cabfpub] Question about CN and SAN encoding


Sure, but that's actually why it's desirable to encode as xn-- (A-Label / Punycode) rather than as UTF-8 (U-Label).


This was one of the main arguments in favor of the ballot - which is that encoding as U-Label facilitates greater domain spoofing, as it attempts to bypass browser / software display policies on when it's acceptable to display a U-Label rather than an A-Label. For example, most browsers have adopted security policies considering mixed scripts and confusibles, such that if a given domain may be misleading (appie.com <http://appie.com>  vs apple.com <http://apple.com> , if you want a purely ASCII example), it's displayed as an A-Label.


You're correct that, in the past two years, most browsers have encountered one or more spoofing variants not currently covered under the UTS-39 mechanisms, and thus have adapted additional heuristics as to the display. These are valid domains, and CAs should not be preventing issuance - they're simply UI issues. By ensuring the Punycoded form, user agents have sufficient information and context to efficiently and securely display this information. CAs that encode in U-Label unfortunately facilitate greater confusion, and thus are discouraged (and, should that ballot be brought forward, forbidden) from doing so :)


On Wed, May 23, 2018 at 1:56 PM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

I agree.  The ballot is not affected at all (it wasn’t mentioned in the first two sentences).


I believe your first two sentences are correct with respect to current versions of major browsers, but need a small caveat w.r.t. older versions of Firefox.


Corey can correct me if I’m wrong, but I was thinking of the Firefox display bugs we stumbled on when he found some spoofing issues with respect to display of xn-- domain components in Firefox.  Older versions of Firefox (circa last year?) had some errors in their logic.


Like I said, they’re pretty minor, but worth noting.




From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ] 
Sent: Wednesday, May 23, 2018 11:15 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >; García Jimeno, Oscar <o-garcia at izenpe.eus <mailto:o-garcia at izenpe.eus> >
Subject: Re: [cabfpub] Question about CN and SAN encoding




On Wed, May 23, 2018 at 11:06 AM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

With regards to the first two sentences, Firefox had some bugs in this area pretty recently, so if you aren’t on the latest version, you might experience issues.  They were relatively minor, though.


Could you provide a citation for this? I actually carefully watch all of those changes, and am not aware of any recent bugs that would overlap with the ballot or question. It's possible that you're referring to the logic for when A-Label to U-Labels are displayed, but that, if anything, is a very clear argument in favor of Ballot 202, and against U-Labels within CNs.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180523/10ab5abf/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180523/10ab5abf/attachment-0003.p7s>

More information about the Public mailing list