Subject: [Acme] Revocation via ACME using pre-signed artifact

From: Matt Palmer <[email-masked]>
Date: Fri, 19 Jun 2020 09:21:36 +1000

Hi everyone,

A corner case of the ACME protocol for certificate revocation by proving
possession of the private key is that the private key needs to be available
to the client which is performing the revocation request.  In some cases,
this is not possible and/or practical, leading to a situation in which
entirely valid revocation requests cannot be processed via ACME, and need to
be handled via some other mechanism.

The specific use case I have in mind is for revocations for key compromise
which are carried out by the Pwnedkeys Revokinator, which is a service I run
to request revocation of certificates using keys known to the pwnedkeys.com
database as being compromised.

When pwnedkeys finds a compromised key which is used in an existing
certificate, it is possible to use the key to request revocation via the
existing ACME-provided mechanism.  However, it does happen on occasion that
a certificate is issued for a key which was already in the pwnedkeys
database, and that causes a problem.

For security reasons, the private keys themselves are not kept online.  Only
a proof of compromise (a JWS and CSR whose content states clearly that the
key is compromised) is available to the public Internet.  As a result, the
Revokinator cannot execute an ACME revokeCert request, because it doesn't
have access to the private key to sign the JWS.  At present, that means that
the only solution I have is to e-mail the CA and request that they manually
revoke the certificate in question, using the CSR as proof of compromise.

Another use case I can think of is analogous to the PGP concept of a
"revocation certificate".  Consider the case where, for whatever reason, an
ordinary user of an ACME CA loses access to the private key used in a
certificate or ACME account, and wishes to notify the CA that the key should
no longer be trusted.  While it is possible to deactivate an account if you
have the private key, you cannot do so if the keys have been abstracted and
then destroyed -- say, in a randomware+blackmail attack, which are, sadly,
all too common.

For these reasons, I'm interested to know if the ACME WG would be willing to
consider adopting a draft specifying a protocol mechanism which extended
ACME to allow a revocation request to be submitted which did not require
immediate access to the private key being revoked.  I don't have a document
prepared, however I've considered the possible mechanisms extensively
through my other work in demonstrating key compromise, and would be willing
to put in the time to write a "pre-draft" for consideration if the WG
expressed in-principle support for adoption.

Thanks,
- Matt

---

From: Jannis Pinter <[email-masked]>
Date: Fri, 19 Jun 2020 07:15:31 +0200

Hi Matt,

> then destroyed -- say, in a randomware+blackmail attack, which are, sadly,
It is not strictly necessary to hold either the account key which was
used to issue the certificate or the private key belonging to the
certificate.

According to section 7.6:
>    Before revoking a certificate, the server MUST verify that the key
>    used to sign the request is authorized to revoke the certificate.
>    The server MUST consider at least the following accounts authorized
>    for a given certificate:
> 
>    o  the account that issued the certificate.
> 
>    o  an account that holds authorizations for all of the identifiers in
>       the certificate.

That means, you can create a new ACME account and get all the
authorizations verified for all the identifiers present in the
certificate, which then allows you to revoke every certificate with
these identifiers. So the use case where all the private keys are lost
forever is already taken care of by the protocol.

Regards,
Jannis

---

From: Matt Palmer <[email-masked]>
Date: Fri, 19 Jun 2020 15:56:24 +1000

> used to issue the certificate or the private key belonging to the

That's true if you want to revoke a certificate, but how do you deactivate
an account without access to the private key?

Let's say I've lost control of the key for my account, but not the keys to
certificates issued by that account (management server got popped, but not
the end nodes).  I'd prefer it if an attacker couldn't mass-revoke all the
certificates issued under that account while I work through getting all the
certificates re-issued under a new account (due to rate limits, this could
take some time for a large number of certificates).

- Matt

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 Jun 2020 17:11:09 +0000

I don't think ACME should handle this.

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Fri, 19 Jun 2020 19:30:47 +0200

What he talking about, is to make it possible, to get a "revocation blob"
from the ACME client, for a specific client or certificate.
This can then be locked securely inside a safe, or published with a
dead-mans-switch.

IF anything happens to the certificate, you just take out the securely
stored "revocation blob" OR let the dead-mans-switch expire, and then you
submit the revocation blob (or let another person do it - for example the
dead-man-switch service) to ACME server, which will then revoke the
associated certificate or all certificates under a account, or allow
choosing of a certificate.

The purpose is that this revocation blob should be limited in access such
that it can ONLY be used to revoke certificates - and maybe one-use only so
if you want to revoke another certificate, you have to use a fresh unused
blob, and thus that blob does not need to be stored super-securely, it can
be stored accessible enough that it can be used in an emergency.

The private key of the certicate or account needs to be stored securely
enough that nobody else gets it, else the certificate could be misused.

-----Ursprungligt meddelande-----
Från: Salz, Rich <rsalz=[email-masked]> 
Skickat: den 19 juni 2020 19:12
Till: Matt Palmer <[email-masked]>; [email-masked]
Ämne: Re: [Acme] Revocation via ACME using pre-signed artifact

_______________________________________________
Acme mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/acme

---

From: Roland Shoemaker <[email-masked]>
Date: Mon, 22 Jun 2020 19:15:03 -0700

Hey Matt,

In general I think this is a good idea. It's a concept that has been
discussed in a handful of venues in the past, and would certainly be a good
thing to have.

That said I'm not _entirely_ sure that ACME is the right place to specify
it. I think tying such a mechanism too closely to ACME is, unfortunately, a
barrier to getting the method adopted elsewhere. If we wanted to say get
this mechanism adopted by the CABF as a mandated revocation mechanism for
instance I think it'd be better to define the mechanism in isolation from a
protocol so that it could be subsumed into other APIs more easily. ACME
could then build an endpoint extension that implemented this mechanism. I
guess in practice we could do this in an ACME draft by
separately specifying the mechanism and the API extension, such that the
mechanism could be implemented independently from the API, but I worry it
would end up being forever branded as 'an ACME thing' (which who knows, may
not be a terrible thing).

But yeah, I think this is something that should definitely be considered,
either in ACME or perhaps lamps? I'd be happy to help I-D-ifying any
proposal if you'd like the assistance.

Thanks,
Roland

---

From: Matt Palmer <[email-masked]>
Date: Tue, 23 Jun 2020 13:46:36 +1000

> not be a terrible thing).

I think what you're saying is that a standardised mechanism for generating a
"key compromise attestation" would be good -- but not necessarily something
for the ACME WG -- while a means of supplying a key compromise attestation
(whatever form it may take) to an ACME server would be a separate document
that would be suitable work for the ACME WG.  Have I got that about right?

If so, work on the two items can proceed somewhat in parallel, with the
proviso that the ACME extension could not be finalised until an attestation
format had been finalised -- until then, it'd have a big blank space, with
"insert key compromise attestation format here" in small type.  <grin>

Having reviewed the LAMPS WG charter, I think it'd be a heck of a stretch to
have a compromise attestation format adopted there without rechartering. 
But I can certainly see how the ACME WG isn't the "right place" for a
generic document specifying a format for attesting to key compromise,
either.  So in the first instance I suppose I'll work on an individual
submission for the attestation format.

- Matt