Updated to: "When a certificate revocation reason is not keyCompromise (1) as described below and the revocation 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."
not sure adding a rule with expectation of it will be broken regularly is good idea. why not just exempt pre-notice when required by BR 4.9.1.1 as it will surely collide? 2021년 12월 31일 금요일 오전 3시 24분 23초 UTC+9에 Jeremy Rowley님이 작성: > 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] <[email protected]> on behalf of > Kathleen Wilson <[email protected]> > *Sent:* 30 December 2021 17:44 > *To:* [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. > > > > 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%7C7abdcdf56ed64288a38b08d9cbbbfbf1%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764830522508312%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=y6YZIEIwOayKPMcQ9xU7ZDCvDk21XNma9HqZdyk4ljM%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] 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]" 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/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%7C7abdcdf56ed64288a38b08d9cbbbfbf1%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637764830522664525%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EGY90PhIP9NUzhXF7aim4TbgE6uQ3G92j%2FNuKkLKdc8%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/MW4PR17MB47295DE63653156956A1018EAA459%40MW4PR17MB4729.namprd17.prod.outlook.com > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB47295DE63653156956A1018EAA459%40MW4PR17MB4729.namprd17.prod.outlook.com?utm_medium=email&utm_source=footer> > . > -- 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/af9bb75f-d629-4e3f-bda9-f56ee4b7b9d8n%40mozilla.org.
