"Timothy J. Miller" <tmiller(_at_)mitre(_dot_)org> writes:
On Aug 13, 2007, at 2:35 PM, Russ Housley wrote:
This issue was raised by my review of
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
However, I think that the issue goes beyond this document. The
decision made here ought to set a precedent.
What's the risk of *not* forcing to ASCII via punycode? Leave aside
flaws in unicode handling routines for the moment. In the IBE
context, a sender would derive an "incorrect" public key (more
correctly, a different public key) and the recipient would be unable
to decrypt the message.
One risk is that the specification cannot use Unicode code points from a
newer Unicode version than IDNA ToASCII supports, right now that means
Unicode 3.2. Since some time, we have Unicode 5.0, which includes many
important code points for a variety of languages. Newer versions of
Unicode will be released in the future. Having to update this
specification for every IDNA/ToUnicode release seems sub-optimal to me.
I believe it is better to teach protocols how to deal with non-ASCII
data, rather than relying on IDNA idiosyncrasies in every IETF protocol.
The choice to remain with ASCII has been made for the DNS protocol,
where it makes some sense due to backwards compatibility reasons, but
that does not mean we have to make the same choice in every IETF
protocol. Some IETF protocols can easily negotiate support for UTF-8 on
both sides, and using UTF-8 rather than Punycode seems more robust and
like better engineering to me.
/Simon