Re: Re[2]: DN Encoding by UTF8String

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Masaki SHIMAOKA <shimaoka@xxxxxxxxxxx> writes:

>Basically I agree with you, we MUST move to UTF-8 soon. But, still now we are
>facing to some issues about UTF8string, e.g., name comparison rule, and it
>seems that hard to solve yet them. AFAIK, there will be a little PKI
>applications who are compliant with the transition to UTF-8.

It's not really name comparison rules, the de facto profile of using only
memcpy() to encode and memcmp() to compare works pretty well at the moment.
The real problem is that a number of legacy apps don't support UTF-8, and
people are reluctant to move to it because of that (and then there's the all-
important 0.000001% of the user base still using Netscape 4.x, which will
crash if it hits a UTF-8 string).  It's like the IPv6 upgrade, the first
backbone provider to switch to it is going to trigger every IPv6 bug in every
implementation every created, so no-one wants to be the guinea pig.

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.

Anyone else?

Peter.