Re: DN Encoding by UTF8String

[Richard Levitte - VMS Whacker <levitte@xxxxx>]

In message <200312150736.hBF7aLJ14015@xxxxxxxxxxxxxxxxx> on Mon, 15 Dec 2003 20:36:21 +1300, pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann) said:

pgut001>   subsequent users use memcpy() to "re-encode" the original
pgut001>     DN, and memcpy() to compare it;

I doubt that :-).

pgut001> In my early naivete about the real state of X.500 I actually
pgut001> tried to implement the X.520 name comparison rules some years
pgut001> ago (that's how the Style Guide entry on this came about).  I
pgut001> found out very quickly that one thing you never, ever do is
pgut001> change the DN encoding once it's been created by the
pgut001> originator (I originally stored the DN in canoncalised form,
pgut001> and had to change my code to cache the original DN so I could
pgut001> "encode" it with memcpy()).  A year or two after changing the
pgut001> encoding to memcpy() I #ifdef'd out the full DN comparison
pgut001> and replaced it with a memcmp() of the encoded form.  A year
pgut001> or two after that, I removed the X.520 comparison code
pgut001> entirely.  All it was was a potential source of trouble
pgut001> anyway, it was far too complex to rely on.  I haven't had any
pgut001> trouble since I switched to memcpy()/memcmp(), and it's been
pgut001> used in some really odd environments with all sorts of
pgut001> non-European character sets (cryptlib seems to be quite
pgut001> popular in Asia for some reason, possibly because it really
pgut001> goes out of its way to handle i18n, which means the i18n
pgut001> support got a lot of stress-testing).  In fact, exactly
pgut001> *because* of memcpy()/memcmp() it will work with absolutely
pgut001> anything: BMPString, T61String, T61String that's actually an
pgut001> 8859-1String, floating diacritics (how much other software
pgut001> can handle those?), UTFString, string types not even dreamed
pgut001> up yet.

Hmm.  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?  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...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"