Re: [idn] comments on IDNA-04

["Eric A. Hall" <ehall@ehsco.com>]

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
> > > The simplest fully-precise definition is:  An ACE label is a label
> > > that gets altered when ToUnicode is applied to it.
> >
> > In terms of the specific context of domain names embedded in data
> > streams, wouldn't the simplest definition be: any label that begins
> > with the ACE prefix?
> 
> Sorry, I meant the simplest definition consistent with the usage in
> the IDNA draft.  Your proposed definition is simpler, but it defines
> a different concept from the one the IDNA draft is trying to define.
> I wanted a term for non-WYSIWYG label, that is, a label that doesn't
> directly say what it means, and is therefore displayed differently in
> IDNA-aware applications versus IDN-unaware applications.  Obviously, the
> definition "label that gets altered by ToUnicode" corresponds exactly to
> this concept.

Do you mean the IDN label that results from decoding, versus the STD13
label with a prefix?

> > The problem scenario is having an app decode and display the name, but
> > where DNS does not.  This allows for a hostile party to provide a link
> > to www.zz--amazon.com which decodes for display as www.amazon.com on
> > the compliant browser, but where DNS is sending the victim party to
> > www.zz--amazon.com.
> 
> I don't think there is a problem.  The ToUnicode operation will never
> return an all-ASCII label that differs from the input.  If the input
> is zz--amazon then the result cannot be amazon, because amazon is
> all-ASCII.  ToUnicode never alters invalid ACE labels.  If zz--amazon
> is an invalid ACE label, then ToUnicode will leave it unchanged, and
> therefore the IDNA-compliant application will display it as zz--amazon.

Okay, so this would only fail if the prefix was stripped before the label
was decoded. I was/am under the impression that general purpose encoding
and decoding libraries would exist to support the use of AMC-Z for non-DNS
purposes since it seems like a good general purpose 7-bit TES, and in
those environments prefix processing would occur separately. If prefix
processing is an embedded part of the conversion process as you describe
it in ToUnicode, the problem is avoided.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/