none
IdnMapping Class the IDNA 2008 standard is not working RRS feed

  • Question

  • Hello Everyone,

    MSDN states for IdnMapping Class [1] that "In the .NET Framework 4.5, the IdnMapping class supports different versions of the IDNA standard, depending on the operating system in use: When run on Windows 8, it supports the 2008 version of the IDNA standard"

    I am developing a project with .NET Framework 4.5 (via Visual Studio 2012) in a Windows 8.1 Pro OS
    and the IdnMapping Class still use the 2003 version of the IDNA standard.

    Code Example:

    System.Globalization.IdnMapping myIDN = new System.Globalization.IdnMapping();
    myIDN.GetAscii("τεστσ.eu");//Result is "xn--qxa2aabc.eu" which is the same fow both standards (2003 & 2008)
    myIDN.GetAscii("τεστς.eu");//Result should be "xn--qxa0accc.eu" for IDNA 2008 [2][3] but it returns "xn--qxa2aabc.eu"

    Can you please suggest any solutions?

    [1] https://msdn.microsoft.com/en-us/library/system.globalization.idnmapping(v=vs.110).aspx
    [2] http://mct.verisign-grs.com/convertServlet?input=%CF%84%CE%B5%CF%83%CF%84%CF%82.eu

    [3] http://unicode.org/reports/tr46/#Deviations

    Thank you for your time,


    • Edited by iKyr Monday, May 4, 2015 12:38 PM
    Monday, May 4, 2015 8:56 AM

Answers

  • Hi, what you're encountering is described by Unicode TR#46 Compatibility Processing http://www.unicode.org/reports/tr46/#Compatibility_Processing

    Basically IDNA2008 caused a few characters to map differently than IDNA2003, which would allow people that had "working" domain names in IDNA2003 to be redirected to different servers in IDNA2008.  For compatibility, most of the clients follow the UTR46 Compatibility processing.  It is recommended that registrars bundle the registrations to prevent confusion. 

    You can imagine that if a bank was using the IDNA2003 name and some customer updated their browser and a malicious attacker had registered the IDNA2008 variation, then that customer would encounter a security problem.  UTR46 addresses that security problem by retaining the old behavior for the conflicting mappings.

    This is the same behavior that you'll see in Windows, Internet Explorer, and Edge.


    Shawn

    Friday, May 15, 2015 9:54 PM

All replies

  • Hello iKyr,

    With your provided code, I tested and reproduced this issue as you mentions, these returned values of the GetAscii method are same. Not sure if this is a known issue and is not reported yet, I posted a feedback to the team:

    https://connect.microsoft.com/VisualStudio/feedback/details/1304173

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, May 5, 2015 6:03 AM
    Moderator
  • Hi, what you're encountering is described by Unicode TR#46 Compatibility Processing http://www.unicode.org/reports/tr46/#Compatibility_Processing

    Basically IDNA2008 caused a few characters to map differently than IDNA2003, which would allow people that had "working" domain names in IDNA2003 to be redirected to different servers in IDNA2008.  For compatibility, most of the clients follow the UTR46 Compatibility processing.  It is recommended that registrars bundle the registrations to prevent confusion. 

    You can imagine that if a bank was using the IDNA2003 name and some customer updated their browser and a malicious attacker had registered the IDNA2008 variation, then that customer would encounter a security problem.  UTR46 addresses that security problem by retaining the old behavior for the conflicting mappings.

    This is the same behavior that you'll see in Windows, Internet Explorer, and Edge.


    Shawn

    Friday, May 15, 2015 9:54 PM