Re: IEA Bottom Line

John C Klensin wrote:

> Jeffrey,
>
> 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
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. 

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.
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.
Jeffrey Altman

smime.p7s
Description: S/MIME Cryptographic Signature