[SSL Observatory] PKI "fixes" that don't fix PKI (part II)

[Peter Gutmann]

Lucky Green <shamrock at cypherpunks.to> writes:

>Moreover, I noticed that some posts list one or more desirable properties and
>requirements together with a proposed solution.

That's the nice thing about PKI, there's more than enough fail to go around.
Everyone gets to fix their own particular bit without infringing on anyone
else's bits.

>[OCSP] The consequences of that decision are hounding us to this day.

Two more factors in OCSP:

  It was written to codify the business models of the vendors whose employees
  created the spec.  This... also didn't help much.

  Some of it is just really, really bad design.  The problems with the bizarro
  cert identifier (you push some information through a one-way hash function
  so the other side can no longer see what it represents, don't hash some
  other data, and the cert itself is represented solely by a serial number
  rather than a unique identifier for the whole cert like a fingerprint) were
  pointed out numerous times by numerous people during the design process.
  This, and much other flawed design that was repeatedly pointed out to be
  problematic, ended up in the RFC anyway.  Among the IETF working groups,
  PKIX is particularly bad in terms of design-by-committee product, but even
  by PKIX' already-poor standards, OCSP is bad.

>Even worse of are other embedded and industrial systems, which also remain
>vulnerable for the duration of the devices replacement cycle. A cycle that
>can span years or even a decade.

Yup.  The update cycle for software on those is "never", so as you say you
need to wait for the hardware update cycle.

Having to resort to pushing out updated binaries is really symbolic of the
total failure of PKI mechanisms to deal with this situation.  Or, to quote Ian
Grigg, "revocation works, except when you need it".

Peter.