On Thu, Apr 4, 2019 at 7:57 AM CERT Coordination Center <[email protected]> wrote:
> Thanks Rob! > > Actually, as I look at one of these cases: > > https://crt.sh/?spkisha256=8628d8106b72c39d98e8e731fc3b9364940efea0dfbb4816b1382542a979c834 > > The latest certificate using the above key expires in just a few days. > But you can see the track record of the same private key being used > repeatedly to obtain new certificates. > > My question is this: When a certificate is revoked, is that certificate > revoked in isolation, or is the private key used to obtain that > certificate placed in some sort of blacklist where it cannot be used to > obtain any future certificates? The scenario I'm picturing is that a > customer gets a certificate revoked, but then just uses the same private > key to obtain a new certificate. Potentially from another CA, if they > have trouble with the one that did the revoking. > > It has been discussed in the past that CAs should, at a minimum, be confirming that they're not signing a public key they have previously revoked for key compromise. Otherwise, they have already "obtained evidence" and are required to revoke any new certificate(s) within 24 hours of issuance per BR 4.9.1.1(3): "The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise" Earlier in this thread, Tim wrote "It would probably be a good idea to submit the keys to https://pwnedkeys.com/submit.html as well, as a centralized way for CAs to verify that the keys are in fact compromised." I am not aware of any current requirement for CAs to submit compromised keys to this database or to check it prior to issuance. I suppose that explaining to the revocation-receiving customer why the > revocation happened is a good start. However, I could imagine that at > least some of the involved customers may not fully grasp the concept of > protecting private key material. After all, each one of the cases in > these two batches is a case of the customer publishing the private key > in an app in the Google Play store. > > I've seen cases where the app developer knowingly goes to another CA, apparently because that's easier than modifying their app to remove the dependency on an embedded private key and publicly-trusted certificate. I guess the general gist of what's going on here is that for each case > we've reported in the two batches, the private key material is > compromised. And as such, no certificate should ever be issued for such > a key, by any CA (in my opinion). Does such a mechanism exist to > prevent customers from shooting themselves in the foot in this way? > (compromised key re-use) > > That's going to be up to the individual CA. I would expect most to notify their customer if they try to reuse a key pair that the CA has previously revoked for key compromise. Related: The first batch that we notified included a number of > already-expired certificates. Based on responses I got for those, I got > the impression that there was no action to be taken by the CAs for those > expired certificates. As a result, I ensured that the second batch > omitted cases that lack evidence of a currently-valid certificate. If > there is any key-level blacklisting going on with the CAs, this was > perhaps an incorrect action to take on my part. > > Thoughts? Is there any value to sharing compromised keys used to obtain > certificates that may already be expired? > > > -- > > Thank you, > Will Dormann > > ============================= > Vulnerability Analyst > CERT Coordination Center > 4500 Fifth Ave. > Pittsburgh, PA 15213 > 1-412-268-7090 > ============================= > > > > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
