On Tue, May 19, 2020 at 12:35 AM Kyle Hamilton <kya...@kyanha.net> wrote:
> > > 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.) > This is a strawman argument based on fundamental misunderstanding, not the logical end. You’ve directly conflated public and private key, and confused the ability to create a signature with attribution. In short: this is utter nonsense. I’m disappointed to even need to point out how unsound the statement of “another entity was certified as being able to make signatures which could be technically attributed to the Let's Encrypt CA” is. This doesn’t hold water at all. The Issuing CA is not certifying a proof of possession of a private key, so naturally you can’t (and shouldn’t) conclude it is a proof of possession of a private key. This is basic. > 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. > This is, continuing, nonsense. This is entirely unnecessarily precisely because it *isn’t* a proof of possession of private key. > (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). > Again, you’re trying to call it both ways. You’re right to point out the logical absurdity of having your cake and eating it to, but you’re missing that you’re the one making that claim. The concerns you raise are there only if you believe it is a PoP. As I’ve said, repeatedly, it is not, nor should it be. These concerns entirely disappear. A TLS Certificate is an expression of authorization, by the domain holder, to allow a public key to be used for their domain. The domain holder is permitted to express whatever public key(s) they want, with all the attendant risk, and the certificate is an expression that the CA has verified that assertion and expression by the domain holder. Similarly, in the case of OV/EV, it’s similarly an expression that the given identity has authorized the key. You’re arguing in favor a property - non-repudiation - that by very protocol does not exist for TLS, nor does it need to. The potential use cases for such a property can be addressed by other protocols/formats, with their own corresponding certificates (e.g. document signing certificates for signing documents that cannot be repudiated). > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
