"James Seng" <[EMAIL PROTECTED]> writes: >> I can't find offical mappings for, e.g., ISO-2022 (RFC 1468) online. >> >> > - IDNA already specify (or suggested) that if the apps is using legacy >> > encodings, it should transcode to Unicode first. >> >> Yes, but I cannot find where it says how to do it, or where it cites a >> reference that explains how to do it. That's why I think the security >> consideration should be more clear that the standard will enable >> trivial attacks that have security consequences if the document is >> implemented, because the details of legacy transcoding is left >> unspecified. > > No. ISO-2022 specify a mechanism for encoding reportairs using code > switching. The transcoding varies depending on the reportairs (up to 4) you > select. And it is not a 1-to-1 mapping with Unicode. > > Do you mean you want IDNA to specify transcoding algoirthm too? Then how > many do you want to support? And why only these set? What if some one > creates another encoding? > > IDNA already say we start from Unicode. How you do the trancoding from your > encoding to Unicode is up to you so long you have the right Unicode to start > with, ie, the original legacy encoding is irrelevant from IDN perspective. > > If you did not do your transcoding from legacy to Unicode, then there is a > security problem. But the beast you describe is not IDNA. IDNA specifically > say it operates from/to Unicode only.
But the Internet is not Unicode only. I don't want to get into the design of IDNA, I only want the security consideration to accurately reflect reality, whatever it may be. My interpretation of reality is that IDNA has a limitation (that it does not define mapping tables for legacy encodings) that can be exploited on hosts that do not use ASCII/Unicode for user input/output. >> If there is no standard way to translate ISO-2022-JP into Unicode, >> won't different applications implement it differently? > > There are many ways to implement an algorithm. It does not matter how you do > it, so long the end results is the same. Yes! But since it isn't specified, different applications may generate different output, which in turn could be exploited. >> Many machines use legacy encodings, how IDNA ends up being implemented >> on such systems seems to be up to the implementor right now. > > Yes and yes. And Toolkits are available for implementors to transcode, MS > APIs, ICU, Java I18N API etc. Lets leave the implementation issues to the > implementors. Fine.
