The Pwnedkeys Revokinator is back!

[Matt Palmer]

Hi everyone,

As some eagle-eyed CAs may have noticed, I've revamped and restarted the
Pwnedkeys Revokinator, which matches compromised keys from the Pwnedkeys
dataset against issued WebPKI certificates, and sends compromise
attestations to the issuing CAs.

The major change from last time I was running the Revokinator is that I
have no intention of trawling the revocation status information looking
for violations of the BRs. CAs are free to ignore the notifications
that Revokinator sends (as a representative of one CA has hinted may
occur if I don't follow their specific manual processes to generate
evidence in their preferred format), without fear of incident reports
being filed by me.

Instead, I have stood up a site, at https://pwnedkeys.com/revokinator,
that is intended to be the one-stop shop for displaying all of the
information that the Revokinator has about compromised certificates,
compromise notifications, OCSP checks, and so on. Anyone who wants to
trawl that data looking for BR and policy violations may do so, and
create incidents as they see fit. The complete database schema
describing what is being recorded by the Revokinator is available at
https://pwnedkeys.com/revokinator/db-schema.

The current information being displayed is very incomplete, and serves
more as a demonstration of how to write extract/display functions than a
complete dump of available information. The codebase is publicly
available at https://github.com/pwnedkeys/revokinator-site, so if you're
keen to be able to see more of the Revokinator's data, submit PRs.

There is an FAQ about the Revokinator at
https://pwnedkeys.com/revokinator/faq that gives details about how the
Revokinator works, and various other pieces of information that may be
of interest. Of particular note to CAs, there are instructions on how
CAs may receive notifications by means other than email. They may wish
to consider implementing that route in the near future, as at some point
I will be running a script to match the backlog of compromised
certificates and bulk-submit them to CAs, which may put significant load
on whoever sits on the problem report mailbox.

Finally, I don't intend for mdsp to become the Revokinator announcements
list, so if you wish to receive future updates about improvements to the
Revokinator as they're released, I'd suggest subscribing to the
Pwnedkeys newsletter (https://pwnedkeys.com/newsletter/subscribe), where
future announcements will be posted.

- Matt

[Aaron Gable]

Hi Matt,

Thanks for running this important service!

The FAQ points out that the revokinator does not use the standardized ACME method for reporting key-compromised certificates. The reason given is that the ACME method requires the private key to be online to sign a nonce (i.e. to demonstrate, not just assert, compromise), but the revokinator stores private keys offline "for security reasons".

Given that these private keys are already compromised, why is the revokinator's storage solution so important as to preclude implementing the only (as far as I'm aware) IETF-standardized compromise reporting mechanism?

Aaron

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/695ca8fc-a4cd-42cf-b589-de3f3e854727%40mtasv.net.

[Matt Palmer]

On Sun, Nov 10, 2024 at 08:52:49AM -0800, Aaron Gable wrote:
> Thanks for running this important service!
>
> The FAQ points out that the revokinator does not use the standardized ACME
> method for reporting key-compromised certificates. The reason given is that
> the ACME method requires the private key to be online to sign a nonce (i.e.
> to demonstrate, not just assert, compromise), but the revokinator stores
> private keys offline "for security reasons".
>
> Given that these private keys are already compromised, why is the
> revokinator's storage solution so important as to preclude implementing the
> only (as far as I'm aware) IETF-standardized compromise reporting mechanism?

For much the same reason that full-disc isn't the standard way of
reporting software security vulnerabilities. While the keys are
compromised, in the sense that someone other than the legitimate user of
the key has a copy of them, they aren't necessarily universally known to
every bad actor.

Given that I've got keys that have, at times in the past, been for
certificates with sANs like "*.gov.<ccTLD>", I don't feel it is
appropriate to leave those private keys in a centralised location for
any miscreant with a penchant for network interception to grab en masse
and use as they desire. Hence, all private keys are stored offline and
encrypted, in a deliberately not-easy-to-access form.

I shall augment the FAQ to make this more clear.

- Matt

[Job Snijders]

Dear Matt,

On Sun, Nov 10, 2024 at 10:02:43PM +0000, Matt Palmer wrote:
> On Sun, Nov 10, 2024 at 08:52:49AM -0800, Aaron Gable wrote:
> > Thanks for running this important service!

Yes, very cool work.

> > Given that these private keys are already compromised, why is the
> > revokinator's storage solution so important as to preclude
> > implementing the only (as far as I'm aware) IETF-standardized
> > compromise reporting mechanism?
>
> For much the same reason that full-disc isn't the standard way of
> reporting software security vulnerabilities. While the keys are
> compromised, in the sense that someone other than the legitimate user
> of the key has a copy of them, they aren't necessarily universally
> known to every bad actor.
>
> Given that I've got keys that have, at times in the past, been for
> certificates with sANs like "*.gov.<ccTLD>", I don't feel it is
> appropriate to leave those private keys in a centralised location for
> any miscreant with a penchant for network interception to grab en
> masse and use as they desire. Hence, all private keys are stored
> offline and encrypted, in a deliberately not-easy-to-access form.
>
> I shall augment the FAQ to make this more clear.

You seem to take an attentive and careful position on this problem
space.

I read your message as that you consider the compromised keys to be
"not yours to use", which to me seems very reasonable.

Kind regards,

Job

[Amir Omidi]

Trying to understand why signing with these keys is considered full disclosure?

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZzEv2Rhtbf8RuCib%40fast.

[Matt Palmer]

On Sun, Nov 10, 2024 at 06:19:50PM -0500, Amir Omidi wrote:
> Trying to understand why signing with these keys is considered full
> disclosure?

It's not. That's why Pwnedkeys provides a signed-by-the-key attestation
of compromise. Full disclosure would be keeping the actual private keys
online in a central database, which is what is required to use the ACME
revokeCert endpoint.

- Matt