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

Andrew Ayer <agwa@andrewayer.name> Wed, 22 March 2023 20:31 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 8BBA9C14CEFC for <acme@ietfa.amsl.com>; Wed, 22 Mar 2023 13:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AVPt6coqCUcE for <acme@ietfa.amsl.com>; Wed, 22 Mar 2023 13:31:34 -0700 (PDT)
Received: from thomson.beanwood.com (thomson.beanwood.com [18.220.42.202]) (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 84B0CC14CE30 for <acme@ietf.org>; Wed, 22 Mar 2023 13:31:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1679517093; bh=naPKsFMoCX3w4aXdeJ5pr6/KggXukIbMHzGMiZwdXao=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=OsuAza+p4WZs/QxcH2CxDihXFv70fZqAdiOp9qFxGwoTv8tyZvZOi2c7dG2ZiAKv4 eO3X2FKAJo3pJp/Jin+F++CoBmRnQ90W21c2u0bLoUZMntru6SvXMzcQB1WlqEi3gG RWUwgE1xzQalD2wHiMcKkuKztpSepTuiHaus30DPKeRr2EazVs+aSkuUuM3eFZCLR3 OJ8NVlIJGdegjojrxErD8VL7MH74wiUKeijt/QoVWZ1iFw+CK9xJ9FfcfsmXN6mDU2 drpfmMly1AGXqXebDyx9ztC9KPAOOi5z5MXU9R1sB7wwp4ygRduAJWqhrXkmMGj1WQ 4N496kJkuWUMw==
Date: Wed, 22 Mar 2023 16:30:24 -0400
From: Andrew Ayer <agwa@andrewayer.name>
To: Corey Bonnell <Corey.Bonnell=40digicert.com@dmarc.ietf.org>
Cc: "acme@ietf.org" <acme@ietf.org>
Message-Id: <20230322163024.d6274767c10df709d7293171@andrewayer.name>
In-Reply-To: <DM6PR14MB2186F5867BDDAB1394F2A23492869@DM6PR14MB2186.namprd14.prod.outlook.com>
References: <20230322103538.975d953c92be1463f2347a4e@andrewayer.name> <DM6PR14MB2186F5867BDDAB1394F2A23492869@DM6PR14MB2186.namprd14.prod.outlook.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/Lf3vZzlhyZRQpop9qY8xBG2Ia1I>
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 20:31:38 -0000

Hi Corey,

On Wed, 22 Mar 2023 17:55:59 +0000
Corey Bonnell <Corey.Bonnell=40digicert.com@dmarc.ietf.org> wrote:

> Hi Andrew,
> Is the purpose of the "revocationTime" field such that ACME client
> behavior would be different than the recommended replacement
> time-selection algorithm in section 4.1, or is it to provide richer
> metadata about the pending replacement window that is potentially
> human or machine-readable?

It is the latter - to provide richer metadata about why the window is
what it is.  ACME client behavior would not be affected.

> If the latter, I'm wondering if we could consider defining a RFC
> 7807-style "problem document" format that would provide fuller
> information that is both human- and machine-readable. The
> "explanationURL" field as it currently exists in the draft might be
> useful for conveying human-readable information, but defining a
> fuller representation of replacement-related metadata would also
> allow machine-readable information to be conveyed.

That could potentially be useful.  Do you have any other information in
mind that would be included?

Regards,
Andrew