On Tue, Feb 1, 2022 at 3:22 PM Doug Beattie <[email protected]> wrote:
> Hi Kathleen, > > > > I still have a hard time with 2 types of key compromise processing. It > seems like if the key is compromised it should always be processed the same > way. Would you consider moving this bullet to a different reason code? > > - Otherwise, the CA SHOULD limit revocation to only the instance of that > key that the certificate subscriber had submitted the Certificate Signing > Request (CSR) for > > > > Basically this last bullet > > - the certificate subscriber requests that the CA revoke the > certificate for this reason. > > could read: > > - the certificate subscriber requests that the CA revoke the > certificate for this reason with proof of possession demonstrated at cert > issuance time or at the time of the revocation request.. > > Doug, That significantly changes the meaning here, and that's what Watson and I were raising concerns about. I'm not sure if you're disagreeing with those concerns, which is fine, or if there's perhaps a misunderstanding that can be clarified with improved text. Do you think the following proposal would be clearer? == 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); or - the certificate subscriber requests that the CA revoke the certificate for this reason. The scope of revocation depends on whether the certificate subscriber has proven possession of the private key of the certificate. - If the certificate subscriber requests that the CA revoke the certificate for this reason, and has not previously demonstrated and cannot currently demonstrate possession of the associated private key of that certificate, the CA SHOULD limit revocation to only certificates that are associated with that Subscriber and which contain that public key. - For all other reasons, including previous or current proof of possession, the CA MUST revoke all instances of the key, across all certificates for all subscribers. == TL;DR: If you can't prove the key, and haven't proved the key, you CAN request for keyCompromise, but only for your certs. If you have proved the key possession, or _anyone else_ proves the key is compromised (all the previous bullets), it affects all certificates, for all subscribers. > -- 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%3DHE1S%3D%2B9MKg7g3b6Jna1aXnq6bvgMKHas4Xj0WeLVE%3DpUQ%40mail.gmail.com.
