Hi Ben, > Maintain and test mass revocation plans annually, including the revocation of > 30 randomly chosen certificates within a 5-day period.
We believe this part of the proposal will not have the intended effect, and would rather cause annoyance with Subscribers. Let me explain why: Over the years, Sectigo has done several mass revocations. We have procedures in place for handling these in a compliant fashion, and these procedures have worked. For a total of 30 certificates, we would not use our mass revocation procedures; rather, for 30 certificates it’s far more effective to pick a handful of employees to perform manual outreach to customers. Contacting customers directly and personally ensures that they are taking steps to replace each certificate before it is revoked, and it’s do-able for 30 certificates. It’s not do-able for 30,000 certificates. Question: What is this requirement hoping to accomplish? Is it (1) to confirm that CAs have a revocation plan available and tested; or (2) to make sure Subscribers have such a plan in order and are ready for it at any time? If the answer is number 2, we’re very skeptical that it would be successful. Going by https://crt.sh/cert-populations, we’re counting around 1 billion unexpired pre-certificates. Let’s take that as a ballpark number. Based on CCADB records, there’s about 55 distinct CA Owners included in the Mozilla Root Store. 55 times 30 certificates become 1650 revocations per year. That means, as a Subscriber, (ignoring math around which CA Owner I’d use) each of my unexpired certificates would have a 0.000165% chance of being randomly selected for revocation out of all unexpired certificates out there. That chance would further decline if I’d use one of the top 10 CAs based on number of issued certificates. I’m not sure how much that would spur Subscribers to change tactics. Additionally, we feel that several CAs have already shown that they are able to perform mass-revocations throughout the year, in full compliance with the BR mandated revocation deadlines. Wouldn’t it be fairer to only impose this random revocation requirement on those CAs that have actually had delayed revocation incidents? i.e., If a CA hasn’t had a delayed revocation incident in the last 12 months, then they MAY perform any random revocations; whereas if a CA has had a delayed revocation incident in the last 12 months, then they MUST. Regards, Martijn Katerbarg Sectigo From: [email protected] <[email protected]> on behalf of Rich Salz <[email protected]> Date: Friday, 3 January 2025 at 19:22 To: Roman Fischer <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: MRSP 3.0: Issue #276: Delayed Revocation As far as the discussion here seems to go: Revocation within 5 days seems to be more important. I *personally* don't agree but if that's the way things are going to be, then I'm in favor of strict and clear rules. I don't think As far as the discussion here seems to go: Revocation within 5 days seems to be more important. I *personally* don't agree but if that's the way things are going to be, then I'm in favor of strict and clear rules. I don't think the discussion is going that way. Some of us have raised concerns, but most of the messages in the thread have been questions about clarification. -- 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]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFH29triiDQbO%3DF2t5%2BBmDrAVmh%2BbzMydQ4DhgUyOHsE3QbJaQ%40mail.gmail.com<https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFH29triiDQbO*3DF2t5*2BBmDrAVmh*2BbzMydQ4DhgUyOHsE3QbJaQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUlJQ!!J5K_pWsD!yzYN_jsUkRtEnYDiiq56Bl3FogeOzBNFfRJlk5GLWvdAkal2y94taOLFyo6jZhkmUqgFG_uZz2WTxuCq9rSK7GDM$>. -- 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/SA1PR17MB650336E6C98B3D95449337F8E3122%40SA1PR17MB6503.namprd17.prod.outlook.com.
