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

Roland Shoemaker <> Tue, 23 June 2020 02:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D6243A0896 for <>; Mon, 22 Jun 2020 19:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JP1khtg0ksA1 for <>; Mon, 22 Jun 2020 19:15:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AFD63A16F4 for <>; Mon, 22 Jun 2020 19:15:16 -0700 (PDT)
Received: by with SMTP id l11so18849942wru.0 for <>; Mon, 22 Jun 2020 19:15:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nEShSDgawmexHI5WlD4CFUEQSL0UDvn2Z1xmlyLnP3s=; b=HKyDCs6/Jcy4MsIKzSaXefo/pni+AVJyU/onSleTGSpKS1fszRmoetxEuZ8rQhvwCw S2V9AUnExDYeUG87qhAdreOQI/XaZ5lgUw6qYfHpbFWrpVLgVfhCU5O0VK8DgwtAdV6G ALbnVuN0Ids+a4BTT5i8tUHyItQOE0SnYyQ8o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nEShSDgawmexHI5WlD4CFUEQSL0UDvn2Z1xmlyLnP3s=; b=GHe4fkhmeeC6KcY1OM1xNztxP6j6EKFdbAJCoqe/LR7P6hFqwK8gs7BkMsCydgNsDB FyJQYppc8nFej+QeOJ3Vot/mHxkTC/2C9a81FYk6R68FCDSgz81lF11Jo+wKzMRsgte4 zURGVZZLaGjtvTtBTffch7Hl+ppyhkibJArvLtphsqXiqu+68T39LG8zJNngUZ3D5NAm +6HgLEsMihMMPitZIFB0uXpeSudxsad5jHaNF9EDbc8oZ23f80tkCE2ZrhNSrz+G6Rig CZEh4raGK7LhUfSIJVpbE8McduPQJeNV1IchDi1gxZ8I5kkgnhILm2SwzWZy+eB8rNQO gtJQ==
X-Gm-Message-State: AOAM531XsCOr9sjF4wgn4rUYfn1BkHqv6JFj2EEPND14e96Px8JV0Opy hAsFt5+gtERNjgTTkTHrZFbqHv/BLztp6I7xfGxr4w==
X-Google-Smtp-Source: ABdhPJyTuux2GK5ah0VUzffjR/JQPaCtNzZSOGYH8zm2bsssWhoOdxEFo56KAUHORk/qfpx3dDTOdruoBGcpeo5hz9I=
X-Received: by 2002:adf:ef8a:: with SMTP id d10mr12869588wro.126.1592878514541; Mon, 22 Jun 2020 19:15:14 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Roland Shoemaker <>
Date: Mon, 22 Jun 2020 19:15:03 -0700
Message-ID: <>
To: Matt Palmer <>
Content-Type: multipart/alternative; boundary="00000000000007a7b405a8b6ee0e"
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: Tue, 23 Jun 2020 02:15:20 -0000

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.


On Thu, Jun 18, 2020 at 4:21 PM Matt Palmer <> wrote:

> 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
> 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
> _______________________________________________
> Acme mailing list