Gervase Markham wrote: > On 01/04/09 16:58, Florian Weimer wrote: >> This highlights a significant problem with IDNA implementations: IDNA >> only makes sense as some sort of opaque hashing mechanism to get a >> resource from DNS.
Yes, that's what it is. Given DNS is only defined for 7-bit ASCII there needs to be a mapping of some sort. Without IDNA everyone would make up their own mappings which would be a horrible incompatible mess. >> The protocol does not actually support going >> backwards, from IDNA-encoded name to the original Unicode string. The >> Mozilla implementation is totally broken in this regard. > > I'm sorry, I don't understand what you mean here. Are you saying that > the protocol doesn't support going from www.xn--caf-dma.com > www.café.com? Because it certainly does. Not only does IDNA support it, but the Mozilla implementation does too. If you go to http://www.xn--mller-kva.de/ the location bar will magically change to http://www.müller.de/ If you're complaining about the fact that multiple IDN strings map to the same punycode DNS representation and therefore round-trips sometimes give you back an alternate string then yes, that's true. It's baked into the spec. The Mozilla implementation is not "broken" nor does it differ from other browser's implementation in this regard. The IDNA spec is currently undergoing revision. I don't think they're going to change the principle of mapping multiple "confusables" to a single canonical value. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
