IETF Logo Mail Archive

Re: [Acme] Renewal Information extension: Proposal to add an Explanation URL

Benjamin Kaduk <kaduk@mit.edu> Sun, 13 February 2022 05:40 UTC

Return-Path: <kaduk@mit.edu>
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 1F7243A121B for <acme@ietfa.amsl.com>; Sat, 12 Feb 2022 21:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ML0Z4QEYqIRG for <acme@ietfa.amsl.com>; Sat, 12 Feb 2022 21:39:58 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4FA3A1219 for <acme@ietf.org>; Sat, 12 Feb 2022 21:39:58 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 21D5diFh025861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Feb 2022 00:39:51 -0500
Date: Sat, 12 Feb 2022 21:39:44 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "J.C. Jones" <ietf@insufficient.coffee>, acme@ietf.org
Message-ID: <20220213053944.GC58590@kduck.mit.edu>
References: <CALrMbp_M74q=WE02vuF6Ey+YMe_E1VOmN9yHS4AdxwUPpX=y1w@mail.gmail.com> <26737.1644521475@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <26737.1644521475@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/vcazPKJZc8wjjo1jFcud-kCiRFM>
Subject: Re: [Acme] Renewal Information extension: Proposal to add an Explanation URL
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: Sun, 13 Feb 2022 05:40:04 -0000

On Thu, Feb 10, 2022 at 02:31:15PM -0500, Michael Richardson wrote:
> 
> J.C. Jones <ietf@insufficient.coffee> wrote:
>     > Hence, I propose we add an optional field to the ARI response
>     > structure, "explanationURL", which when populated should be presented
>     > in any user-visible context (logging, alerting, etc) by the
>     > ARI-compatible client. It would be up to the Certificate Authority to
>     > ensure the URL presented appropriately translated information for the
>     > operator, and the CA _should_ only provide the field if there was
>     > something exceptional that warranted additional explanation or
>     > context.
> 
> Sounds good.
> 
> If it's for human consumption, then it might need to be an array or dict,
> with per-language versions.

Yes, BCP 18 has a few things to say on this matter.

-Ben

v2.23.0 | Report a Bug | By Email