Re: [Acme] [Technical Errata Reported] RFC8555 (6317)
Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 03 January 2024 16:02 UTC
Return-Path: <ilariliusvaara@welho.com>
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 49223C14F6BB for <acme@ietfa.amsl.com>; Wed, 3 Jan 2024 08:02:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 DkV3dnDXCycP for <acme@ietfa.amsl.com>; Wed, 3 Jan 2024 08:02:01 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E55C14F6BA for <acme@ietf.org>; Wed, 3 Jan 2024 08:02:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id B774446D2A for <acme@ietf.org>; Wed, 3 Jan 2024 18:01:57 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id eayUNuB4qPg5 for <acme@ietf.org>; Wed, 3 Jan 2024 18:01:57 +0200 (EET)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi [78.27.96.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 8993D287 for <acme@ietf.org>; Wed, 3 Jan 2024 18:01:56 +0200 (EET)
Date: Wed, 03 Jan 2024 18:01:56 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: acme@ietf.org
Message-ID: <ZZWE9Ni3hx0Cot1J@LK-Perkele-VII2.locald>
References: <20201023221949.B6009F4072C@rfc-editor.org> <CAGgd1OcBrF-W_rktuTyCNnC_8-tU2i5VQSLAUoc_mw-aZTSANQ@mail.gmail.com> <50047612-01A3-436F-A940-6CAE115F2AD9@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <50047612-01A3-436F-A940-6CAE115F2AD9@gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/xSvyg6_WRDi6hyjqNeSb5qG5CUc>
Subject: Re: [Acme] [Technical Errata Reported] RFC8555 (6317)
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, 03 Jan 2024 16:02:03 -0000
On Wed, Jan 03, 2024 at 11:13:01PM +0900, Seo Suchan wrote: > While looks sensible I wonder if how many clients pulling on auth > instead of challanges: Those client will pull without limit if this > behavior applied to CA > > For example this client do watch auths status instead of challenge > itself. > https://github.com/diafygi/acme-tiny/blob/c29c0f36cedbca2a7117169c6a9e1f166c501899/acme_tiny.py#L151 I would imagine most clients do that. The one that I have written certainly does (I think it would timeout with "authorization status stuck" error after 10min). AFAIK, ACME does not even guarantee that challenges are fetchable. And one does not have to deactivate authorizations in order to retry. Just creating new order will either restart from scratch or resume where one left off, depending on the CA. Yes, one would need autotimeouting blacklist for clients that can try multiple methods, but I do not think that is hard (at least compared to stuff like handling the three different concurrent order race conditions). The only reasons I know to deactivate authorizations: - Getting rid of zombie auths that fail CAA validationmethods. - Dropping authority to reduce damage on key compromise (explicit clear-all would be better for this purpose). -Ilari
- [Acme] [Technical Errata Reported] RFC8555 (6317) RFC Errata System
- Re: [Acme] [Technical Errata Reported] RFC8555 (6… Deb Cooley
- Re: [Acme] [Technical Errata Reported] RFC8555 (6… Seo Suchan
- Re: [Acme] [Technical Errata Reported] RFC8555 (6… Ilari Liusvaara
- Re: [Acme] [Technical Errata Reported] RFC8555 (6… Aaron Gable
- Re: [Acme] [Technical Errata Reported] RFC8555 (6… Jacob Hoffman-Andrews