[Servercert-wg] IDN encoding

[Jeremy Rowley]

We received a report for someone saying that certificates issued with puny-code are mis-issued if they use IDNA2008. Considering a number of people probably received the same report, I figured we should raise and discuss the implications here.

SUMMARY:
Certificates are being issued with puny-code created using two separate IDN conversion standards: IDNA2003 and IDNA2008.  Section 7 of RFC 5280 specifies that conforming applications MUST perform the conversion specified in RFC 3490. However, RFC 8399 is listed as an internationalization update to RFC 5280. RFC8399 is never referenced in RFC 5280 though.

ISSUES:

  1.  Does a CA have to check the puny-code provided by a customer for compliance? Generally, we send the validation request to the puny-code domain (not the pre-conversation name). This confirms control over the domain so is there a need to check this? If we aren’t doing the conversion, are we actually an implementer in this case?
  2.  If required to check the conversion is proper (including if we are doing the conversion with our own systems), do we need to conform to IDNA2003, IDN2008 or either one of the CAs choosing? Because 8399 is an “Update” and not something that “Obsoletes” 3490, I think the answer is either one is okay?
  3.  Do we want a ballot to standardize this?

NOTES:
The browsers seem to be working in a transition mode where they use the full 2003 char set, then they also support any new ones from 2008 where there is a deviation they revert back to the 2003.

  *   MS Internet Explorer implements IDNA 2008 transitional mode – sends to ‘ss’-version, no full IDNA 2008 is planned.
  *   Google Chrome implements IDNA 2008 transitional mode – sends to ‘ss’-version, no full IDNA 2008 is planned.
  *   Mozilla Firefox implements IDNA2003 currently, and currently sends to ‘ss’-version.
  *   Apple Safari doesn’t support full IDNA 2008, a relevant bug on WebKit is still open; Safari currently sends to ‘ss’-version.
  *   Opera is currently based on the Blink engine and it implements transitional IDNA 2008. Reportedly, Opera supported full IDNA 2008 in v12.15, but then cancelled in Opera Next (v17), when it switched to the Blink engine.

These translation to the xn—naming is called an ACE label.

https://tools.ietf.org/html/rfc3490#section-5 the definition of IDNA2003 that is referenced in RFC5280 states.

“While all ACE labels begin with the ACE prefix, not all labels
   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
   labels that begin with the ACE prefix will confuse users and SHOULD
   NOT be allowed in DNS zones.”

Thus, not everything that starts with a xn—  name automatically is an IDNA2003 translatable URL. The RFC recommends that ones that cannot be translated to IDNA2003 Should Not be added to the domain register. (so not actually banning them just suggesting confusion could happen if it is done.)

However being that these have been added to the domain registries and can be translated by the browsers means pretty well every-one is ignoring this recommendation.  When a user enters the IDNA2008 domain to the browser, it will translate it to a ASCII version and then go to that URL.

The most important bit here for us is that we are validating the ASCII version of the domain ie:
xn--hypers-nhspa-w9a9d.de<http://hypers-nhspa-w9a9d.de> which is what is in the certificate and not the translated part from IDNA2003/08.
And technically it is a valid domain. The URL’s are correct just not inline with the how the RFC from 15 years ago was hoping to be used.

An example with lets encrypt CA..
https://🕊🕊🕊.ws

translate to:
https://xn--6w8haa.ws/

The real confusion however is when we get something like:
www.ems-preuß.de<http://www.ems-preuss.de>

for 2003 you get
https://www.ems-preuss.de/

for 2008 you get
https://xn--ems-preu-xya.de/

2 different sites both with a cert and both valid depending on which translation you use.

Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190122/a39f2b40/attachment-0001.html>