IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec

JFC Morfin jefsey at jefsey.com
Sat Oct 1 01:46:03 CEST 2011


At 21:12 30/09/2011, Andrew Sullivan wrote:
>On Fri, Sep 30, 2011 at 12:58:56PM -0600, Peter Saint-Andre wrote:
> >
> > Because it seems that most or all of the browsers implement IDNA2003 but
> > have no plans to migrate to IDNA2008.
>
>Really?  Or is this rather "plan to implement IDNA2008 + UTS46"?  The
>latter is a mapping that breaks some features of IDNA2008, but doesn't
>break everything.
>
>AFAICT, ICANN's current IDN TLD plans, as well as the IDN
>Implementation Guidelines currently out for public comment, depend on
>IDNA2008.  If no browser is actually going to implement IDNA2008, then
>we have a serious mismatch between the publishing side and the
>consuming side, and perhaps policy needs to be re-examined.

This is why as a test registry (Projet.FRA) we could not depend on 
the different applications IDNA2008+variants+orthotypography 
implementations. All what we demand to browsers and applications is 
to carry their application job and to transparently transfer users 
entries to the local ML-DNS local nameserver (i.e. the IUI IDNApplication).

The lack of IAB/IESG disclaimer when publishing the IDNA2008 RFC set 
was obviously conservative, but ICANN took it as too conservative and 
has based the VIP (variants project) on IDNA2008 so everyone waits 
for the ICANN final position. IMHO this attentism can only help an 
IDNApplication oriented solution with a common progressive and stable 
transition vs an IDNinApplication unstable delayed "à la IPv6" deployment.

The need would then on:y be for the IAB to document the 
IDNApplication solution, may be as information completing the RFC 
5895 information?
jfc






More information about the Idna-update mailing list