[cabf_validation] IDN Encoding Ballot

[Ryan Sleevi]

On Thu, Feb 14, 2019 at 12:30 PM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> Since we didn't get to this on today's call. I'd like to ask for some
> discussion on the list about requiring IDNA2008 encoding with a sunset on
> IDNA2003. I would boil the options down to:
>
> 1. We should require consistent and unambiguous encoding of IDNs in SANs
> and CNs when represented as Unicode, and that means we should require
> conformance with IDNA2008
> 2. Some existing domains rely on IDNA2003 encoding to display as intended,
> and browsers support the UTS #46 compatibility processing specification
> [1], so we should allow both IDNA2003 and IDNA2008
> 3. CAs shouldn't be held to any encoding requirements as long as they are
> only accepting punycode from the subscriber and validating the domain name,
> then placing the punycode into the certificate
>

I'm inclined to #2, by virtue of the fact that, as you note, browsers
effectively support the UTS #46 compatibility processing (by virtue of the
URL Standard [1]).

In the case of Apple and Microsoft, this support is done within the lower
layers of their general purpose networking stacks (CFNetwork, WinHTTP) for
conversion Unicode-to-ASCII, while the conversion from ASCII-to-Unicode
(for display purposes) is generally application-specific (i.e.
Safari/WebKit implements its own display-algorithm [2], like other
browsers). I mention this, as it means that TLS-using applications on those
devices, even in the non-browser case, should be compatible with a UTS#46
approach.

[1] https://url.spec.whatwg.org/#idna
[2]
https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/URLHelpers.cpp?rev=240962#L100
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190214/2b639168/attachment.html>