Why limit it to only those reasons requiring 24 hours? It certainly addresses the immediate incompatibility, and so I’m very supportive of that approach, but my worry is that we’ll still CAs getting confused about the requirements. In particular, imagine the scenario where an incident report comes in for those in the 5 day scenario, and the CA requires time to investigate. The 24 hour notice requirement creates a similar catch-22 for CAs, as it reduces their available time to respond to 4 days. That’s because either they need to give 24 hours notice (to comply with Moz policy), or need to ensure they revoke within 5 days (to comply with the BRs). The only way to meet both requirements is for all of the 5-day reasons in 4.9.1.1 to effectively be treated as 4 days.
Of course, exempting all of 4.9.1.1 alone may not be appropriate, at least for the abuses imagined by “inappropriate” revocation, because it currently contains several areas left up entirely to CA whim and fancy. For example, “misuse” is something entirely defined by the CA, so any CA that wanted to be exempted from a notification requirement could liberally define misuse to whatever they wish. Similarly, the Subscriber Agreement/Terms of Use clause can contain any reason imaginable (e.g. “the CA will revoke for any reason it sees fit”), and that can similarly cause issues that notification may be trying to mitigate or ameliorate. So I recognize my suggestion has flaws that would need to be worked through, but so do the current proposals here, both by Kathleen and by passerby184. I definitely agree with Rob that it’s worth exploring the reasons/goals for this change. I’m skeptical that the proposed notice requirement will do anything to help other browsers get to a hard-fail situation, so if that’s the primary goal, it may be worth stepping back, both to examine if that is a worthwhile goal in itself, and look at possible ways to achieve that. One serious shortcoming of the revocation methods, in general, is that they are CA mediated. Both new and long-standing participants on this list are undoubtedly familiar with just how many CA incidents we regularly see, and in violations of things that are surprising, if not outright unconscionable, in the CAs’ explanations for them. That’s not to say any disagreement or misunderstanding of requirements is an indelible black mark on CAs, or even that they’re all unreasonable, but there certainly have been some events, even in the past year, that are egregious in their misunderstanding that borderline on “willful noncompliance”. CA revocation simply exacerbates this asymmetry, in which the goals of the user agent are misinterpreted, or misimplemented, by CAs that (understandably and reasonably) have their own motivations and priorities. We see some CAs callously and knowingly violating the BRs, because they want to advantage their customers (site operators) at the risk of users, and revocation is a natural extension of that misalignment. That is, some CAs want to avoid revocation for mistakes they make, because it annoys their customers and (rightfully) harms their reputation, but want to promote revocation for areas where it advantages them (e.g. revoking certs for a customer if that customer gets any cert from another CA, or if the customer fails to pay additional balloon fees based on volume, or monthly “rentals”, etc). If the goal of revocation is to protect users, particularly in scenarios where the site operator is actively interested and supportive of that, such as key compromise, while discouraging abuse by others, such as CAs, doesn’t it make sense to have the user agent be the means of accomplishing that? Equally, when considering government compulsion for revocation, which may not respect the rule of law or the rights of site operators, doesn’t it make sense for the user agent to be able to both advocate for and defend the rights of server operators, such as ensuring such demands are legitimate and respect the rights of users and site operators? Similarly too, what about the risk of (other) root stores using contractual obligations to compel revocation by CAs in their program, which has a knock-on effect of effectively propagating that policy to all (other) root stores? Concretely, one way to accomplish this would be that, rather than defining the set of reasons that a CA may use, and trying to filter or special case that, what if the user agent provided a means (e.g. through some integration with, or system maintained similarly to, CCADB), which would allow for site operators to request revocation be propagated through to browsers, with the logic being that the browser first checks if the CA has done the revocation. Effectively, a two-phase commit system to allow both the CA, and the UA, to validate the legitimacy of the revocation request. There are undoubtably shortcomings here as well - for example, if a third-party demonstrated key compromise to the CA, the site operator may not be interested in having revocation propagated, so it’s by no means a fully fleshed out proposal, although one can easily imagine possible solutions, like the CA delivering that proof to this hypothetical system. But for the scenarios of CA-forced revocation, or things like “someone sent a government-like looking letter for which the CA has no time, skill, or interest in actually validating”, this would allow the user agent to act on their behalf. Conceptually, just as CT functions as a form of counter-signing, in which CAs aren’t trusted to issue certificates unless they have been witnessed by public logs, thus legitimizing the issuance, this functions as a form of counter-signing for revocation. Unlike past (somewhat misguided) proposals for “revocation transparency”, which largely seek to simply make a commitment to revocation without being able to distinguish, or validate, the decision making, this tries to add a counter-party (or counter-parties) to make sure the revocation itself is legitimate and aligned with the needs and goals for the UA. This is, however, further separate from the question of soft-fail vs hard-fail for revocation. I realize during the earlier discussion of revocation, as it applies to Mozilla, the technical role of revocation as it works for Web technologies was explicitly excluded, and I do want to respect that. However, I do believe that a meaningful discussion of soft-fail vs hard-fail, for any reason (including key compromise), would necessarily have to include that, since it may be another area of philosophical differences that are key to understanding the present situation. On Fri, Dec 31, 2021 at 7:04 AM Rob Stradling <[email protected]> wrote: > > why not just exempt pre-notice when required by BR 4.9.1.1 > > I think this is an excellent idea. > > Kathleen, here's a suggested re-wording: > *"Unless revocation within 24 hours is required in order to comply with > section 4.9.1.1 of the CA/Browser Forum Baseline Requirements, 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."* > > ------------------------------ > *From:* [email protected] <[email protected]> > on behalf of passerby184 <[email protected]> > *Sent:* 31 December 2021 03:35 > *To:* [email protected] <[email protected]> > *Cc:* Jeremy Rowley <[email protected]>; Rob Stradling < > [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. > > 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%7C61aa88a284524f3376c908d9cc0e8bd4%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637765185129566247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pckxJvKbFFEXDFEBhPm%2BvMQvHeGlrCFUyZ9TivqVXO4%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%7C61aa88a284524f3376c908d9cc0e8bd4%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637765185129566247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gFUiAcoiToBZ1rF5rLiKOK73dAvMB%2BbbkcZA0SU17fs%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://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%7C61aa88a284524f3376c908d9cc0e8bd4%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637765185129566247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DSIvFcKg3NlnLN6EgQiTbaRTKAdrhTVK5nGQJD0OPlY%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/af9bb75f-d629-4e3f-bda9-f56ee4b7b9d8n%40mozilla.org > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2Faf9bb75f-d629-4e3f-bda9-f56ee4b7b9d8n%2540mozilla.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7C61aa88a284524f3376c908d9cc0e8bd4%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637765185129566247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ki2pywEPEXXrNLj%2BDdn%2FPjwbwHz3rIDGbBIV7%2FqIo2Y%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/MW4PR17MB4729B3D46782AD07856E77F2AA469%40MW4PR17MB4729.namprd17.prod.outlook.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB4729B3D46782AD07856E77F2AA469%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/CAErg%3DHGSkc50KYCnBseoQJidnaCxX%2BnX77Zm2XDQE69LdRVcog%40mail.gmail.com.
