IETF Logo Mail Archive

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

Stefan Eissing <stefan@eissing.org> Mon, 14 February 2022 09:17 UTC

Return-Path: <stefan@eissing.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 EBF353A0A51 for <acme@ietfa.amsl.com>; Mon, 14 Feb 2022 01:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=eissing.org
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 nHZkVcONWMvm for <acme@ietfa.amsl.com>; Mon, 14 Feb 2022 01:17:30 -0800 (PST)
Received: from mail.eissing.org (mail.eissing.org [194.163.179.85]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF53E3A0CFF for <acme@ietf.org>; Mon, 14 Feb 2022 01:17:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=eissing.org; s=default; t=1644830246; bh=KcYFni/NQALKwyQjVDqa3CkXjAh1HxCcMUltuhiuxlQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=AdqlQGboKHiS5EqPqZt1DXYEZ/NBHtUltvRaydJRGj3HVcMrIjJyKj9GRheCHGTkl ortKybPs+0bpdUlcRhwzTrm9mXDcc5PtgE2vFRhtTned/Apwrx7ET68Di3q5dZRjAM UWIR7s/G+PgszVpBaIDnSLb9xpFg51UwDsfC6DlhrBxDf+TkF6hBBmmPAuY4FnUhnT o+efmc/LeCd570nQXZljLVvHehbIuzedcKvr7vzgM4x5bhGDh7oFEj15PrDAEBP/Sx 2bmmnpHpSn/1E1faknGA6EzKsMheN21n32DBBtrmu/jCzt1vFXhCgjLoNijvC5rV/n osZMXj/T9evzA==
Received: from smtpclient.apple (unknown [89.246.53.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.eissing.org (Postfix) with ESMTPSA id 7687BC0069; Mon, 14 Feb 2022 10:17:24 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Stefan Eissing <stefan@eissing.org>
In-Reply-To: <20220213053944.GC58590@kduck.mit.edu>
Date: Mon, 14 Feb 2022 10:17:23 +0100
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "J.C. Jones" <ietf@insufficient.coffee>, acme@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <67E8BE96-7F15-4DE6-8DE9-B30288886926@eissing.org>
References: <CALrMbp_M74q=WE02vuF6Ey+YMe_E1VOmN9yHS4AdxwUPpX=y1w@mail.gmail.com> <26737.1644521475@localhost> <20220213053944.GC58590@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/NZDRBNpUZE4DRxMDTOmn1H1ZmD4>
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: Mon, 14 Feb 2022 09:17:36 -0000


> Am 13.02.2022 um 06:39 schrieb Benjamin Kaduk <kaduk@mit.edu>:
> 
> 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.

Unnecessary. HTTP servers can redirect to language specific resources just fine. Let's not i18n the protocol urls, please.

> 
> Yes, BCP 18 has a few things to say on this matter.
> 
> -Ben
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

v2.23.0 | Report a Bug | By Email