Re: U-labels and draft-obispo-epp-idn-00

On Wed, Feb 15, 2012 at 05:58:50AM +0100, Patrik Fältström wrote:
> 
> In this case, what the client should send is _not_ a U-label. You know better than anyone else what an A-label and U-label is, and you give examples below on unicode strings that are passed around that are not U-labels. Remember that there is by definition a 1:1 mapping between A-labels and U-labels.
> 

The examples I gave are not U-labels, no.  But they're Unicode forms
of IDNA2003-compliant systems that happen to generate Punycode forms
that are perfectly good A-labels.  If I got a candidate U-label that
didn't match the A-label, I could detect this.  If I just get the
A-label, I can't.

> And the question is then what to do if it is the case that:
> 
> 1. That unicode string is passed to the registry
> 
> 2. The registry do not believe that unicode string can be represented by the A-label that is also sent
> 

If I ran the circus, this would be a fatal error for the
registration.  Moreover, RFC 5891, section 4.2.1, agrees with me:

   If both the U-label and A-label forms are available, the registry
   MUST ensure that the A-label form is in lowercase, perform a
   conversion to a U-label, perform the steps and tests described below
   on that U-label, and then verify that the A-label produced by the
   step in Section 4.4 matches the one provided as input.  In addition,
   the U-label that was provided as input and the one obtained by
   conversion of the A-label MUST match exactly.  If, for some reason,
   these tests fail, the registration MUST be rejected.

> > In the case where the U-label contained "ß", the chances are at the
> 
> > very least non-zero, at least today and for the near future: last I
> > checked (about 30 seconds ago) libidn2 isn't in the Debian stable
> > distribution, just for instance.  Similarly with ZWNJ and ZWJ.
> 
> So, the reason why we want to do this is to ensure there is no bug in the libraries used by various parties?

There's no _bug_ in libidn when it maps ß to ss.  That's what it's
supposed to do.  Moreover, if the input string was (say) üß, then the
result would in fact be a Punycode-form IDNA2003 string that happened
also to be an IDNA2008 A-label.  It just wouldn't be the right one,
because in IDNA2003 üß becomes üss before the Punycode
transformation.  The point of requiring the U-label is to be able to
catch this sort of corner case.

In complicated typographic systems like Arabic this is loads worse,
because not only are ZWNJ and ZWJ mapped away in IDNA2003, but many
people won't be able to see that.  But a machine could spot it and
throw an error.

Best,

A

-- 
Andrew Sullivan
[email protected]
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg