I agree with point number 2. I think Mozilla should just make it clear delayed revocations are not permitted and call it good. This is the only industry I know where we'd propose breaking availability in the CIA triangle just in case integrity might be compromised. Better to pull off the band-aid and, assuming we really like 5 day revocations, either a) require that companies use ACME to deploy certificates or b) simply state that CAs delaying revocation past 5 days will likely be distrusted.
On Wednesday, December 18, 2024 at 10:17:46 AM UTC-7 Ben Wilson wrote: > All, > > As part of the discussions on this proposal, namely that CAs “maintain and > test mass revocation plans annually, including the revocation of 30 > randomly chosen certificates within a 5-day period,” I’ve received a few > comments via private channels, and to ensure transparency and foster > discussion, I am sharing them here anonymously: > > 1. “Mozilla does not grant exceptions…” -- this is the most important > signal that Mozilla can provide. > > 2. If certificate consumers want to prohibit delayed revocation, then they > need to make it clear to CAs that they won't accept it and that they will > kick them out of the root stores if they still do it. Don't try to solve > this issue with indirect measures like random revocations. Just be straight > about it and make it clear that there will be consequences for the very > first delayed revocation and onward. > > 3. We will face big problems in revoking productive customer certificates > just to test our mass-revocation plan and procedures. Our current customer > contracts do not foresee this. While we can revoke at any time for security > or compliance reasons, this authorization should not be used just to test > mass-revocation. This will also require us to push out contract changes to > our complete TLS customer base, which will take a considerable amount of > time and effort. > > 4. This part of the proposal should occur within the CA/Browser Forum > through amendments to the TLS Baseline Requirements, and not via Mozilla > Root Store Policy. > > 5. Why was the number 30 chosen as a sample? Some CA operators issue very > few certificates, while some CAs issue millions of certificates. > > I welcome your feedback on these points, the random sampling proposal, and > any others. > > Thanks, > > Ben > On Monday, December 16, 2024 at 3:02:35 AM UTC-7 [email protected] wrote: > >> Hi Ben, >> About " annual plan testing by revoking 30 randomly chosen certificates >> within a 5-day timeframe; and"... >> We understand that this mean that a CA will need to randomly revoke 30 >> certificates that most likely don't have other reason for being revoked >> than being randomly chosen and customers will just need to "happily" accept >> the situation... Harsh, but doable... >> >> About "audit report submitted under section 3.1 SHALL include an >> attestation that the CA operator has met these mass revocation planning >> requirements", it must be considered that the attestation letters of >> Webtrust audit reports have a fixed format, so such addition would be added >> most likely as a "Other matters" section, that audits can take each >> differently. >> >> My question here would be if you think it's there any chance that these >> requirements become part of the TLS BRs instead of the Mozilla Policy, I >> see several benefits here: >> - Checking the mass-revocation plan would be integral part of the audit >> scope, so auditors don't need to figure out how to include it in the >> reports... it just needs to be added to the audit criteria. >> - The "inverse-lottery" thing could be added in the revocation timelines >> of the BR, so there's an entry in the 5-day deadline adding a new category >> "The certificate has been randomly chosen for revocation during an internal >> audit". This should facilitate the contractual language to add in the >> subscriber agreement. >> >> El domingo, 15 de diciembre de 2024 a las 21:51:43 UTC+1, Ben Wilson >> escribió: >> >>> All, >>> >>> The purpose of this email is to start discussion of Mozilla GitHub Issue >>> #276 <https://github.com/mozilla/pkipolicy/issues/276> ("Address >>> Delayed Revocation"). We would like to collect comments and feedback on a >>> proposal to address delayed certificate revocation from a Mozilla >>> perspective. It builds on prior discussions and feedback regarding delayed >>> revocation, and the proposal is meant to replace guidance currently >>> provided on the Mozilla CA wiki >>> <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation>. >>> >>> Here is the comparison link for a proposed new section 6.1.3 in the MRSP: >>> >>> >>> https://github.com/mozilla/pkipolicy/compare/51b2f702accd54cb70d52081a9e814298433495b%E2%80%A6efa8ac40ac341fb813620938ef72328a53858038 >>> >>> >>> *Summary* >>> >>> Here are the highlights of the proposal: >>> >>> >>> - Revocation must occur promptly in compliance with the timelines >>> set in section 4.9.1 of the TLS Baseline Requirements (TLS BRs). Mozilla >>> does not grant exceptions to these timelines. >>> - New CA Obligations: >>> - Educate subscribers on revocation timelines and discourage >>> reliance on certificates in systems that cannot tolerate timely >>> revocation. >>> - Include contractual language requiring subscriber cooperation >>> with revocation timelines. >>> - Maintain and test mass revocation plans annually, including the >>> revocation of 30 randomly chosen certificates within a 5-day period. >>> - Beginning April 15, 2026, CA audit reports must attest to >>> compliance with the mass revocation planning requirements. >>> - Delayed revocation incidents must be reported per version 2.1 of >>> the CCADB's Incident Reporting Guidelines (as currently proposed >>> <https://github.com/mozilla/www.ccadb.org/pull/187>) >>> - Repeated delayed revocation incidents will result in heightened >>> scrutiny or sanctions, which may include root removal. >>> >>> *Background* >>> >>> Earlier this year, on this list, I proposed an Interim Policy to >>> Address Delayed Revocation >>> <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/hXr43W3c4Gs/m/J1OAktIaAwAJ>. >>> >>> While the proposed interim policy provided clarity, it faced criticism >>> regarding implementation complexity, burden on subscribers and CAs, and the >>> feasibility of associated measures, such as transitioning delayed >>> revocation domains to 90-day certificates. Also, there were subsequent >>> proposals aimed at reducing certificate lifetimes and encouraging >>> automation. See e.g. https://github.com/cabforum/servercert/pull/553. >>> >>> This new proposal drops proposed measures such as domain-specific >>> tracking and subscriber attestations and instead focuses on subscriber >>> education, mass revocation preparedness, and robust incident reporting >>> as the primary mechanisms for improving agility and transparency regarding >>> delayed revocation. >>> >>> If adopted, the proposed MRSP § 6.1.3 would replace the current guidance >>> on delayed revocation in Mozilla’s wiki and ensure consistency with the >>> CCADB's Incident Reporting Guidelines. >>> >>> I welcome your feedback on this draft proposal. Please share your >>> thoughts, questions, or concerns to help us refine and improve it further. >>> >>> Thanks, >>> >>> Ben Wilson >>> >>> Mozilla Root Store >>> >> -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f67eb297-826e-4f2b-b511-3a0b90dc8f04n%40mozilla.org.
