Subject: Re: PrintableString not usable tigether with OCSP?

From: [email-masked] (Peter Gutmann)
Date: Wed, 13 Nov 2002 14:21:33 +1300 (NZDT)

From a discussion with an Anonymous Person:

-- Snip --

>While tehcnically there's this DN compare algorithm in RFC2459 or the evil
>X500 version anyone with any sense ignores it completely and normally treats
>DNs as equal only if they have the same encoding or it will break OCSP et al.
>
>Have you ever come across "equal" DNs that don't have the same encoding? I
>know I never have.

I doubt I have - I actually implemented all the fancy conversion stuff back in
about 1997, but I doubt it's ever really been tested.  I'm currently redoing
that part of the code, I'm tempted to remove it all and do a memcmp() because
it makes it harder to play tricks with encoding forms to get around security
checks.  For one thing the coding required is so convoluted that its
complexity alone is likely to be a source of security problems.

>Presyumably you did the lesser evil version rather than the full version
>which I doubt anyone would want to implement: i.e. the thing that can compare
>Korean T61Strings and BMPStrings.

I'd only bet on it working as far as latin1, however in theory I could compare
widechars to Unicode.  In practice I found (in 1997, it's probably better now)
that mbstowcs() usually only handled latin1, however I suspect
MultiByteToWideChar() (at least under NT) handles more stuff because MS is
pretty thorough with i18n.  OTOH I have no idea what sort of stuff would
appear in a multibyte T61String encoding except it's unlikely to be anything
that any ASN.1 spec defines but just whatever the local charset happens to be
and whatever displays OK in Windows.  OTOH this stuff is barely used, at one
point I wanted to play with some Asian charsets and had to ask someone to
specially generate a cert for me because no-one normally uses them (if you
look at something like the Hong Kong Post CPS, it says that if your company
has a non-ASCII-representable name, you'll need to use an ASCII one to get a
cert).  I asked someone else to create a Unicode cyrillic string for me for
testing (that's outside the latin1 range, so I know it'll end up Unicode) to
see if my code will handle it, but since there's no real multibyte equivalent
I can't easily test the string-comparison capability, only the basic Unicode-
handling.

I suspect that if someone did manage to create a synthetic cert chain with
(say) the issuer in multibyte and subject in Unicode, 100% of implementations
which don't fall back to chaining by keyIDs would fail to recognise it as the
issuer.  That's one guarantee that it's safe to ignore the comparison rules
and use memcmp().

-- Snip --

Peter.

---

From: Steve Hanna <[email-masked]>
Date: Wed, 13 Nov 2002 09:57:06 -0500

Peter Gutmann wrote:
> I suspect that if someone did manage to create a synthetic
> cert chain with (say) the issuer in multibyte and subject
> in Unicode, 100% of implementations which don't fall back
> to chaining by keyIDs would fail to recognise it as the
> issuer. That's one guarantee that it's safe to ignore the
> comparison rules and use memcmp().

The path validation code in Sun's JDK 1.4 implements the
X.500 DN matching algorithm (stripping excess spaces and
doing case-insensitive comparison) for PrintableString and
UTF8String. And we support matching a PrintableString to a
UTF8String. We don't support Teletex (T.61), since this is
not widely used and not recommended for future use.

There are many people and companies whose names cannot be
represented with PrintableString. If we want PKI to be widely
deployed, we need to support UTF8String properly. I look forward
to the advancement of draft-zeilenga-ldapbis-strmatch-01.txt,
which is a stringprep profile for X.500 DN matching. Stringprep
implementations are starting to come out now, which will remove
the need for PKIX folks to be I18N experts.

If you'd like to have some certs that contain subject or
issuer names with UTF8String, let me know. I'd be glad to
send you some.

Thanks,

Steve Hanna
Sun Microsystems, Inc.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Wed, 13 Nov 2002 09:41:21 -0800

While I agree with the overall statement that using memcmp is
the best way of checking for DN equality, there are folks that
are using non-ascii characters in certs - in particular there
are a lot of certs using Kanji in Japan.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Tuesday, November 12, 2002 5:22 PM
> To: [email-masked]
> Subject: Re: PrintableString not usable tigether with OCSP?
>
>
>