On Thu, Jan 20, 2022 at 6:11 PM Kathleen Wilson <[email protected]> wrote:
> On Tuesday, January 18, 2022 at 5:56:21 PM UTC-8 [email protected] wrote: > >> >> >> On Tue, Jan 18, 2022, 7:16 PM Kathleen Wilson <[email protected]> >> wrote: >> >>> >>> 4) Added text to a bullet point in the keyCompromise section in order to >>> ensure that the certificate subscriber can only declare keyCompromise for >>> certificates for which they control the private key. >>> - the certificate subscriber *provides proof of control over the >>> private key and* requests that the CA revoke the certificate for this >>> reason code; >>> >> >> Suppose that the subscriber suffers a ransomware attack, decides that it >> is better policy to say we never pay the dane geld, and this loses access >> to the private key and knows that the key was compromised. >> >> This arguably could fall under the first possible bullet but if so I have >> trouble understanding why we need the fourth bullet. Isn't the subscriber's >> statement proof of compromise? >> >> Sincerely, >> Watson >> > > > This is a good question. > > "" > The CRLReason keyCompromise (1) MUST be used when one or more of the > following occurs: > > bullet point #1) the CA obtains verifiable evidence that the certificate > subscriber’s private key corresponding to the public key in the certificate > suffered a key compromise; > > bullet point #5) the certificate subscriber provides proof of control over > the private key and requests that the CA revoke the certificate for this > reason code; > "" > > Is bullet point #5 sufficiently covered in bullet point #1? > > Or is bullet point #5 needed in addition to bullet point #1? > > I will appreciate opinions on this. > Hi Kathleen, I think the question is whether you want to allow subscribers to request revocation for keyCompromise even if they're not able to provide evidence. I think to Watson's point, what happens if someone compromises a server, but then also deletes the key? If that was the only copy the server operator had - which is a desirable situation - then they wouldn't be able to demonstrate the compromise under #5. However, it's a question of whether or not the evidence the Subscriber provides to the CA is sufficient to demonstrate #1. I would suggest these are different use cases: Bullet #1 is trying to handle external parties (not the Subscriber) flagging risks that the Subscriber may not wish to have public, but which is relevant to end users. Bullet #5, on the other hand, seems like it restricts the capabilities of the Subscriber - by putting them through more work, which they may not be able to accomplish? If the goal is to ensure that key compromise is only used if: A) The Subscriber wants it (i.e. not by the CA as part of a contract dispute or part of some other policy or business practice detrimental to end users) B) The key was compromised (even if the Subscriber doesn't want it revoked) then it seems like changing bullet #5 to simply being that the Subscriber requests the revocation with keyCompromise should be sufficient? If the concern is that the Subscriber may maliciously request a cert be revoked for keyCompromise, e.g. to spam/flood systems like OneCRL, they could do the same by posting the private keys. So it seems fine to just let the customer self-declare, while understandably restricting the CA's the ability to unilaterally declare unless they've met the burden of proof/evidence. This keeps Subscribers in control, while balancing the needs of end users. This also raises a separate question - why is bullet #6 (domain validation change) part of keyCompromise and not part of privilegeWithdrawn (which includes improper domain validation) -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEWipEYN-S-s48tzXqidvf6tRxFxgCyGCDg7QhJisZuSw%40mail.gmail.com.
