Re[2]: DN Encoding by UTF8String

[Masaki SHIMAOKA <shimaoka@xxxxxxxxxxx>]

Tim,

> meet."  So we required, at a minimum, support for a straight binary 
> comparison but we permit an implementation to do more...

> RFC 3280 is silent with respect to emailAddress.  RFC 3280 requires space 
> normalization and a case insensitive compare for PrintableString.  For 
> other types, a straight binary comparison is the minimum but more complex 
> name comparison is permitted...

Basically I agree with your simple requirement as binary comparison, but
I do not prefer to permit other implementation.
When we have two implementations, one may make false-positive even
though other makes false-negative.
If we allow to some implementations, we MUST get to keep same result of
name-comparison.

Such my concept consents with your observation below, does not it?

> General observation #1:  implementing additional name comparison should not 
> create *new* problems.  



> I don't think RFC 3280 is too much at odds with the OpenSSL implementation 
> or Peter's guidance.  However, I should note that name comparison for 
> directory strings encoded in UTF8STRING is a task we have been directed to 
> tackle by the IESG.    As the name comparison work progresses in the IETF, 
> the PKIX WG intends to have a document that describes the "right way" to 
> perform such a comparison.

I am pleased that PKIX is tackling such work.

Now I have one question.
How will son of RFC3280 address this UTF8Sting issue which is described
at clause 4.1.2.4 in RFC3280?

Thanks,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: shimaoka@xxxxxxxxxxx