Dear everybody, >Point 3 is unusual as revocation for compliance reasons is explicitly >outlined, and that's all that this is? There isn't any new changes to the >legal language required that I can see.
I checked with our legal department and they clearly stated that we will have to amend the contracts if we want to be sure that we can't be sued for damages inflicted by random revocation. Current language (at least in our contracts) allows us to revoke in case of security incidents, non-compliance and some other cases. But a preventative revocation would currently not be covered. Also, I'm not convinced that it will motivate many customers towards automation. Most will probably just gamble and bet on not being in the unlucky 30, especially if they get their certs from a large CA... 😉 >Point 4 has been covered, being above the baseline requirements is barely >noteworthy but encouraging these practices in more programs is good advice. Regarding a comment made in another mail, I think it's fair to say that most public trust CAs -need- to conform to all major root store policies to be of any value for their customers. The more fragmented these root store policies are, the more complex (and error prone!) complying to them becomes. For this reason, we would really encourage the root store operators to converge on requirements set forward. Kind regards Roman On Wednesday, December 18, 2024 at 5:53:51 PM UTC Jeremy Rowley wrote: 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]<mailto:[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]<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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c2290409-2ef1-4295-8f5d-13369f2dbbe1n%40mozilla.org<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c2290409-2ef1-4295-8f5d-13369f2dbbe1n%40mozilla.org?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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170A7308388003F18AB8AB6FA062%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.
