To expand on my position: If the concern is letting the subscriber (me) know about the revocation so I can mitigate the issue, then sending me an email is useless. I'm sometimes entirely offline for weeks at a time, so any recovery needs to be fully automated, or it won't happen. Adding a contact email address would therefore be busywork, as any emails wouldn't reach me in time to anything about the issue anyway.
I already have automated recovery if OCSP informs me of revocation (integrated with OCSP stapling to avoid most downtime), and the ACME Renewal Information (ARI) draft seems promising to avoid potential downtime entirely. As such, I'd prefer it if I didn't have to do the busywork of providing an email address or other contact info, and I'm hoping something like ARI could serve as an acceptable means of notification. Thanks, Sam On Wednesday, December 29, 2021 at 3:08:30 PM UTC-8 [email protected] wrote: > Kathleen and Sam, comments inline: > > On Wed, Dec 29, 2021 at 2:11 PM Kathleen Wilson <[email protected]> > wrote: > >> 1) The first sentence of the second paragraph has been changed to make my >> intent more clear, and I added a comment that we will need to determine an >> effective-date because this means code changes (e.g. ACME). >> >> "When a certificate revocation is not initiated by the certificate >> subscriber, the CA MUST notify the certificate subscriber about its intent >> to revoke the end-entity SSL certificate at least 24 hours before revoking >> the certificate." >> >> I am open for feedback on wording and the time frame (e.g. 24 hours), and >> I will also appreciate thoughts about the effective-date for this new >> policy. I intend to require that CAs notify certificate subscribers before >> revoking their certificates, because when certificate revocation is >> enforced by the browser the CA can essentially cause DOS for websites. >> > > To the best of my knowledge, this requirement phrased as-is is impossible > to comply with. BRs Section 4.9.1.1 says "The CA SHALL revoke a certificate > within 24 hours if... [t]he CA obtains evidence that the Subscriber's > Private Key... suffered a Key Compromise". This has uniformly been > interpreted to mean "within 24 hours of the key compromise report being > filed", not "within 24 hours of receiving the report" let alone "within 24 > hours of deciding that the report is legitimate". Since there must > necessarily be some amount of time between receiving the report and > deciding to revoke -- even on the order of milliseconds for an automated > ACME revocation, but still -- a CA cannot notify the subscriber *more* than > 24 hours before the revocation *and* revoke the certificate *less* than > 24 hours after receiving the report. At the very least, this notification > period must be reduced in order for a CA to comply both with it and with > the existing BRs. > > On a broader basis, though, I'm curious what the purpose of this proposed > requirement is, and whether there is a better way to satisfy that goal. > > In particular, updating an ACME CA to abide by the spirit of the proposed > requirement (i.e. send an email, not provide notification via some other > mechanism) means not just updating ACME Server software to send > notifications: it means every ACME Subscriber updating their client > configuration to provide an email address. An ACME CA could update to > reject account registrations that don't include email addresses, and could > even deactivate all existing accounts that don't have notification > addresses, but this would result in those ACME Clients continually failing > issuance until their configuration is *manually* updated to include an > address... or until the client itself is updated to provide a > fake/meaningless/blackhole address (and as Sam comments, many subscribers > do not want to provide an address at all). Neither of those seems like a > win for the ecosystem, to me. > > So is there another way to think about the purpose of this proposed > requirement, what situations it is meant to prevent, and whether those can > be more precisely targeted? > > On Wed, Dec 29, 2021 at 2:54 PM Sam H <[email protected]> wrote: > >> As a subscriber, I would prefer not to be required to provide an email to >> get a certificate. As such, would it be acceptable to allow polling an >> endpoint to get the revocation status? I already monitor OCSP for my >> domains, so I am already notified of revocations without the need for an >> inbox. >> > > One downside of the "poll an endpoint" approach is that, as you note... > well, it's kinda like OCSP. And if a CA publishes "hey, I'm going to revoke > this cert in the next 24 hours", why should anyone trust that cert during > that 24 hours either? This is why I'm trying to examine the intended > purpose of the requirement overall, not just the details of one particular > implementation of it. > > Aaron > -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ec7ff5d0-ac6c-4685-8978-333d888e0047n%40mozilla.org.
