Dear Matt, >In general, anything that does not get exercised regularly tends to atrophy, >and so when it turns out to be needed, it does not perform as well as would be >hoped.
I agree. However, as far as I remember at least the delayed revocations in the past 1-2 years were not due to CAs incapability to do mass-revocation but due to CAs believing that weighing customer's claims of negative effects of revocation against complying to the mandatory revocation times was acceptable (I'm not in the industry long enough to say if at any previous time such weighing was accepted by root store operators or the community). IMHO, the problem is not the mass-revocation but the believe that delayed revocation -might- be acceptable under certain circumstances. >That's why I support random revocation requirements for *all* CAs -- because >it is practically axiomatic that all CAs' systems will be less-than-perfect, >with problems that have lain dormant, and are only identified by real-world, >end-to-end testing. And that's even before we start considering the >subscriber-level problems out there... If testing CAs mass-revocation process is the goal, then we could just put a requirement in the BRs. Auditors would then check if CAs did mass-revocation tests. Such tests don't have to be done on productive public trusted certificates to prove that the process works. 😊 Kind regards Roman -- 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/ZR0P278MB01702E0C3A32E78064104C91FA1C2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.
