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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2017-01-19 at 10:21 -0500, Russ Housley wrote:
> On Jan 19, 2017, at 4:22 AM, Tim Ruehsen <[e-mail]> 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.

I think Tim's point here is that that the IDNA2008 doesn't define the
actual pre-processing steps needed prior to convert a unicode string to
punycode. If for example a non-ascii all caps string is encountered one
would have to pre-process it in order to use IDNA2008. This is not
something we can leave up to the implementer. We have to either use
TR46 or define what other preprocessing has to be used.

IDNA2003 for example maps "ÖBB.at" to "öbb.at", IDNA2008 doesn't define
what mapping is to be used. You can see that omission in the rationale
for the TR46, in the Mapping section 1.3.1 of: 
http://unicode.org/reports/tr46/

regards,
Nikos