Subject: Re: PrintableString not usable tigether with OCSP?

From: [email-masked] (Peter Gutmann)
Date: Mon, 11 Nov 2002 17:17:02 +1300 (NZDT)

Richard Levitte - VMS Whacker <[email-masked]> writes:

>Perhaps the subject is a little on the harsh side.  However, having just
>implemented the rules for PrintableString and emailAddress from RFC3280 [1]
>into OpenSSL, I was reminded that this in itself causes some problems when
>hashes over subject or issuer is used to find a certificate.
>
>[1] saying the PrintableString in DNs should have spaces collapsed and
>    trimmed at the beginning and end of value, and considered case
>    insensitive, and the emailAddress with the string type ia5String should
>    be considered case insensitive...

This is about as realistic as the requirement that certs be re-coded using
DER, and has the same solution: Everyone just uses the string as encoded in
the cert.  This works just fine, it's a non-problem.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 18 Nov 2002 16:05:58 +1300 (NZDT)

Steve Hanna <[email-masked]> writes:

>There are other cases where memcmp would not be sufficient. For one thing, DN
>matching is supposed to be case-insensitive and ignore excess white space (as
>described in RFC 2459, RFC 3280, and X.520). memcmp won't handle that. Also,
>there are many ways to encode a particular name in Unicode. For instance, the
><E9> in Jos<E9> can be encoded as a composite character (U+00E9) or as a base
>character and a combining character (U+0065 U+0301). X.500 names with either
>of these two encodings should match.

I don't disagree with this, in fact AFAIK I was the first person to point out
the problems with encoding/canonicalisation/etc in the X.509 Style Guide some
years ago.  However, I have yet to see any evidence that there are certs which
do this.  The reason for this is that implementors realised some years ago
that it's practically suicidal to use anything other than memcpy() to encode a
reference to a cert (that is, you use memcpy() to move the DN from the cert to
where it's needed) and by extension memcmp() to compare the reference to the
original DN, in the same way that no-one even tries to apply the decode-and-
recode-in-DER requirement.  I can say this from having helped other vendors
debug implementations which erroneously tried to follow the X.500/RFC 2459
canonicalisation/encoding rules and then found that nothing worked with the
data being produced by their code.  You give an example of combining chars,
someone once sent me a cert with the 8-bit equivalent (floating diacritics) in
it.  I have yet to find anything anywhere which displays these correctly,
however everything handles the cert OK because they just do a memcpy()/
memcmp() without trying to do anything with the content.

In summary, it does't matter what's possible in theory, real-world experience
has told us that it's memcpy()/memcmp() or nothing.

[I got one private comment saying that it would be nice if the standards
 contained at least a vague approximation to reality.  I have a (long-delayed)
 update in the works for the Style Guide which points out some of the major
 points in PKI RFCs which are best ignored, although I've never really written
 it up since I didn't feel that publishing something like this would raise
 people's views of PKI standardisation much :-).  OTOH not having it available
 leads to much pain for implementors as everyone new to the field has to find
 out the hard way which bits of the standard do and don't work.  What are
 people's opinions on this?]

Peter.