Steve Hanna <steve(_dot_)hanna(_at_)sun(_dot_)com> 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.