Hi Jeremy. I think it's unreasonable to expect the browser representatives and the community to always be ready to respond to incident reports within 24 hours. I also think that it would be a very sad state of affairs for the BRs and Mozilla policy to have mutually exclusive requirements. And I also think that it makes no sense to prevent CAs from responding promptly to confirmed "security incidents" (e.g., proven key compromise, evidence from a reputable third party that a misissued certificate's private key is controlled by an attacker, etc).
In all other cases, where the CA is not able to confirm a "security incident", I think I could be persuaded that it's not unreasonable to require a >=24hr subscriber notification period prior to revocation. ________________________________ From: Jeremy Rowley <[email protected]> Sent: 30 December 2021 18:24 To: Rob Stradling <[email protected]>; Kathleen Wilson <[email protected]>; [email protected] <[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. In that case, couldn’t you just include that you revoked the certificate before notice as part of the incident report you are already required to file for failing to properly do validation? In this scenario, you’re already filing an incident report so combining the two misses on a report doesn’t seem burdensome. Plus, if you’re filing incident reports promptly, then the browsers can provide guidance on their expectations to revoke before the 24-hour notice or not. Then, the decision on when to revoke is partly a community-driven decision rather than something the CA is unilaterally deciding. From: [email protected] <[email protected]> On Behalf Of Rob Stradling Sent: Thursday, December 30, 2021 11:09 AM To: Kathleen Wilson <[email protected]>; [email protected] Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates > "When a certificate revocation is not due to key compromise and is not > initiated by the certificate subscriber, the CA MUST make the information > regarding its intent to revoke an end-entity SSL certificate available to the > certificate subscriber at least 24 hours before revoking the certificate." What if the certificate revocation is due to the CA becoming aware that validation (particularly DCV) was not performed correctly? In such cases, it's possible (perhaps even likely) that the private key is controlled only by an attacker; and since that private key hasn't been obtained by parties that the subscriber (i.e., the attacker) has not authorized, the key is not compromised. As with key compromise, waiting 24 hours in this scenario only helps the attacker. ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Kathleen Wilson <[email protected]<mailto:[email protected]>> Sent: 30 December 2021 17:44 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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. Many thanks to all of you for your continued input. I have updated the first sentence of the second paragraph of the draft<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%7Cd10f017744394c3804f608d9cbc19958%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764854642365017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JUlKuiG5Nn5zTTslhAaHaAJ8zxsywUcTO%2FoQMXcto90%3D&reserved=0> to the following, and will continue to appreciate your help with the wording. My intent is to provide some protection to the website operator so that a CA cannot revoke their certificate for non-critical reasons without letting them know and take action first. The responsibility may be on the website operator to have automation to check for that information, as opposed to sending notifications via email. So I will continue to appreciate your help with the wording. "When a certificate revocation is not due to key compromise and is not initiated by the certificate subscriber, the CA MUST make the information regarding its intent to revoke an end-entity SSL certificate available to the certificate subscriber at least 24 hours before revoking the certificate." I am particularly interested in having more discussion about the following from Rob: On Thursday, December 30, 2021 at 8:37:07 AM UTC-8 [email protected]<mailto:[email protected]> wrote: 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. How do you all think that browsers should enforce end-entity TLS certificate revocations? e.g. Should ALL end-entity TLS certificate revocations be enforced via non-over-rideable errors? Or should the user be able to continue past the error to the website when the revocation is for something other than key compromise? Should a non-over-rideable error be presented for end-entity TLS certificates that are revoked for privilegeWithdrawn? Should a non-over-rideable error be presented for end-entity TLS certificates that are revoked for cessationOfOperation? Should a non-over-rideable error be presented for end-entity TLS certificates that are revoked for superseded? We all know that if user gets a non-over-rideable error in one browser they will try again with another browser, so enforcing any revocations in only one browser will not be very effective in protecting the user. So I am looking for a solution that may be more broad than Firefox, with the hopes that other browsers will be able to eventually use the revocation reasons for end-entity TLS certificates too. I am under the impression that other browsers will not enforce ALL end-entity TLS certificate revocations with hard fail, and that the rules about the use of certain revocation codes must be in place and in use before they will consider automatically enforcing via hard fail any end-entity TLS certificate revocations. Thanks, Kathleen -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[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/fb3a0850-cd60-4c53-8c72-095ad4ade8b7n%40mozilla.org<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2Ffb3a0850-cd60-4c53-8c72-095ad4ade8b7n%2540mozilla.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7Cd10f017744394c3804f608d9cbc19958%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764854642365017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HvCyu%2BbpM8CqZy8VxQ9IuQfHhE283PPF9g%2F1XCeOxUs%3D&reserved=0>. -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[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/MW4PR17MB47295DE63653156956A1018EAA459%40MW4PR17MB4729.namprd17.prod.outlook.com<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FMW4PR17MB47295DE63653156956A1018EAA459%2540MW4PR17MB4729.namprd17.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7Cd10f017744394c3804f608d9cbc19958%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764854642365017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5F5ltkDLYf8iUBeuSesbLtz%2FcoxFEPvbPZnSKBAsjZ0%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/SJ0PR17MB4726D9863885333E4119AF7CAA469%40SJ0PR17MB4726.namprd17.prod.outlook.com.
