Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt

From: Russ Housley <[email-masked]>
Date: Thu, 19 Jan 2017 10:21:14 -0500

On Jan 19, 2017, at 4:22 AM, Tim Ruehsen <[email-masked]> wrote:

> Hi,
> 
> as an implementer of IDN aware client software I am seeking for clarification.
> 
> Punycode conversion of an IDN always comes with preprocessing steps. These 
> steps influence the resulting punycode in a way that a reverse procedure 
> (punycode decoding) doesn't result in the original IDN.
> That leads to incompatibilities between IDNA2003 and IDNA2008, addressed by 
> Unicode technical report #46 (TR46)[1]. This technical report defines two 
> preprocessing procedures, namely 'transitional' and 'non-transitional'.
> 
> Currently the open source client software (e.g. curl, wget) goes in the 
> direction of using TR46's 'non-transitional', which is very close to IDNA2008 
> + a few flaws fixed.
> 
> Maybe you could address this also in your draft, to clarify implementation 
> work.
> 
> Just a (often cited) example from the german locale:
> 
> IDNA2003 translates 'faß.de' to 'fass.de'. That is not revertable by the means 
> of IDNA2003. That means using IDN2003 to compare a certificates validity would 
> match 'faß.de' and 'fass.de', both have different owners... no chance to do it 
> right.
> 
> IDNA2008 fixes this and translates 'faß.de' to 'xn--fa-hia.de', but doesn't 
> address other peculiarities.
> 
> 
> Having the above in mind, I would appreciate it if you clearly say:
> 
> 1. IDNs used in certs have to be punycode-encoded using TR46 non-transitional 
> processing (that is where we all want be to some time in the future).

As you say, that would be equivalent to telling people to use IDNA2008 plus some stuff not agreed by the IETF consensus process.  Since this document will be an IETF consensus document (once approved), I think it better to stick to IDNA2088.

> 2. for comparison, two IDNs have to be converted by TR46 non-transitional 
> processing (into punycode) and those resulting strings will be compared byte-
> by-byte.

Given the above, it should say:

   if it is an A-label, convert A through Z to lower case.
   if it is an U-label, convert it to an A-label.
   compare octet by octet.

Russ

---

From: Tim Ruehsen <[email-masked]>
Date: Thu, 19 Jan 2017 10:22:26 +0100

Hi,

With Best Regards

Tim

[1] http://www.unicode.org/reports/tr46/