Subject: UTF8 revisited

From: Lars Johansson <[email-masked]>
Date: Tue, 02 Sep 2003 15:42:56 +0300

Sorry to bother you with this old thread...

....but since RFC 3280 (and 2459) states that 
all certificates issued after December 31
2003(!) MUST use UTF8 encoding of DN:s and 
I'm currently in the process of updating an 
old CA service, I wonder if there´s a "easy" 
way to find out which applications (operating 
systems, webservers etc) that can handle
these kinds of certs and - more importantly - 
which applications that doesn't.

Will I have to do all the testing myself
or does sombody on this list know about
this thing?

Kind regards!
_________________________________________________
Lars Johansson | Consultant
[email-masked] | www.omegapoint.se
tel 070-915 88 40 | fax 08-517 008 29
Omegapoint AB

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 02 Sep 2003 19:20:09 +0200

Lars Johansson wrote:
> [....] I wonder if there´s a "easy" 

In my opinion, maybe this requirement shouldn't have been blindly copied 
from RFC2459 to 3280 without some reflexion in the group about whether 
the recommandation was reasonnably in line with the market was about to 
accept, or voicing more that what used to be distant perspective in 
RFC2459 was going to happen soon after the release of RFC 3280.

I'm afraid the recommandation will end up being almost completely 
ignored. I even think that whatever respect for standards you have 
ignoring the instruction to systematically use only UTF-8 will probably 
be a lot more reasonnable.

Any PKI application released today really should have perfect support 
for UTF8String, but this is certainly not the case.
I'm not even talking about application that are still used a long time 
after release.

I'd distinguesh three degree of support of UTF-8 :
1 - perfect support
2 - support, but utf8string encoded field actually using characters 
outsite of ISO-8859-1 show some or many presentation bugs and problems
3 - blocking problems when using utf-8 fields

In the document about experiment of PKI interoperability in Japan that 
was publicised here some time ago, the description of the state of UTF-8 
support was AFAIR that they did some testing, but had to stop using it 
after that if they wanted to be able to get proper support in a 
reasonnable number of applications.
See here for the horror story :
http://www.ipa.go.jp/security/fy13/report/pki_interop/chalange2001.html
(almost every problem described there is an horror story in terms of 
respect of even basic PKI properties, not only utf8)

I haven't extensive information about the effective support, but from 
what I do know I'd expect the situation to be the following :
- Extremly few application in situation 1, certainly the case of the 
Microsoft tools, but not of many third party Windows based utilities
- An enormous number of application in situation 2, some of which having 
very, very annoying problems making any use of certificate in UTF-8 
containing non US-ASCII characters redhibitory.
- Some old but still used application in situation 3, for example the 
old Netscape 4.x that have very little public use left, but are still 
the standard of some corporate users.

In most case, situation 2 will be the result of a badly developed 
application using a utf8string clean API (this is the case of most 
popular API : Microsoft Crypto API, OpenSSL, NSS, etc...).
This case should be considered *the* usual situation.

Fully testing the applications will also be extremly long.
For example Mozilla might initially seem to support utf8 properly, but 
they are several presentation bugs (view details in certificate 
manager), and maybe some bugs are more severe than that.