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