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

Jannis Pinter <jannis@pinterjann.is> Fri, 19 June 2020 05:15 UTC

Return-Path: <jannis@pinterjann.is>
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 2B9F43A0E33 for <acme@ietfa.amsl.com>; Thu, 18 Jun 2020 22:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pinterjann.is
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 8t1nhnhwk9-m for <acme@ietfa.amsl.com>; Thu, 18 Jun 2020 22:15:38 -0700 (PDT)
Received: from mx0.pinterjann.is (mx0.pinterjann.is [IPv6:2a04:3542:1000:910:8e1:abff:fe4f:10ae]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DBE73A0E29 for <acme@ietf.org>; Thu, 18 Jun 2020 22:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinterjann.is; s=2020-Q2; t=1592543733; bh=1JERXfwfnulEHnzPExb1sV+LbOLzU0HKiY3kcj7+CEQ=; h=Subject:To:From:Autocrypt:Message-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; b=BeRtKzjGU2l1MqLjXl7AH5sV5aeJudg2M9+QvPkkNoCfSkXVsuwan2e0EiHunqd2r SOthwVpG1wRZk3t9ajQ8ZTE+aYMBed+D/JlRwOwjb1QHa/ByGLSNuypB9zC1NM/uXo crndW6qug3iZbrBOe434K50HJItUzx7VrKfGuR/uRqEpeYChWtxc4b1Bri4JmB8jhb Ax/DBVF87GiXfiItc5m7Vj4wWNl60q7vIeew7O1OXVgcfI889Ut0eKzZmJvVcS3ts4 +sqaO4Ow0BXJjtYbrzTw4YiHxsZm5NYuBkWlaoEFSKpw0QIZjC+ezMcgrK8dPAoLoc MOnXNZ2FAeJVw==
To: acme@ietf.org
References: <20200618232136.dusrpzvag62hofh4@hezmatt.org>
From: Jannis Pinter <jannis@pinterjann.is>
Autocrypt: addr=jannis@pinterjann.is; prefer-encrypt=mutual; keydata= mDMEWrkkShYJKwYBBAHaRw8BAQdAS7mxfMubVaK+GteDS4ZwXSiPAzg+yi1m3bwCRRNrmUm0 JEphbm5pcyBQaW50ZXIgPGphbm5pc0BwaW50ZXJqYW5uLmlzPoiWBBMWCAA+FiEE0NqTsMgy 6lNaCmOiARUtS+Nw/OoFAlq5JEoCGwMFCQrYJagFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQARUtS+Nw/OrF7gEAwZSXi2TNzeaCXhKi+tRqKJdtTOzcBg8M9XfviYOrmvsA/3cnY09r lL7U/gPHUgzHG3/BK17tJ0fVoTWWeAQlHFQNuDgEWrkkShIKKwYBBAGXVQEFAQEHQOBXrqZD 7K1G2sbWVYV3nUwDGbnzgDhw8jHChoUMI81zAwEIB4h+BBgWCAAmFiEE0NqTsMgy6lNaCmOi ARUtS+Nw/OoFAlq5JEoCGwwFCQrYJagACgkQARUtS+Nw/OoEJwD+L481mw2+MDTH6poEPwiH TcLzWdjmYwahBmcJJq1fvB0A/AzKJD8dpPm1yGmOYj/arJa93IPZ4Hh34CHBVTAQEFgI
Message-ID: <1d8652f0-45fc-162b-9add-1b0549004578@pinterjann.is>
Date: Fri, 19 Jun 2020 07:15:31 +0200
MIME-Version: 1.0
In-Reply-To: <20200618232136.dusrpzvag62hofh4@hezmatt.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/9pYH4P1pocQJNH63F_urPthVcOo>
Subject: Re: [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: Fri, 19 Jun 2020 05:15:42 -0000

Hi Matt,

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.

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