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 From: Kathleen Wilson <[email protected]> Sent: Tuesday, February 1, 2022 1:04 PM To: [email protected] Cc: Ryan Sleevi <[email protected]>; Doug Beattie <[email protected]> Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates I have re-written the bright green text in the draft policy <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing> to separate out the scope of revocation from the requirement to use the keyCompromise reason. So the proposed text is as follows: == 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 has previously demonstrated or can currently demonstrate possession of the private key of the certificate, then the CA MUST revoke all instances of that key across all subscribers. - 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. == I will continue to appreciate your feedback on this, and especially your input on how to make this more accurate. 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/TYZPR03MB613555E8980F4C557F9402BFF0269%40TYZPR03MB6135.apcprd03.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
