Re: Re[2]: DN Encoding by UTF8String

["Wen-Cheng Wang" <wcwang@xxxxxxxxxx>]

Peter Gutmann" <pgut001@xxxxxxxxxxxxxxxxx> writes:
> 
> 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?
> 
In Taiwan GPKI (Government PKI), we have already adopted UTF8string in DN
since 2002. We have to use UTF8string because our GPKI CP stipulates
that the DN must contains the offical registered name of the subscriber and
the name is of course in Chinese. One exception is that we do not use
UTF8string for Common Name in SSL certificates because IE (even IE6) running
on Windows 95/98/NT does not support UTF8string.

Wen-Cheng Wang