On Sun, Mar 22, 2015 at 11:48 AM, Peter Gutmann
Gregory Maxwell <gmaxwell(_at_)gmail(_dot_)com> writes:
A CA has signed an intermediate CA cert which is loaded in an interception
appliance. You blacklist this certificate by ID. Your blacklisting is
bypassed by simply changing the encoding of the when sending the cert chain
and now your traffic can be intercepted again.
This issue has been known for a long, long time (well, I guess not by the
OpenSSL authors :-). The problem is its being tied to a blacklist-based
security mechanism, you can always evade the blacklist through trivial
encoding changes that produce a valid but not bit-for-bit identical encoding.
Since all of PKI is built around blacklists (the second dumbest idea in
computer security, and arguably a special case of the dumbest idea in computer
security, default-allow), the PKIX folks argued that using certificate
fingerprints to uniquely identify a cert wasn't allowed because it broke their
blacklist/default-allow based approach to things.
As a result, they identify certs via their serial numbers (so a CRL isn't
really a CRL but a SNRL, a serial-number revocation list). So now, instead of
a single easily-identified problem (trivially fixed by not relying on
blacklists for security), you have a whole raft of problems, many of them
still waiting to be discovered.
In other words the PKIX approach is to decide on a wrong solution
(blacklists), and then to break other things (certificate IDs) in order to
perpetuate the wrong solution.
No, the idea in PKI is that certificate issue is a whitelisting. So
CRLs are then a blacklisting of previous whitelist entries.
I don't think it really matters though as short lived certs are going
to be the basis for the emerging PKI/2. The need for certificate
revocation lists goes away just when I work out how to compress them.
If we could agree on one way to calculate a fingerprint of a key that
can be used for both OpenPGP purposes and PKI/2 then we can get the
systems to interop very nicely.
openpgp mailing list