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

Matt Palmer <> Fri, 19 June 2020 05:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 322CD3A0E41 for <>; Thu, 18 Jun 2020 22:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7YAkdgeUo0F5 for <>; Thu, 18 Jun 2020 22:56:32 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 843FE3A0E23 for <>; Thu, 18 Jun 2020 22:56:32 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id DDD2B19295A for <>; Fri, 19 Jun 2020 05:56:29 +0000 (UTC)
Received: by (Postfix, from userid 1000) id BEFA3A0447; Fri, 19 Jun 2020 15:56:24 +1000 (AEST)
Date: Fri, 19 Jun 2020 15:56:24 +1000
From: Matt Palmer <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [Acme] Revocation via ACME using pre-signed artifact
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Jun 2020 05:56:34 -0000

On Fri, Jun 19, 2020 at 07:15:31AM +0200, Jannis Pinter wrote:
> On 19.06.20 01:21, Matt Palmer wrote:
> > 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.
> 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.

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