Re: [IETF-PKIX] OCSP: Method of Identifying Certificates

[John Wray <John_Wray@xxxxxxxx>]

Tim Polk <wpolk@nist.gov> wrote:

>NOTE: I am drafting new text for the PKIX profile to limit the string
>matching burden. The proposed text will limit the pain for implementors by
>permitting binary comparison of two strings encoded as UTF8String or
>BMPString. It will also relieve implementors of the obligation to map
>character sets and match strings encoded as different types.  This limits
>the ugliness (ignoring case and compressing white space) to processing
>PrintableString. (As I understand it, implementors have already conquered
>this piece.) I will distribute that text SOON, on a new thread on this
list.

I guess I should really wait to see the proposed text, and I may have
misunderstood
your intent, but this sounds like the wrong thing to do.  PrintableString
is a
crippled code-set, in that characters that are quite common aren't
permitted in it
(e.g. underscores and accented characters).  If what you are proposing is a
set of
canonicalization rules that are to be applied to the Unicode encodings (BMP
& UTF8)
before they are placed in certificates to allow binary comparisons between
certificate names to give the same results as the X.501 rules would between
their
non-canonical equivalents, that will mean that names that stray outside the
limited printableString character set will lose the ability to be expressed
(in certificates) in the way the owner of that name prefers (e.g. with
appropriate capitalization).

If you do intend that the PKIX profile should require that names in
certificates
are represented in canonical form when encoded in Unicode-derived codesets,
I
think the same restriction should apply to printableString too (actually,
I'm
not sure why we need to keep printableString around at all, since the
encoding
of every printableString character is identical to the encoding of that
character in UTF8.  The only thing that the printableString option buys is
the
freedom to choose a different tag in the BER encoding, which seems
more of a liability than an advantage.  I can see the utility of keeping
printableString for things like C=xy, where <xy> is required to be within
the
printableString character-set, but I don't see any benefits to allowing an
attribute value to be expressed as a CHOICE { printableString, UTF8String,
... }).

I don't believe that restricting names in certificates will actually free
up
applications from having to deal with non-canonical names anyway, since the
entity
that initiates path validation is likely to be interacting with a human at
some
stage, and at that point any names should be expressed in "owner-preferred
form"
as opposed to canonical form.

I'm all for the PKIX profile specifying an algorithm to convert a string
(in _any_
permitted codeset, not just UTF8 and BMP) into a canonical form (actually,
that should
be one algorithm for each X.501 matching rule), but I don't think we should
constrain
the names in certificates to be stored in that canonical form.

John