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

Matt Palmer <> Tue, 23 June 2020 04:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52BD43A172B for <>; Mon, 22 Jun 2020 21:04:39 -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 xo02jSjcsuCP for <>; Mon, 22 Jun 2020 21:04:37 -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 660D43A090D for <>; Mon, 22 Jun 2020 21:04:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 64C3719311E for <>; Tue, 23 Jun 2020 04:04:34 +0000 (UTC)
Received: by (Postfix, from userid 1000) id DF745A0E22; Tue, 23 Jun 2020 13:46:36 +1000 (AEST)
Date: Tue, 23 Jun 2020 13:46:36 +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: Tue, 23 Jun 2020 04:04:39 -0000

On Mon, Jun 22, 2020 at 07:15:03PM -0700, Roland Shoemaker wrote:
> 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).

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