Tables

A certificate becomes a revocation candidate by being identified as containing a pwned key. Every revocation candidate is a potential notification, but we only send a notification once per (issuer, key) pair, as issuers should automatically revoke all certificates for a given key once that key has been notified as having been compromised.

Every time an OCSP check is made for a revocation candidate (that is, a certificate which is using a known-compromised key), a record is made for that attempt in this table. As you might expect, things can get pretty big.

Revocation status is checked on a per-candidate basis, rather than on a notification basis, to ensure that issuers are doing the right thing and revoking all certificates that use a key which they know to be compromised, even if a notification for that specific certificate was not received. This is in line with CABF BR requirements.

Emails (attempted to be) sent to issuers to request revocation.

HTTP(S) requests made to provide a pwnedkeys-legacy format PKCS10 attestation of key compromise.

E-mail addresses for CAs to which we can request revocation.

HTTP(S) URL endpoints which will accept a POSTed PKCS10 (CSR) attestation of compromise in the older, pwnedkeys-specific format.

Each (issuer, key) pair gets a single revocation request. Individual attempts to request revocation are recorded in the type-specific tables below. You might think you’d only need one attempt to request a revocation, but systems fail, so we keep a record of every attempt, for evidence of systemic attempts to avoid receive problem reports.

Stores the full OCSP responses received from OCSP servers. This is kept out of the main ocsp_checks table because OCSP responses generally change far less frequently than we make checks, thus saving us a lot of unnecessary disk space by making them a separate table.

The set of issuers that we have contacts for. The “first” certificate in the chain that matches an entry in this table is getting the report.

Provides the most recent successful (ie HTTP response was successful and the OCSP data was successfully validated) for every revocation candidate.

Provides an indication of when a particular OCSP response was first actually seen, which can be quite different from when the response metadata says it was created.

Determine the time at which revocation is considered “published”, which we define as the last time we didn’t get a ‘revoked’ status in an OCSP response for that candidate (so as to give the issuer the benefit of the doubt).

Provides our best estimate of the interval it took for a revocation to be published, based on OCSP response times.

Provides the history of OCSP responses for revocation candidates, with duplicate OCSP responses suppressed so it’s easier to see how an OCSP status changed over time.

Provides a consolidated view of the revocation status of all unexpired revocation candidates. Includes information on how long it took to revoke the certificate, based on the interval between notification and the first OCSP response indicating revocation.