Subject: RFC 3280bis: Isses about UTF8

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

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 just a path 
building uses. 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.
We do not insist PKI client must to process all requirements in 
PKIX says, as path validating and so on.

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)