On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton <kya...@kyanha.net> wrote:
> With proof of possession, these situations can be detected and raised as > being not-just-theoretical, and the CAs (or whoever wants to search the CT > logs) can notify the entities involved that they probably want to change > their keys. In the case of CA keys potentially being duplicated, this is an > incredibly important capacity. In the case of EV certificate keys being > duplicated, it can be a reportable event for the certified entities (such > as banks) if copies of their private key are found to be in the possession > of anyone else. > How, precisely? Today, the vast majority of certificates lack any end-entity identifying factors other than some number of SAN dnsName entries. In modern CDNs (example: CloudFlare), a single certificate might represent a plurality of entirely unrelated websites run by entirely unrelated entities who happen to share a service provider in common. In as far as that these sites are already sharing a TLS concentrator -- while it is not the practice of anyone I know of -- such a service provider could have quite a number of TLS concentrator elements sharing (access to) a public/private key pair and might choose to provision quite a number of unrelated certificates with the same key. Two certificates issued at two different times containing the same public key is not proof one way or the other. It does not prove two entities are definitely related. It does not prove that they are not. But the fact that proof of possession isn't required increases the plausibility that it does not prove a relationship. I wonder if the attendant ambiguity has saved anyone's head from rolling. On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton <kya...@kyanha.net> wrote: > CABForum's current Basic Requirements, section 3.2.1, is titled "Method to > prove possession of private key". > > It is currently blank. > > A potential attack without Proof of Possession which PKIX glosses over > could involve someone believing that a signature on a document combined > with the non-possession-proved certificate constitutes proof of possession, > and combined with external action which corroborates the contents of the > document could heuristically evidence the authority to issue the document. > (Yes, this would be a con job. But it would be prevented if CAs actually > had the applicant prove possession of the private key.) > > 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.) > > With proof of possession, these situations can be detected and raised as > being not-just-theoretical, and the CAs (or whoever wants to search the CT > logs) can notify the entities involved that they probably want to change > their keys. In the case of CA keys potentially being duplicated, this is an > incredibly important capacity. In the case of EV certificate keys being > duplicated, it can be a reportable event for the certified entities (such > as banks) if copies of their private key are found to be in the possession > of anyone else. > > Non-zero probability of duplication is not zero probability of > duplication, and relying on it being "close enough to zero" is eventually > going to bite us all. It's up to those who work for CAs to put in > mitigations for when that day ultimately arrives, or else risk the > viability of not only their businesses but every other CA business they > compete with. > > So, I request and encourage that CABForum members consider populating > clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be > mandated. > > -Kyle H > > On Sun, May 17, 2020, 22:23 Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> > In particular, there must have been some authorisation carried out at >> some >> > point, or perhaps that wasn't carried out, that indicates who requested >> the >> > cert. What I'm trying to discover is where the gap was, and what's >> > required >> > to fix it in the future. >> > >> >> What gap, exactly? There’s not a risk here. >> >> I don’t think it’s been codified that private key possession or control >> has >> to be demonstrated. >> >> I think it would be plausible for a CA to allow submission of a public key >> in lieu of a CSR and that nothing would be wrong about it. >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
