Subject: Re: Basic Constrains and Key Usage processing

From: [email-masked] (Peter Gutmann)
Date: Wed, 26 Jun 2002 18:47:17 +1200 (NZST)

"David P. Kemp" <[email-masked]> writes:

>In your experience, do implementors of IPSEC or TLS receive much slack if they
>are not "strict in what they generate"?

I can't really comment on IPsec (although I've heard that a year or two back
some of the certs being used made the ones mentioned in the style guide seem
like canon in comparison), but for SSL/TLS the rule is that you do what the
browser does (that is, whatever it takes to make Netscape and MSIE work),
whether the spec says so or not.  See for example Netscape's encoding bug for
RSA-wrapped keys (fixed in TLS), which everyone copied, or their DSA sig
formatting bug which Netscape justify by citing installed base and MS argue
against by citing standards non-compliance.

OTOH it isn't just Netscape, MSIE at one point would generate packets of up to
64K (allowed max is 16K) and everyone just broke their code to handle this.
Since browsers are universally used, any failure by the browser to interoperate
with X is seen as a bug in X rather than a bug in the browser.  I guess you
could generalise that to say that the rule for SSL/TLS implementations is that
you follow the de facto semi-standard of Netscape and to a lesser extent MSIE,
and finally fall back to what the RFC says (X.509 is no different, see below).

Once nice thing about RFC 2246 is that in several locations it actually tells
you about widely-occurring browser problems/bugs to allow you to add
workarounds.  RFC 2440 does this as well.

>Should not CAs that mention the PKIX brand be held to a similar standard?

You mean breaking their code/certs to be compatible with other broken
certs/code? :-).  Actually that's already happened, look at the issue with MS
reversing the handling of the critical flag a few years back, all the CAs broke
their certs to be bug-compatible.

The problem is that PKIX (I'll generalise here and call it "X.509", since
that's the buzzword the masses are familiar with, which in practice has been
diluted to the point where it means "anything but PGP and SPKI") isn't a brand
in the legal sense, so there's no enforceability attached to it.  I really
don't know how to address this issue, perhaps make "X.509" a TM/service mark
like "Designed for Windows" (or whatever the phrase is) and then have someone
slapping people who use it without passing some compliance test.  At the moment
X.509 is like the League of Nations, lots of good intentions and zero
enforcement power, so everyone can be a member while still doing pretty much
whatever they please.

The intent of my previous message was just to point out that working from a
viewpoint of "In my reality, things work like this" isn't very useful when
everyone else's reality differs from yours (I think that's the approach that
lead to OSI :-).  One possible solution would be to have some sort of minimum
compliance check like RSA's S/MIME interop test, where you send in a signed,
encrypted message and get back the same.  If you can do that, you've got 99% of
the required functionality right... come to think of it, the one place where
you really don't hear much about interop problems is S/MIME (assuming you stick
to v2 and don't try any of the fancy stuff in v3, I was pleasantly surprised to
find that I could interoperate the first time with Messenger and Outlook, which
certainly wasn't the case with Navigator and IE).  Maybe PKIX needs a similar
"You must be at least this compliant to call yourself X.509" test.

Peter.