On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton <kya...@kyanha.net> wrote:
> 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.) > Could you explain how this is different from other stretches of fitness for purpose? For example, I can use Lipton's tea leaves as guidance dictates - for making a beverage purportedly fit for human consumption. I can also try to diving events of the future by finding meaning in the patterns of the tiny dregs of tea leaf left in the bottom of my mug. But I should expect to get laughed at by Lipton customer service if I ask for assistance with this or appear to be taking these predictions seriously. 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
