[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

[Rob Stradling]

On Saturday 10 Sep 2011 09:24:25 Peter Gutmann wrote:
> Rob Stradling <rob.stradling at comodo.com> writes:
> >One man's "blatant violation" is another man's "profile" [1].  :-)
> 
> It'll be interesting to see how PKIX reacts to this, since their WG chair
> has said repeatedly that PKIX defines reality,

Do you think he'd hit me if I suggested that maybe ichsunx2 defines reality 
these days?!

> reality does not define PKIX.  I guess now we'll get to see what happens when
> some hard reality runs into PKIX.
> 
> >If it's not been done already, it might be an interesting exercise to
> >write an I-D called something like "The Hardened OCSP Profile for the
> >Internet".
> 
> Some of this stuff is exactly what was proposed more than a decade ago, and
> repeatedly rejected by PKIX.  In any case though this isn't going to come
> close to fixing OCSP.  See the rest of my earlier response, since it's
> multiple-redundant broken, by design, if you fix one part all it'll mean is
> that someone wanting to bypass it can exploit another part (they did a
> pretty good job in that respect, there's no way to fix it by changing just
> one or two parts).  At best this protocol variant (not a profile, see
> below) is going to create an illusion of fixing it ("we changed some bits,
> it's OK now").  It needs to be replaced with a properly-designed mechanism
> that actually works.

The important thing is that we fix revocation checking somehow.  I don't care 
how we do it.  If OCSP must die, then so be it.  Or if OCSP must be beaten to 
within an inch of its life and then undergo major surgery, then so be it.

A properly-designed mechanism is always a nice idea.  But I'll take 
inelegently-patched-up OCSP if that's the best that all required parties can 
agree to.

> >Here are a few of the "blatant violations" of RFC2560 that are present in
> 
> >RFC5019 (The Lightweight OCSP Profile for High-Volume Environments):
> They're not violations in any way, they're a pure profile.  So while the
> original says "you can do any of X, Y, Z", RFC50919 (and profiles in
> general) say "for the purposes of this profile you can only do X".  Every
> example you give of a "violation" is a case of this.  The main PKIX RFC
> itself is a profile of X.509, so X.509 will say "you can do X, Y, Z" and
> the PKIX version will say "you can only do X" (with the implication being
> the Y and Z are unnecessary or irrelevant).
> 
> Oh the other hand what you're proposing is a complete change in behaviour
> for OCSP

I would put only allowing a "good" response for known-issued certs in the "for 
the purposes of this profile you can only do X" (and therefore you cannot do Y) 
category (where RFC2560 essentially says...
X = You can specify "good" for known-issued certs.
Y = You can specify "good" when you don't recognize the serial number).

> and the addition of new extensions to the protocol.  That's not a
> profile any more, that's a new version (or variant) of OCSP.

OK.  I concede that adding a new required Extension is stretching the concept 
of a "profile" a bit too much.

> Peter.

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online