[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DN Encoding by UTF8String



Name comparison is definitely a thorny problem. The name comparison rules in RFC 2459 and 3280 were an attempt to establish a reasonable bar that current implementations already met, or could easily meet.

2459 and 3280 require white space compression and case-insensitive match for PrintableString because client implementations already met this standard. It is also very easy - strings never get longer and a single pass is all one ever needs to prepare for the comparison. (In fact you could probably compare in a single pass, normalizing as you go!)

This functionality is expected to be present, and is reflected by the content of existing certificates. For example, the country code is sometimes uppercase and sometimes lower case. Implementations that only performed case sensitive matching would not interpret "C=mx" and "C=MX" as equivalent.

On the other hand, normalization for more complex character sets is fraught with danger. Strings can actually grow during this process, several passes may be required, etc... Name comparison for these character sets was *not* "a reasonable bar that current implementations already met, or could easily meet." So we required, at a minimum, support for a straight binary comparison but we permit an implementation to do more...

Some specific comments:

Peter noted:
> 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

Basically, I would agree. This is reflected by the RFC 3280 requirement that the encoding of an established CA's name be preserved when issuing CA certs. Depending upon clients to perform string normalization accurately and consistently is risky. No matter what they do (or don't) implement, preserving the encoding should provide dependable results.

Richard stated:
> 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?

RFC 3280 is silent with respect to emailAddress. RFC 3280 requires space normalization and a case insensitive compare for PrintableString. For other types, a straight binary comparison is the minimum but more complex name comparison is permitted...

General observation #1: implementing additional name comparison should not create *new* problems. I see three cases. Case 1: If the two strings match for binary comparison, then they will match afterwards. (However, you may get the blue screen of death if the strings grow beyond the expected size and overwrite something it shouldn't!) Case 2: Consider two strings that are a theoretical match but were encoded in different binary forms - if the name comparison rules detect the match, that's great; if not well you didn't make the situation worse. Case 3: Only if two theoretically different string get munged by the normalization process and become inappropriately equivalent would you have a real problem. Case 3 failure seems the less likely than case 2, in my opinion...

General Observation #2: False positives are more dangerous than false negatives... the one place name comparison can result in name constraints. An inappropriate match for permitted subtrees could result in a false positive. An inappropriate non-match for excluded subtrees could result in a false positive. If you buy my theory that case 2 failure is more likely than case 3, that says you should use permitted subtrees where ever possible. It also says that for either type of constraint, you should respect the encoding of the attributes by the issuer.

I don't think RFC 3280 is too much at odds with the OpenSSL implementation or Peter's guidance. However, I should note that name comparison for directory strings encoded in UTF8STRING is a task we have been directed to tackle by the IESG. As the name comparison work progresses in the IETF, the PKIX WG intends to have a document that describes the "right way" to perform such a comparison.

Thanks,

Tim Polk

At 12:43 PM 12/15/2003 +0100, Richard Levitte - VMS Whacker wrote:

In message <200312151122.hBFBM9P15024@xxxxxxxxxxxxxxxxx> on Tue, 16 Dec 2003 00:22:09 +1300, pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann) said:

pgut001> Richard Levitte - VMS Whacker <levitte@xxxxx> writes:
pgut001>
pgut001> >OpenSSL provides a limit set of rules for comparing DNs: it
pgut001> >does space normalization and a case insensitive compare for
pgut001> >PrintableString, and case insensitive comparison for
pgut001> >IA5String if the attribute type is emailAddress from pkcs#9.
pgut001> >For all other strings, a straight memcmp() is done.  Would
pgut001> >you say we're going overkill?
pgut001>
pgut001> Hmm, I don't know if it's a good idea to encourage this sort
pgut001> of behaviour (that is, apps that generate certs that require
pgut001> custom code in order to work).  Some years ago (after I
pgut001> snapped out of my X.520 delusion and switched to memcmp()) a
pgut001> vendor complained that cryptlib was failing to find a cert
pgut001> with a canonicalised name.  I told them to try the same thing
pgut001> with Netscape and MSIE, and fairly soon afterwards (within a
pgut001> matter of days, I think) they had a service release out that
pgut001> didn't try and modify names any more.
pgut001>
pgut001> If cryptlib had still been using the X.520 comparison at that
pgut001> time, they might have gone ahead and deployed a product that
pgut001> failed in the field once it was exposed to other
pgut001> implementations.  Better to be strict and let darwinism do
pgut001> its work.  If Netscape had been less lenient about accepting
pgut001> all kinds of broken HTML, it wouldn't have encouraged the
pgut001> spread of apps that generate the broken HTML.

I understand your thoughts, and I agree that following the KISS
principle (does anyone need that explained?) is tempting.  However,
I'd say that your comparison between non-compliance with X.520
comparison rules and Netscape's boken HTML is flawed.  On one hand,
from the point of view of X.520, MSIE and Netscape are broken since
they don't follow the rules, and that's what you want to encourage.
On the other hand, Netscape's acceptance of some HTML was also broken
from the point of view of HTML, and you seem to want to discourage
that.  The conclusion is that you support breaking the rules in some
cases, while not in others.  That doesn't seem very consistent to
me...

Now from the point of view of "this makes sense", I can understand
your views, but I have to ask "from whose point of view?"  Is everyone
accepting Peter Gutmann as an authority?  I can accept that if that's
the common rule :-).

pgut001> >I'm not sure about that, since those special cases were
pgut001> >added fairly recently, after we got some user complaint, and
pgut001> >possibly after I had a run with the NIST PKI test bunch...
pgut001>
pgut001> Are those test certs representative of real-world usage
pgut001> though?

Considering it's NIST we're talking about, I wouldn't be surprised if
there are some US gov. examples behind those tests...

-----
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"