Re: DN Encoding by UTF8String

[Jean-Marc Desperrier <jmdesp@xxxxxxx>]

Dr Stephen Henson wrote:

> Peter Gutmann wrote:
>
> > What we'd really need here is an indication from vendors of how far 
> > UTF-8
> > support goes (or doesn't go) in their products, to determine whether 
> > it's safe
> > to switch it on yet.  The most important one would be Microsoft I 
> > guess.  I'll
> > start the ball rolling by saying that any version of cryptlib that 
> > handles
> > certs will process UTF-8, although none will produce it (at least in 
> > a DN) for
> > the reason given above.
>
> I'll add that the latest releases of OpenSSL (0.9.7c) can handle UTF8 
> strings in certificates too.

I had sent a message earlier on this list resuming the situation for 
this as I see it from the major implementations around.
I also did send a message some time ago to the list raising the same 
issue as Shimaoka, that went completely unanswered.
I'm happy there's a more reaction now.

The problem is *not* for the low level crypto API to support UTF8String.
Basically all API around do that.
All the i18n related problems in the actual implementations are added 
between that layer and the UI layer.
And even the best API can not prevent the implementer to screw the i18n 
implementation.

The japanese document about PKI interoperability also has a long list of 
horror stories at this, but also many other levels.
There's is detailled information about how memcpy() to encode and 
memcmp() to compare don't work as soon as anything more complex than 
printablestring is involved. And don't work also if you take into 
account anything from the full x520 comparison rules.
But this kind of comparaison being prevalent in application, the only 
solution to avoid problem is for the CA to normalize strictly every name 
before emitting certificates.