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/CAEmnErfC-sZmhMSaN6Oueth5OWTeCnAqiV72xLYDPe77U%3DWWqA%40mail.gmail.com.
