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. -Tim From: Ryan Sleevi [mailto:[email protected]] Sent: Wednesday, May 23, 2018 2:10 PM To: Tim Hollebeek <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]>; García Jimeno, Oscar <[email protected]> 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 <[email protected] <mailto:[email protected]> > 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. -Tim From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]> ] Sent: Wednesday, May 23, 2018 11:15 AM To: Tim Hollebeek <[email protected] <mailto:[email protected]> > Cc: CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> >; García Jimeno, Oscar <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] Question about CN and SAN encoding On Wed, May 23, 2018 at 11:06 AM, Tim Hollebeek <[email protected] <mailto:[email protected]> > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
