Re: DN Encoding by UTF8String

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Jean-Marc Desperrier <jmdesp@xxxxxxx> writes:

>The problem is *not* for the low level crypto API to support UTF8String.
>Basically all API around do that.

Only newer ones do.  Some (e.g. Netscape 4.x) will not just fail to process
the string but actually crash the application when they encounter a
UTF8String.

>There's is detailled information about how memcpy() to encode and memcmp() to
>compare don't work as soon as anything more complex than printablestring is
>involved. 

Why not?  The encoding rules are:

  DN originator (e.g. client generating a cert request) encodes the DN in any
    way they see fit;
  subsequent users use memcpy() to "re-encode" the original DN, and memcpy()
    to compare it;

OK, that doesn't work for something odd like a directory lookup, but for
normal cert usage where all you care about is locating a cert or checking for
equality based on a DN, it's fine.

>And don't work also if you take into account anything from the full x520
>comparison rules.

... which don't work in practice (see the X.509 Style Guide), so it's not
really relevant.

>But this kind of comparaison being prevalent in application, the only
>solution to avoid problem is for the CA to normalize strictly every name
>before emitting certificates.

How well do you think that'll work in the presence of implementations that use
memcpy() and memcmp()?  Have you ever tried generating a cert request from
(say) IE and sending it to a CA that "strictly normalizes" the DN before
returning it?

(To save you the effort if you haven't done this, it'll be rejected by the
 client.  I'm just using IE as a common, easy-to-get-to example here, you can
 see the same thing with other software when you fiddle with DN encodings.
 Try signing an S/MIME message with the DN in the SignerInfo canonicalised to
 not match the cert DN).

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

Peter.