Thank you Ryan, for clearly articulating the concern. I have updated the draft policy document <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing> to the following -- changes are in italics below, and highlighted in green in the document. ==
keyCompromise (1) The CRLReason keyCompromise (1) MUST be used when one or more of the following occurs: - the CA obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise; - the CA is made aware of a demonstrated or proven method that exposes the certificate subscriber’s private key to compromise; - there is clear evidence that the specific method used to generate the private key was flawed; - the CA is made aware of a demonstrated or proven method that can easily compute the certificate subscriber’s private key based on the public key in the certificate (such as a Debian weak key, see https://wiki.debian.org/TLSkeys <https://wiki.debian.org/SSLkeys>); or - the certificate subscriber, *who has provided proof of possession of the private key**, *requests that the CA revoke the certificate for this reason. *** If the certificate subscriber has not previously provided and can no longer provide proof of possession of the private key, they may still request revocation due to keyCompromise, and that revocation SHOULD be limited in scope to only the certificate issued to that certificate subscriber, even if the key in the CSR is used by other certificates.* *The CRLReason keyCompromise (1) MAY be used when the CA obtains verifiable evidence that the certificate was issued to a subscriber who does not own or control all of the domain names listed in the certificate. For example;* - *the certificate subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; or* - *the CA obtains reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the certificate should not be relied upon.* Otherwise this CRLReason MUST NOT be used. == I am having difficulty with this part and will continue to appreciate suggestions on how to improve this. Thanks, Kathleen -- 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/25fa980c-0014-4751-a2ef-9c6f86042b91n%40mozilla.org.
