FWIW, I don't like the approach of random revocations. I would prefer to focus on re-issuance and certificate rollover exercises by each CA, providing statistics of how subscribers perform, without any real disruptions. Instead of selecting certificates for revocation, select certificates for re-issuance and rollover in 5 days.
DZ. Dec 23, 2024 13:30:45 Rich Salz <[email protected]>: > Yes i know. The key point is to not DoS customers, so do what you have to > make sure they have certs before the revocation experiment. > > On Mon, Dec 23, 2024, 1:32 AM Dimitris Zacharopoulos <[email protected]> wrote: >> Hi Rich, >> >> The CA cannot issue a replacement certificate if the Domain and/or Identity >> Validation reuse period has expired. >> >> Some CAs even choose to request fresh domain validations at every issuance. >> >> DZ. >> >> Dec 19, 2024 22:24:31 Rich Salz <[email protected]>: >> >>>> I think it would be advisable for a CA operator’s mass-revocation testing >>>> plan to include an immediate notice to all customers whose certificates >>>> were randomly selected because we would want to minimize disruption to >>>> server operations while testing the CA’s ability to revoke and replace >>>> certificates promptly. >>>> >>> That's not quite the question I was asking. I said "pre-notify". Imagine a >>> timeline like this: >>> N pick enough certs randomly. Generate replacement certs for those being >>> revoked. >>> N+1 notify those customers they will be revoked ("this is a test of the >>> emergency broadcasting system" as it were) and that you have replacement >>> certs >>> N + 1 + x Do the revocation >>> >>> Would that be valid? If not, then as a reasonably large subscriber, I think >>> Akamai would expect to have a cert in the mass-revocation plan, and if we >>> have to respond at incident speed so that our customers are not impacted by >>> such a test, we would probably take that into consideration about which CAs >>> we use. >>> >>> -- >>> 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/CAFH29trVcYUbbWCE722Qu8qECvG%3DBBS9MswpK6%2B3YVQRAhnC2A%40mail.gmail.com[https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFH29trVcYUbbWCE722Qu8qECvG%3DBBS9MswpK6%2B3YVQRAhnC2A%40mail.gmail.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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/cc416f25-c483-49ec-ac8a-2ad2b0d81f0c%40it.auth.gr.
