I can understand why the keyCompromise and cACompromise reason codes are of interest, but I'm struggling to see why Mozilla might be interested in differentiating between privilegeWithdrawn, cessationOfOperation, and superseded. Why are any of these 3 reason codes more useful than having no reason code at all? What use cases would be enabled if CAs were to use these 3 reason codes as you propose?
FWIW, at the moment my counter-proposal would be roughly along these lines (for leaf certificate revocations): - CAs MUST use keyCompromise for (and only for) proven or suspected key compromise. - CAs MUST revoke immediately in the case of proven key compromise. - CAs SHOULD NOT use other reason codes. - Beyond that, follow the BRs. ________________________________ From: Rob Stradling <[email protected]> Sent: 30 December 2021 16:09 To: Kathleen Wilson <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; Matt Palmer <[email protected]> Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates Hi Kathleen. The aspect of this proposal that most concerns me is the idea that after receiving proof of key compromise a CA MUST wait at least 24 hours before revoking the corresponding certificate(s). Whilst this delay would certainly benefit an attacker who has a copy of the compromised private key (because their window of opportunity is enlarged), ISTM that this delay is most certainly not the best outcome for either the server operator or the relying parties. IMHO, DOS'ing the website is better than enabling a false sense of security. By way of analogy (albeit a fairly extreme analogy), imagine if it had just been discovered that the Golden Gate Bridge had become structurally unsound and was likely to collapse at any moment. To avoid inconveniencing commuters that didn't receive prior warning to make alternative travel plans, should we wait 24 hours before closing the bridge? Or should we close the bridge immediately, to ensure no loss of life? If a Subscriber has failed to protect their private key, then they've probably failed to uphold the terms of the Subscriber Agreement. Why shouldn't the CA be permitted to revoke immediately? ________________________________ From: [email protected] <[email protected]> on behalf of Kathleen Wilson <[email protected]> Sent: 29 December 2021 22:11 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; Matt Palmer <[email protected]> Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thank you to those of you who have provided more feedback. I have updated the draft policy text here: https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3LT%2FaeXApN1PCwUYyZ3w%2FeYkgS6%2Bz4D84DyGgtob0Vs%3D&reserved=0> I highlighted the changes in the document, and below is a summary of the changes. 1) The first sentence of the second paragraph has been changed to make my intent more clear, and I added a comment that we will need to determine an effective-date because this means code changes (e.g. ACME). "When a certificate revocation is not initiated by the certificate subscriber, the CA MUST notify the certificate subscriber about its intent to revoke the end-entity SSL certificate at least 24 hours before revoking the certificate." I am open for feedback on wording and the time frame (e.g. 24 hours), and I will also appreciate thoughts about the effective-date for this new policy. I intend to require that CAs notify certificate subscribers before revoking their certificates, because when certificate revocation is enforced by the browser the CA can essentially cause DOS for websites. 2) Per the feedback from Wendy (here<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fg%2Fdev-security-policy%2Fc%2FCls1b2iuOLU%2Fm%2F-wAFl43kCwAJ&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LI%2Bx9n6ByrRqE4yc%2FSfgtzSXLQT9C7Ajp%2BIC8hbXSV8%3D&reserved=0>) I replaced "affiliationChanged (3)" with "cessationOfOperation (5)" in the proposed text, because despite the previously referenced document<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fprevious-versions%2Ftn-archive%2Fcc700843(v%3Dtechnet.10)&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZIKRh4n3bJ%2B0JJnwx%2B4nSRBL9Upq7t7O4otOUuDsFuI%3D&reserved=0> about revocation reasons, I agree with Wendy that cessationOfOperation makes more sense in regards to a TLS certificate no longer being needed because the website it was used in has been taken down or the certificate subscriber no longer owns the domain name(s) in the certificate. Whereas affiliationChanged seems to be about how a person is associated with an organization. So the "affiliationChanged (3)" paragraph has been replaced by the following. "cessationOfOperation (5) The CRLReason cessationOfOperation (5) MUST be used when the subscriber has requested that their certificate be revoked for this reason, or the CA has received verifiable evidence that the subscriber no longer owns the domain names in the certificate and there is no evidence of a private key compromise. Otherwise this CRLReason MUST NOT be used. The CRLReason cessationOfOperation (5) is intended to be used to indicate that the subscriber no longer owns the domain names in the certificate or will no longer be using the certificate. For example, this revocation reason should be used if the website with the certificate is shut down prior to the expiration of the certificate." I will continue to appreciate your input on this draft proposal. 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/985030a9-d162-4102-8724-adeec29be6ean%40mozilla.org<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F985030a9-d162-4102-8724-adeec29be6ean%2540mozilla.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7Cc152517698e546edcdaf08d9cb1832ef%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764127082851878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r0rPLLiPhXZvekbtXkCr11BP1%2BPOOE82kGRiM19aZZg%3D&reserved=0>. -- 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/MW4PR17MB4729316EB1EC6116BE6A982BAA459%40MW4PR17MB4729.namprd17.prod.outlook.com.
