--On Monday, 03 November, 2003 14:46 -0500 Jeffrey Altman <jaltman@xxxxxxxxxxxx> wrote:
John C Klensin wrote:
Jeffrey,John:
I think this is an important point. The question is what to do about it. One extreme view is that we should, because of those issues, say "usernames must be confined to simple, IA5, strings because that is the only way to get guaranteed interoperability with all of these things with a single string". I don't think that is going to fly in the areas in which people are really determined to internationalize usernames and email addresses. Nor do I think that those folks are going to accept an encoding that causes user names to look as expected in some contexts and a hard-to-verify form in others -- users won't see it as the same, or common, representation of their names. So, at worst, we should be sure that people understand the tradeoffs, regardless of what i18n system is adopted: localization versus global interoperability, localization versus a single identifier as username, mailbox address, and Kerberos/ SASL/ X.509 certification or credential name.
I'll try to work some words to that effect into -02 of my email document so it doesn't get lost.
Much more than that we probably can't do, any more than saying "I18n Bad" or "I18n risky" or "I18n less interoperable" is going to prevent anyone who thinks they are needed from deploying _something_ for very long.
regards, john
My primary concern with the i18n issues are those of wire representation leakage at the user interface layer. The IDNA solution has resulted in some nasty implications for the security community because it mandates the leakage of ACE representations of IDNs to the end user when the local system architecture cannot support the appropriate i18n display and input mechanisms. This decision is wonderful for short term interoperability because it allows the existing end-user application infrastructure to be used during the migration process.
Yes. I hope that, by the time the IDNA work drew to its end, everyone involved and supporting it understood that implication... even if I was not successful in getting it explicitly into the relevant documents.
The problem it causes for the security community is that the primary goal of the authentication process is to mutually authenticate two entities to one another. This usually usually means verifying a name in some fashion. This can either be done by using the name as input to some cryptographic operation (SRP,Kerberos,...) or by associating the name with an information bundle protected by a cryptographic operation (X.509). In either case, we have complicated the situation immensely by moving from a model in which each entity has one unique name to a model in which each entity may have multiple names. Future revisions to the affected protocols can deal with the change in the model, but what of the existing deployments which cannot? I would much rather see an incompatible protocol or architecture which requires a short amount of severe pain than one that compromises the architecture for the lifetime of its future deployment.
This is, I think, a fairly persuasive argument for the "no internationalization of email addresses until your infrastructure is upgraded" approach in my draft. It also argues, I think, that the option of having the domain name in a mailbox string in either UTF-8 or punycode should be eliminated, requiring UTF-8 only and that any of the localization variations that start from "@" is an ASCII character too" should be avoided, however regretfully. Of course, as I have been trying to point out, this remains all about tradeoffs -- not only between options, but about where the pain is felt. My hope is that we can analyze those carefully and make good and explicit decisions about them, avoiding any temptations to reach for the snake oil or pixie dust.
Future versions of SASL and Kerberos are going to standardize on the use of a normalized form of Unicode represented in UTF-8 as the wire format for strings. X.509 already can support Unicode. If it were possible to insist that only Unicode aware applications could use i18n names then we would see a much more rapid transition to newer protocol implementations across the board. From my perspective, applications should be free to provide their own mechanisms for displaying i18n names when the operation system or windowing system does not support them. However, the wire representations should not be leaked through. The applications should always be requires to convert to Unicode before passing the strings the various protocol libraries. This would allow us to develop the network infrastructure independent of the user interface infrastructure. It is unfortunate that this separation cannot be maintained.
Ack. See above.
john