not sure it's safe to let one revoke with reason key compromise without control of key: IIRC wasn't it ruled that CA doesn't need to verify subscriber controls private key it requests for TLS cert? (https://groups.google.com/g/mozilla.dev.security.policy/c/x_DeTDKBwWI/m/ogSKLpx8CgAJ)

22. 1. 21. 08:11에 Kathleen Wilson 이(가) 쓴 글:
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.

Thanks,
Kathleen


--
You received this message because you are subscribed to a topic in the Google Groups "[email protected]" group. To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/RVFnJJRuUag/unsubscribe. To unsubscribe from this group and all its topics, 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/ed11d7d4-7368-468d-93b3-f0733cea8711n%40mozilla.org <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ed11d7d4-7368-468d-93b3-f0733cea8711n%40mozilla.org?utm_medium=email&utm_source=footer>.

--
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/75d278a0-fbbf-3e19-b205-b2d41282cd26%40gmail.com.

Reply via email to