The BRs, in s4.9.1.1, say: > The CA SHALL revoke a Certificate within 24 hours if one or more of the > following occurs: > > [...] > 3. The CA obtains evidence that the Subscriber's Private Key > corresponding to the Public Key in the Certificate suffered a Key > Compromise
I've come to have some concerns about this clause of the BRs, in that it seems very much up to the CA to decide what constitutes valid "evidence" of key compromise, and there doesn't appear to be anything (other than possible mdsp censure, after the fact) preventing a CA using "your evidence is insufficient" as a way of delaying revocation, potentially indefinitely. In my specific case, I've been providing a JWS[1] signed by the compromised private key, and CAs are telling me that they can't (or won't) work with a JWS, and thus no revocation is going to happen. Is this a reasonable response? If it is a reasonable response, what properties are necessary to differentiate valid evidence from invalid? Is it appropriate for a CA to be able to unilaterally decide what constitutes valid evidence, and should they be able to change that decision at any time? Relatedly, if a CA were to receive a key compromise notification which truly *doesn't* have sufficient evidence of compromise, but which at least has some degree of legitimacy (rather than "I haxxed teh keys to your CA, better pay me dogecoin!!!11!one!"), is there (or should there be) any onus on the CA to respond to that notification within a certain timeframe? I ask this because I accidentally sent a couple of compromise notifications with an incorrect URL. While one notification got what appeared to be a human saying "we'll look into it" (which itself was sent more than 24 hours after I received the corresponding auto-ack), others have been greeted with complete radio silence (other than the auto-ack). This seems... sub-optimal. I'd appreciate commentary and feedback on this area of the BRs and its ramifications, to help me to decide whether to report these situations as failures to revoke, or perhaps modify my procedures for reporting publicly-trusted certificates whose keys have been published. Thanks, - Matt [1] "JSON Web Signature", as specified in the standards-track RFC7515. It is used in a variety of places, including, but not limited to, the Automatic Certificate Management Environment (ACME, RFC8555) -- although I wasn't consciously aware of that at the time I chose to generate key compromise attestations in that format. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
