Lucky Green <[email protected]> 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. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
