On Mon, Mar 23, 2020 at 06:15:00PM +0000, Jeremy Rowley wrote: > There are two things worth discussing in general: > > 1. I’m very interested in seeing the Let’s Encrypt response to this issue > since the biggest obstacle in trying to find all of the keys with the same > private key is the sheer volume of the certs. Trying to do a > comprehensive search when a private key is provided leaves some window > between when we start the analysis and when we revoke.
Well, Let's Encrypt has committed to automatically blacklisting keys reported for keyCompromise in its CA software (https://community.letsencrypt.org/t/116762), so it won't be nearly as problematic for them as it appears to be for Digicert. At any rate, though, I can get a list of all certs with a certain SPKI out of crt.sh in a matter of a couple of seconds, and crt.sh has a *lot* more certs in it than Digicert has issued. The schema for the certwatch database is publicly available, so, if nothing else, you could stand up a copy of that database, skip deploying the CT scrapers, and just stuff a copy of every cert you issue into the certificate table, and you're off to the races. > 1. Another issue in trying to report keys that aren’t affiliated with > any cert is that the process becomes subject to abuse. Without knowing a > cert affiliated with a key, someone can continuously generate keys and > submit them as compromised. You end up just blacklisting random keys, > DDOSing the revocation system as it kicks off another request to search > for those keys. I don’t think it’s feasible. This is why the disclosures > need to be affiliated with actual certs. I don't think that anyone has, as yet, claimed that it is a BR violation for a CA to issue a certificate with a key for which they have not yet received a valid certificate problem report. Nor do I believe that anyone has claimed that a certificate problem report without any indication of a problematic certificate is valid. So, it appears to me that you're arguing against something that nobody has proposed. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
