Hi Alan, Stefan,
I have several things that I would like to mention about. The first
three or four pragraphs might be interesting for you and the rest are just
low priority personal remarks:
I think it's about time to include GNU libidn and thanks for doing that.
And some additional remarks on IDN/IDNA. IDNA is being re-worked/updated by
mainly in three forums: IETF IDNA-UPDATE and EAI WG and Unicode Technical
Committee. We will soon see some development further visible to everyone as
they are converge and produce standards.
Unicode consortium has various security related studies, reports, data, and
reference materials. And most notably they are:
UTS #39: Unicode Security Mechanisms
http://www.unicode.org/reports/tr39/
UTR #36: Unicode Security Considerations
http://www.unicode.org/reports/tr36/
UAX #31: Identifier and Pattern Syntax
http://www.unicode.org/reports/tr31/
In addition to the above, the following data files are attached or referenced
from the above documents:
IDN Characters
http://www.unicode.org/reports/tr39/data/idnchars.txt
Identifier Modifications
http://www.unicode.org/reports/tr39/data/xidmodifications.txt
Visually Confusable Characters
http://www.unicode.org/reports/tr39/data/confusables.txt
Whole Script Confusables
http://www.unicode.org/reports/tr39/data/confusablesWholeScript.txt
Intentional Confusable Mappings
http://www.unicode.org/reports/tr39/data/intentional.txt
I think the above are quite good documents and information that interested
people would want to read about.
And some low priority personal remarks you may not want to read:
I also would like to make a couple of statements on Alan's email and
make the record set straight:
We do have libidnkit(3EXT) interfaces and one of the reasons we chose that
at that time (June or so of 2003) was because simply that particular
implementation was the best at that time almost handsdown and it's also
under a very favorable licensing. As I mentioned in the LSARC case and
also during the review, IDN implementations are like shells and we're
willing to ship more implementations as they are available and needed.
At that time, we evaluated I think three or four different IDN API
implementations and chose libidnkit. The LSARC case directory has also
evaluation report that contains detail reasons and rationales that were
also clearly agreed by LSARC at that time.
One thing that I was very happy with the GNU libidn BTW was that when I was
pointing out there is no 64-bit support and MT-safeness issues and so on
to Simon (who's the maintainer), he was absolutely wonderful and quick to
remedy the key problems.
I also have to explicitly make remark on Alan's "too scary" which isn't
really the case. :-) We had reasons and GNU libidn wasn't simply ready for
us at that time, even though, as I mentioned at the above, the problem was
corrected rather quickly afterward.
BTW, all the emails and links that they send to me by so many bad people
in this world, I usually get plain 7-bit ASCII phising and spoofing URLs
and hrefs absolutely many more than any that use international characters
and their confusables. And so it's not just IDN or international characters
and you just have to watch out for them all the time unfortunately. With
IDN and upcoming revisions, we just get more and worse...
And, if you choose to, I think you can report such con jobs to
corresponding companies or institutions such as spoof at ebay.com,
spoof at paypal.com, abuse at bankofamerica.com, 53investigation at
security.53.com,
and so on so that hopefully responsible companies and institutions will do
something about such bad people. (I'm sure you've received fake emails with
such phishing/spoofing hrefs from cons claiming they are from PayPal, eBay,
BoA, Fifth Third Bank and so on.)
Ienup
Alan Coopersmith wrote at 03/16/07 08:53:
> Stefan Teleman wrote:
>
>> Including IDN with Solaris
>>
>> Stefan Teleman <Stefan.Teleman at Sun.COM>
>> 15 March 2007
>>
>> 1. Summary and motivation
>>
>> The inclusion of PHP5 in Solaris has identified a number of
>> missing capabilities. One of these capabilities is a generic
>> implementation of the Stringprep, Punycode and IDNA specifications
>> as defined by IETF Internationalized Domain Names (IDN) Working
>> Group. LibIDN provides such an implementation in a portable and
>> platform-independent manner. According to the IDN web page at
>> GNU.org, LibIDN is known to run on over 20 UNIX-like platforms.
>>
>> This FastTrack case proposes the integration of LibIDN in Solaris.
>> LibIDN is GNU Software [http://www.gnu.org/software/libidn/] [1]
>> and is developed outside of SMI. As such, the SFW Consolidation is
>> the natural choice for LibIDN.
>
>
> Actually Solaris does include a generic IDN implementation already - see
> LSARC/2003/311. Unfortunately, it's not the API most of the world chose
> to use.
>
> (When they came for ARC review, GNU libIDN was suggested by the ARC, but
> was too scary for the project team to adopt.)
>
> Also, note the security issues which caused IDN to be disabled by default
> in Mozilla, and be prepared to explain how these are dealt with in any
> application that uses IDN to display domain names in any context when the
> user needs to verify the domain name is a trusted site. (Short summary:
> there are multiple Unicode characters that appear very similarly to base
> ASCII characters - close enough that users may not notice that when they
> clicked on the URL in their e-mail to what looks like their bank's web
> site,
> it was really a IDN-encoded URL using said Unicode characters to appear
> like their bank's website when it's not.)
>
