IDNA flaws with regard to U+2024

In a bug report against libidn, Erik van der Poel gives an example of an internationalized domain name that is handled differently by different implementation. Another example of one such string is:

‘räksmörgÃ¥s’ U+2024 ‘com’

If your browser supports Unicode, the string is: räksmörgÃ¥s․com. Use cut’n’paste of the string into your browser and see what it tries to lookup (please let me know what you notice!).

The problem with this string is that it is on the form “[non-ASCII][DOT-Like code point]com”. Here ‘räksmörgÃ¥s’ represents the non-ASCII string, which can be any non-ASCII string. Further, the U+2024 represent one character which looks like a dot, there are others that also contain dot-like characters.

The IDNA algorithm (section 3.1) implies that applications should treat the string as one label. The U+2024 character is not one of the dot-like characters that needs to be treated as a label separator. The ASCII string which is output after applying the IDNA algorithm is:

Note that the string contains an ASCII dot ‘.’ (0x0E). If applications are not careful how they resolv the name in the DNS, they will request information in a non-existing top-level domain ‘com-l8as9u’. This is because the DNS do not use ‘.’ to separate labels, but instead uses a length-value pair for each label. Thus the wrong string to lookup would be:


Whereas the right string to lookup would be:


Using DNS master file syntax, the name to lookup is

What’s interesting here is that some implementations, such as Microsoft Internet Explorer and Firefox implements IDNA not according to the standard. Instead, they compute the following string:

Arguable, this is a better approach than what is specified by RFC 3490. MSIE/Firefox recognize that U+2024 is a “dot-like” character, by using NFKC. What is debatable is whether U+2024 will actually occur in practice, Unicode expert Kenneth Whistler says U+2024 will not be entered accidentally.

As the maintainer of GNU Libidn, I’m not yet sure about what to do about the situation. The conservative approach is to do nothing until the RFCs are updated. I have come up with a patch to add a new IDNA flag that treat U+2024 as a dot-like character early on. This would at least make it possible to produce the same (RFC non-conforming) output that MSIE/Firefox computes.


The TLS-AUTHZ document (protocol spec here) describes a mechanism to add support for authorization in the TLS protocol. The idea is part of a patent application, see the patent notification to the IETF. The protocol has a complicated history in the IETF. Right now a third last call is open to request feedback from the community. I’ve written about TLS-AUTHZ before.

RedPhoneSecurity is now trying to circumvent the IETF standardization process by trying to get the document published as an ‘experimental standard’. The document earlier failed to get consensus for publication on the standards track.

The responsible IETF Area Director, Tim Polk, argues that because there exists independent implementations, the community benefits from having the document published. The argument is silly because the only independent implementation is mine and I’m opposed to publication of the standard. Further, the document will remain accessible to anyone in the community with access to the Internet since it has been published as an Internet Draft. To clarify that we have no interest in a standard with patent claims, we have decided to remove the tls-authz implementation from GnuTLS. Together with the FSF we came up with the following statement which is part of the GnuTLS 2.0.2 release announcement:

** TLS authorization support removed.
This technique may be patented in the future, and it is not of crucial importance for the Internet community. After deliberation we have concluded that the best thing we can do in this situation is to encourage society not to adopt this technique. We have decided to lead the way with our own actions.

If you are concerned about having patented standards adopted by the IETF, now is a very good time to make your voice heard! The last call ends on October 23th. Please read about the issue, and familiarize yourself with the IETF process (RFC 2026, with updates related to patents in RFC 3989) and send your feedback to


I have created a mailing list whose purpose is to discuss everything related to free software and the IETF, in particular themes related to copyright and patent. The idea is also to CC this list on discussions in various IETF areas that is relevant to the topic, so that everyone on this list becomes aware of what is going on. For example of useful things to CC are reviews (from a free software perspective) of documents in last call, and discussions in working groups related to patent/copyright decisions.

You may subscribe to the list.

TLS-AUTHZ Patent Concerns

I’ve implemented tls-authz in GnuTLS but there has been a long discussion of the patent situation for that technology on the IETF list. A few days ago there was a new IPR Disclosure with a patent license for this technology:

I evaluated this license from a free software perspective, here is my writeup:

EnigForm – HTML/HTTP forms with OpenPGP

Talking to Buanzo, I have been testing the EnigForm plugin for Mozilla. Briefly, EnigForm gives you OpenPGP signing of HTML forms, based on GnuPG, by setting some HTTP headers with the OpenPGP data. This is quite cool, I imagine two use-cases:

  • PGP-based web-authentication. Type your username, have a hidden form field with a nonce, and have EnigForm sign the data. The server verifies the signature, and you have been logged on.
  • PGP-protected web-based forums, bug-tracking systems, polls, etc. What you write in a HTML form is signed by EnigForm, and the server knows who wrote it, and there is persistent evidence of it. Imagine Debian votes through the web instead of via e-mail!

I think this should be documented and forwarded to the IETF for standardization. It is a good example of a simple invention that uses two existing techniques in a new way.

Password-based Authentication Protocol

There was a large increase in activity on password-based SASL authentication mechanism in the Prague IETF, with three new proposals. Unfortunately, I was travelling over the I-D cutoff, so my document didn’t make it. However, I’ve now finished a -00 document for it. The goal was initially to just specify a GSS-API mechanism, but it seemed easier to specify a framework-agnostic protocol (with some influences from GSS-API and SASL) and then specify the mapping to GSS-API and SASL.

LibIDN 0.6.11

Today I released a new version of LibIDN. No major changes, although Alexander Gnauck contributed an update of his C# port.

I’m feeling somewhat saddened how far the IDNAbis proposals are going without any attempts to work with the SASLPrep community. I predict that SASLPrep2 will be a fork of StringPrep1, rather than a profile of StringPrep2.

Update! It seems is down, which seems to affect uploads to The normal distribution URLs go to a directory checked out from CVS, but I’ve manually made sure the directory contain the latest release even though CVS checkouts doesn’t work.