Subject: CORRECTION: RFC 3280bis: Isses about UTF8

From: Ryu Inada <[email-masked]>
Date: Sat, 20 Nov 2004 02:34:49 +0900

Please abondan preveious message, We've send draft version by 
mistake.

Thanks David as new 3280bis author who represents all folks.

We guess following issues should be included in 3280bis.
We heard that stringmatch I-D in pkix will be merged into 3280bis,
 from Paul Hoffman. Therefore, the following includes some issues 
for the stringprep and UTF8String.

0) The day of begin to issue UTF8 encoded certificate
RFC 2459/3280 described that "The UTF8String encoding [RFC 2279] 
is the preferred encoding, and all certificates issued after 
December 31, 2003 MUST use the UTF8String."
This statement made confuse in some countries include Japan.
We want to change this statement or delete.

1) Certificate Retrieval vs. Certificate Matching
PKIX requires retrieving the certificate, like ldapsearch command.
It is okay to the certificate retrieval such as a path building. 
But it does not meet to the certificate matching such as a path 
validation.
DN comparison rule in the path validation MUST be boolean, match 
or not. In stringmatch I-D, it defines the state of matching 
result three state such as match, not match and undefined. It 
makes different result which verifier used. 
It makes confusion of trustiness in PKI world.
So, we think to define separately the method of certificate 
retrieval and certificate matching.

2) Code point Matching vs. Byte order Matching
There are some confusion exist on when an application compares the
 different encoding type. 
It can compare them by the code point matching or the byte order 
matching.
For example, if using the code point matching, 'ABC' encoded by 
UTF8String is same as 'ABC' encoded by BMPString. But, if using 
the byte order matching, 'ABC' encoded by UTF8String is not same 
as 'ABC' encoded by BMPString. 
So, 3280bis has to make which matching rule should be used.

3) Implementation Requirements for UTF8String
3a) Requirement for UTF8String processing to the client 
applications
PKI client application must handle the UTF8String in the 
certificate. At least the application should not reject UTF8 
encoded certificate.

3b) Requirement for verifier (of course including SCVP server)
PKI path validation module must process the UTF8String in the 
certificates as PKIX says. 

3c) Issuing requirements for the CA
In our just personal opinion, to avoid the confusion of the 
application developers, CA MUST issue the *normalized* UTF8String 
certificates. CA MUST normalize the some strings using the 
UTF8String encoding before issuing the certificate. When CA cannot
 normalize it by some reasons, CA MUST use the PrintableString for
 the strings. This is an idea not to complicate the name 
comparison. 
The using the PrintableString should be allowed only temporarily. 
But I have no idea about how long requires to the switchover to 
the UTF8String.
Anyway, if subject requires any characters out the PrintableString,
 CA MUST use UTF8String encoding.

Thank you.

--
Ryu Inada <[email-masked]>
Fuji Xerox Co., Ltd.
+81 44 812 510 ext.6539

Masaki SHIMAOKA <[email-masked]>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4172)

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sun, 21 Nov 2004 18:22:29 -0800

>We want to change this statement or delete.

Deleting this is possible if the WG wishes, but doing so would be a 
major blow to getting anyone to pay attention to (much less 
interoperate with) non-ASCII names.

>retrieval and certificate matching.

This sounds like a good idea. Either adopt one path for retrieval and 
a different one for matching, or take "undefined" out of the string 
matching rules.

>So, 3280bis has to make which matching rule should be used.

Quite true, and it should clearly be "code point matching".

>  CA MUST use UTF8String encoding.

I like this up to the "PrintableString" part. That is, putting the 
emphasis on normalization before issuance is good because it will 
increase interoperability. However, falling back to PrintableString 
won't work for many languages. In fact, falling back to anything that 
has fewer characters than the full UCS set is probably a very bad 
idea. It is not clear what we should say here to CAs that cannot 
normalize.

--Paul Hoffman, Director
--VPN Consortium