Subject: Re: Re[2]: DN Encoding by UTF8String

From: [email-masked] (Peter Gutmann)
Date: Fri, 12 Dec 2003 22:52:46 +1300

Masaki SHIMAOKA <[email-masked]> 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.

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 12 Dec 2003 19:03:55 +0800

> certs will process UTF-8, although none will produce it (at least in a DN) for
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

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 12 Dec 2003 12:53:08 +0000

> certs will process UTF-8, although none will produce it (at least in a DN) for

I'll add that the latest releases of OpenSSL (0.9.7c) can handle UTF8 
strings in certificates too.

It can also generate certificates containing UTF8Strings by means of a 
configuration file option, but this is not set by default.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 12 Dec 2003 14:44:02 +0100 (CET)

In message <[email-masked]> on Fri, 12 Dec 2003 22:52:46 +1300, [email-masked] (Peter Gutmann) said:

pgut001> (and then there's the all-important 0.000001% of the user
pgut001> base still using Netscape 4.x, which will crash if it hits a
pgut001> UTF-8 string).

Personally, I'd say that's the perfect reason to use UTF-8.
Supporting Netscape 4 has become HARD lately (and that's a discussion
for a completely different forum).

pgut001> It's like the IPv6 upgrade, the first backbone provider to
pgut001> switch to it is going to trigger every IPv6 bug in every
pgut001> implementation every created, so no-one wants to be the
pgut001> guinea pig.

*ahem* Actually, it's happening as we speak.  KTH (The Royal Institute
of Technology in Stockholm) and SUNET (Swedish University NETwork,
which also holds much of the swedish Internet infrastructure) are
going IPv6 native (I think they're almost done).  So if there are bugs
to be triggered, now is the time :-).

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

OpenSSL handles UTF-8 fine (at least last I checked), and can produce
UTF-8 DNs as well (it's all part of the configuration file).

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 12 Dec 2003 09:27:53 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Friday, December 12, 2003 1:53 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Re[2]: DN Encoding by UTF8String
> 

My understanding is that J2SE 1.4.2 supports it. Not sure about earlier
versions.

Blake

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 12 Dec 2003 19:25:55 +0100

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