IETF Logo Mail Archive

Re: [Acme] ARI: Indication if certificate will be revoked

Andrew Ayer <agwa@andrewayer.name> Wed, 22 March 2023 21:44 UTC

Return-Path: <agwa@andrewayer.name>
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 6E5BAC14F748 for <acme@ietfa.amsl.com>; Wed, 22 Mar 2023 14:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEpSMN09WZO4 for <acme@ietfa.amsl.com>; Wed, 22 Mar 2023 14:44:10 -0700 (PDT)
Received: from thomson.beanwood.com (thomson.beanwood.com [IPv6:2600:1f16:719:be00:5c48:f083:d884:d130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19506C15C280 for <acme@ietf.org>; Wed, 22 Mar 2023 14:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1679521418; bh=JJt2YutPwkwoTElAw6M0Db/zpT+4yYkgkcoiXX2e4cE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=C/t1enolGD7lcL3gX0fv7/hacC4nOqfZHeCkwlcoVYJL/MO+Lwsz0CpSzg6DSSq8h QBuhWOz+ooRVS2LZ1+6pyLN7G30eSoT3jZOSuUzg1wicKLosqJvjMzE5KEv6Tyy6hE RxnCo/IX7UO2ojbqXjnnBqzngxLdntjG+WuIOHCLbjgkmlE6pDwcflarUpuxurNQ3B +LmGCUVFMcmTV3XafOqLTGxNfBKvpDCwNGV++ldBzu8GLVkia+NXNK0frAVkMdQ7IU R/ih47LNTcG3E0ZSEfUYYIJXbUlsOmeMgURO77Y/yvrIcflmoqUjARaMV+rWVmmGSE bLo/Abk4SLAFA==
Date: Wed, 22 Mar 2023 17:43:37 -0400
From: Andrew Ayer <agwa@andrewayer.name>
To: Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org>
Cc: "acme@ietf.org" <acme@ietf.org>
Message-Id: <20230322174337.ef7fdc0a07b859cca191bbae@andrewayer.name>
In-Reply-To: <CAEmnEreSnwWZXCS84AnwbHrsxsDPnt=6c0DCzyioV+ARapBnsw@mail.gmail.com>
References: <20230322103538.975d953c92be1463f2347a4e@andrewayer.name> <DM6PR14MB2186F5867BDDAB1394F2A23492869@DM6PR14MB2186.namprd14.prod.outlook.com> <20230322163024.d6274767c10df709d7293171@andrewayer.name> <CAEmnEreSnwWZXCS84AnwbHrsxsDPnt=6c0DCzyioV+ARapBnsw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/ypiytuPu2-KzQXJQ1_6FlZFFwE0>
Subject: Re: [Acme] ARI: Indication if certificate will be revoked
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 22 Mar 2023 21:44:14 -0000

On Wed, 22 Mar 2023 14:16:40 -0700
Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org> wrote:

> I'm not totally sold on the utility of including extra information in
> the ARI response, if that extra information will not modify client
> behavior. If the purpose is to modify human behavior, then I believe
> the current explanationURL is sufficient. Adding a machine-readable
> problem document that would only be read by machines that are not
> part of the ACME client/server relationship feels odd to me.

There are a lot of ACME implementations and deployments and it will take
a long time for them to all support ARI.  If monitoring programs could
alert operators that they need to urgently trigger a renewal, it would
help reduce the impact of mass revocation events, which was a major
motivation for ARI.

Consumption by monitoring programs was the reason for constructing the
ARI URL from the issuer and serial number.  However, ARI is not
useful for monitoring programs without an indication of whether the
renewal window is due to revocation.

Regards,
Andrew

v2.23.0 | Report a Bug | By Email