Re: DN Encoding by UTF8String

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Richard Levitte - VMS Whacker <levitte@xxxxx> writes:

>OpenSSL provides a limit set of rules for comparing DNs: it does space
>normalization and a case insensitive compare for PrintableString, and case
>insensitive comparison for IA5String if the attribute type is emailAddress
>from pkcs#9.  For all other strings, a straight memcmp() is done.  Would you
>say we're going overkill?  

Hmm, I don't know if it's a good idea to encourage this sort of behaviour
(that is, apps that generate certs that require custom code in order to work).
Some years ago (after I snapped out of my X.520 delusion and switched to
memcmp()) a vendor complained that cryptlib was failing to find a cert with a
canonicalised name.  I told them to try the same thing with Netscape and MSIE,
and fairly soon afterwards (within a matter of days, I think) they had a
service release out that didn't try and modify names any more.

If cryptlib had still been using the X.520 comparison at that time, they might
have gone ahead and deployed a product that failed in the field once it was
exposed to other implementations.  Better to be strict and let darwinism do
its work.  If Netscape had been less lenient about accepting all kinds of
broken HTML, it wouldn't have encouraged the spread of apps that generate the
broken HTML.

>I'm not sure about that, since those special cases were added fairly
>recently, after we got some user complaint, and possibly after I had a run
>with the NIST PKI test bunch...

Are those test certs representative of real-world usage though?  There's a
danger of adding all sorts of special-case complexity that nothing (except
some artificial test vectors) ever exercise, which then comes back to bite you
later when there's some exploitable problem in there.  That's why I eventually
removed the X.520 comparison code, it's so complex (and complex in a system-
specific way, since you're dependant on different levels of i18n support on
different systems) that it'd be pretty much impossible to ever guarantee it
worked as required.  Guaranteeing the behaviour of memcmp() is much easier.

You could always enable a NIST-test-vector mode that uses ad-hoc fixups, and a
normal-use mode that uses memcmp().  In other words, make it explicit to the
user, through having to enable it via a #define or use a configure option,
that what they're doing is likely to cause problems down the track.

Peter.