Re: Request change in son-of-rfc2633

[[e-mail] (Peter Gutmann)]

Steve Hanna <[e-mail]> writes:

>Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name 
>chaining checks in path validation needs to have their eyes checked. RFC 3280 
>says in many places that name chaining MUST be checked.

Uhh, I'm not sure who that was directed at, but if it was at me then I should 
point out that the tea leaves comment was an observation that no-one seemed to 
be able to agree on the role of the sKID, with all manner of possible 
interpretations having been presented in the recent thread.  Seeing everyone 
trying to figure out how to interpret the sKID requirements reminded me of 
people trying to read tea leaves.

Getting somewhat more tongue-in-cheek now:

>I'm sure that some customers have created PKIs where name chaining doesn't 
>hold, 

Standard practice for cross-certification, re-parenting, and all the other 
stuff that I gave the generic label "spaghetti PKI" to (you can tell from the 
label I use for it what I think of it :-).

>but that's an error on the customer's part.

That's what I've been saying for years (see e.g. my statement a couple of months
back "There is a special name for a PKI of this kind.  It's called 'Broken' or
'Defective'"), but I guess that's something the spaghetti PKI fans and myself 
will have to agree to disagree on.

>In fact, they may have opened themselves and their customers up to security 
>holes and perhaps even legal liability.

When was anyone ever held liable for implementing a broken PKI?  Usually any 
investment of large amounts of money that results in a broken PKI is followed 
by the investment of even more money in it (either that or the quiet 
cancellation of the project).  No-one ever gets held liable.  Why do you think
we have products like the ones you mentioned out there?

>This reminds me of Microsoft's decision to not check the Basic Constraints 
>extension, treating every certificate as a CA certificate. This decision, 
>presumably made in to please a customer, resulted in a HUGE security hole.

It wasn't a conscious decision, just bad programming.  Mozilla (and no doubt 
some others that didn't get any publicity) did the same thing, and I'm sure 
they didn't get asked to do that by customers.  The flaw had been known for at 
least five years, but no-one cared until the scaremongering in the media forced 
vendors to fix things (see the above comments about liability - you can get 
away with calling anything you like "X.509 standards-compliant", so why bother 
doing the job properly?).

Peter.