[Acme] [Technical Errata Reported] RFC8555 (5771)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 02 July 2019 14:04 UTC
Return-Path: <wwwrun@rfc-editor.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 B3CEB1200F1 for <acme@ietfa.amsl.com>; Tue, 2 Jul 2019 07:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 s8ev9eddbwzS for <acme@ietfa.amsl.com>; Tue, 2 Jul 2019 07:04:08 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EB41200B6 for <acme@ietf.org>; Tue, 2 Jul 2019 07:04:07 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 527D3B81CB0; Tue, 2 Jul 2019 07:04:00 -0700 (PDT)
To: rlb@ipv.sx, jsha@eff.org, cpu@letsencrypt.org, jdkasten@umich.edu, rdd@cert.org, kaduk@mit.edu, rsalz@akamai.com, ynir.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rob@sectigo.com, acme@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190702140400.527D3B81CB0@rfc-editor.org>
Date: Tue, 02 Jul 2019 07:04:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/ztbfrs994Z3So34Wejkk213wnLY>
X-Mailman-Approved-At: Tue, 02 Jul 2019 07:08:25 -0700
Subject: [Acme] [Technical Errata Reported] RFC8555 (5771)
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: Tue, 02 Jul 2019 14:04:10 -0000
The following errata report has been submitted for RFC8555, "Automatic Certificate Management Environment (ACME)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5771 -------------------------------------- Type: Technical Reported by: Rob Stradling <rob@sectigo.com> Section: 7.1.1 Original Text ------------- Clients access the directory by sending a GET request to the directory URL. Corrected Text -------------- Clients access the directory by sending a GET request to the directory URL. Before making a request to any URL from the directory, the client MUST evaluate whether the directory object is still fresh according to the Cache-Control header(s) received when that directory object was accessed. If no Cache-Control header(s) were received, the client MUST act as if "Cache-Control: no-cache" was received. If the directory object is no longer fresh, the client MUST access the directory again (by sending another GET request to the directory URL) and then use the updated directory object. Notes ----- The original text is underspecified, because it doesn't say how long a directory remains valid. A server should be able to update its directory (e.g., to add support for newAuthz, to update the termsOfService URL, etc) without having to worry about clients holding on to stale directory objects. Whilst in practice many clients tend to re-fetch the server's directory object frequently, I think that it's unwise to leave this to chance. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8555 (draft-ietf-acme-acme-18) -------------------------------------- Title : Automatic Certificate Management Environment (ACME) Publication Date : March 2019 Author(s) : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten Category : PROPOSED STANDARD Source : Automated Certificate Management Environment Area : Security Stream : IETF Verifying Party : IESG
- [Acme] [Technical Errata Reported] RFC8555 (5771) RFC Errata System
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Salz, Rich
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Jacob Hoffman-Andrews
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Stefan Eissing
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Rob Stradling
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Salz, Rich
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Rob Stradling
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… stefan@eissing.org
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Rob Stradling
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Ask Bjørn Hansen
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Salz, Rich
- Re: [Acme] [Technical Errata Reported] RFC8555 (5… Rob Stradling