Understanding what the "Incidents" category is for

[petercooperjr]

As somebody who's interested in Let's Encrypt and runs some custom client code, I have subscribed to the "Incidents" category. Most postings in there describe some kind of "misissuance" type incident, where Let's Encrypt "broke the rules" and needs to revoke some certificates, or at least justify why revoking certificates isn't necessary or otherwise explain what happened. There are also occasionally posts about how they aren't affected by a common-to-many-systems vulnerability that they're being asked about frequently, or about an incident response of emergency measures being taken to protect their infrastructure from abuse.

In the last few months, I've noticed that there have been a few incidents that were reported to the Mozilla root program but don't have a post in the Incidents category:

• Certificates issued to Elliptic Curve Debian Weak Keys
• Incomplete and Inconsistent CRLs
• Delayed revocation for removed gTLD

Now, the reason I'm following Let's Encrypt incidents so closely is just because I'm being nosy. But as the Integration Guide suggests that client developers and large integrators only need to follow the "API Announcements" category to learn about updates, I'm trying to learn what the "Incidents" category is for and who should subscribe to it to ensure they see posts in it.

1. Is the expectation that there is only a post in the "Incidents" category if there's a need to have a post from Let's Encrypt specifically to this community, and that (as with those three listed above) if there's no perceived need for this community to be informed that Let's Encrypt will only inform the root programs? (I posted links to Mozilla above because they run their root program in a very open way, but it's my understanding that incidents like those need to be reported privately to other root programs as well).
2. If I'm the subscriber for a certificate being revoked due to one of these "smaller" incidents that don't warrant a post to this community, is there a notification that happens to the email address on file for the account when revocation due to an incident occurs? (And if I don't want to give Let's Encrypt my email address, well that's just on me so I might expect my certificate to be revoked and won't know why unless I look through reports to the root programs.)
3. Should it be recommended for client authors and large integrators to subscribe to the "Incidents" category in addition to the "API Announcements" category, to learn about things like incident response that temporarily disables some issuance that might impact my requests, like what happened with Plesk for a day? Or are those also handled by separately contacting those integrators, so if it's just one integrator it might have a post in "Incidents" (because it's worth noting but the people involved are already aware) but if there's more than one integrator affected it would have a post in "API Announcements" to be more widely spread?

Thanks for indulging my curiosity.

[mcpherrinm]

I think your interpretation in point 1 matches my intuition: It's a place to share with the community about "incidents" that may have broader impact. The three examples of recent ones are compliance issues but we expect to have no impact on the community.

If we had to revoke certificates, we would definitely share with the community in the Incidents category, unless we knew we'd communicated with all subscribers affected (such as was the case with the EC Debian Weak Keys, where we knew who issued it). We're also working on a new API, the ACME Renewal Info api, which will provide information about when certificates may need to be renewed promptly because of pending revocation. We feel that handling revocation via ARI is going to be the best way for large integrators to operate, though it's not quite complete. We usually coordinate with our largest of integrators directly during such incidents mostly to manage our own load, and we hope that ARI can help automate that.

I think a suggestion to subscribe to Incidents is a good idea for operators of clients. We already suggest they subscribe to our status.io page which has availability information. Client authors may want to subscribe as well, especially if they want to understand what their users are going to experience.