[Acme] Revocation via ACME using pre-signed artifact
Matt Palmer <mpalmer@hezmatt.org> Thu, 18 June 2020 23:21 UTC
Return-Path: <mpalmer@hezmatt.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEB93A11DF for <acme@ietfa.amsl.com>; Thu, 18 Jun 2020 16:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg9iMuv-PPEa for <acme@ietfa.amsl.com>; Thu, 18 Jun 2020 16:21:49 -0700 (PDT)
Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282BF3A11B2 for <acme@ietf.org>; Thu, 18 Jun 2020 16:21:48 -0700 (PDT)
Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-4d90-2288-4828-b7db.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:4d90:2288:4828:b7db]) by mail.hezmatt.org (Postfix) with ESMTPSA id 7FA601928EB for <acme@ietf.org>; Thu, 18 Jun 2020 23:21:44 +0000 (UTC)
Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id C30E8A0444; Fri, 19 Jun 2020 09:21:36 +1000 (AEST)
Date: Fri, 19 Jun 2020 09:21:36 +1000
From: Matt Palmer <mpalmer@hezmatt.org>
To: acme@ietf.org
Message-ID: <20200618232136.dusrpzvag62hofh4@hezmatt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Usvf3Qa09XaPPD0BosXYG99wxiY>
Subject: [Acme] Revocation via ACME using pre-signed artifact
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 23:21:53 -0000
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
- [Acme] Revocation via ACME using pre-signed artif… Matt Palmer
- Re: [Acme] Revocation via ACME using pre-signed a… Jannis Pinter
- Re: [Acme] Revocation via ACME using pre-signed a… Matt Palmer
- Re: [Acme] Revocation via ACME using pre-signed a… Salz, Rich
- Re: [Acme] Revocation via ACME using pre-signed a… Sebastian Nielsen
- Re: [Acme] Revocation via ACME using pre-signed a… Roland Shoemaker
- Re: [Acme] Revocation via ACME using pre-signed a… Matt Palmer