On Mon, May 18, 2020, 19:46 Ryan Sleevi <r...@sleevi.com> wrote: > On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > Regardless of that potential con, though, there is one very important > thing > > which Proof of Possession is good for, regardless of whether any credible > > attacks are "enabled" by its lack: it enables identification of a > situation > > where multiple people independently generate and possess the same keypair > > (such as what happened in the Debian weak-key fiasco). Regardless of how > > often it might be seen in the wild, the fact is that on every key > > generation there is a chance (small, but non-zero) that the same key will > > be generated again, probably by someone different than the person who > > originally generated it. (With bad implementations the chance gets much > > larger.) > > This argument doesn't hold water. This is an argument not about proof > of possession about private key, but about the public key itself. > Multiple parties possessing the same key pair are revealed by the > public key. Proof of possession provides zero value. >
So... taking this argument to its logical end, Let's Encrypt should have immediately revoked its public key when it was found to have been issued to another entity by another member of CABF, which is supposed to operate within the constraints of identification embedded in the Basic Requirements. (i.e., another entity was certified as being able to make signatures which could be technically attributed to the Let's Encrypt CA, which qualifies as "loss of control of the CA private key". A private key is not a device, or an authorized or unauthorized copy of a PKCS#8 or PKCS#12 structure. A private key is a sequence of bits which encodes a value which, when operated upon in accordance with the rules of the algorithm it was generated under, will generate a value which can be verified (and possibly decrypted, in the case of RSA) with its corresponding public key value. Random generation means that the independent generation of a keypair is always a potential risk. The reason we have a uniform and large key space and generation process is to minimize the risk that this will happen, but a non-zero risk is not a zero risk.) In this case, it becomes even more important for CAs to prove that the private key is held by every person who claims it as being their public key -- again, to change it from a theoretical/potential/too-expensive-to-act-on threat to an actual key compromise scenario that mandates pushing the big red button and holding a new key generation ceremony and regenerating the PKI infrastructure and getting the new root key installed in browsers and operating systems as soon as possible. (or, if it's an intermediate, generating a new intermediate, contacting all legitimate recipients and having them change their certificate chains, and revoking the one that had its key independently discovered.) Unfortunately, you can't have it both ways. What's more important, correct certificate issuance (the issuance is by the entity trusted to issue the certificate), or lack of disruption? The CA has always been expected to err on the side of correct issuance (which is why, for example, the Netherlands PKIOverheid intermediate was distrusted). -Kyle H _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
