IETF Logo Mail Archive

[Sidrops] [Technical Errata Reported] RFC9286 (7243)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 07 November 2022 16:35 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B1DC14F724 for <sidrops@ietfa.amsl.com>; Mon, 7 Nov 2022 08:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.659
X-Spam-Level:
X-Spam-Status: No, score=-6.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 QBsjcs6hKDX8 for <sidrops@ietfa.amsl.com>; Mon, 7 Nov 2022 08:35:23 -0800 (PST)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (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 359B2C1524C1 for <sidrops@ietf.org>; Mon, 7 Nov 2022 08:35:23 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 04502C8AF4; Mon, 7 Nov 2022 08:35:22 -0800 (PST)
To: sra@hactrn.net, gih@apnic.net, kent@alum.mit.edu, mlepinski@ncf.edu, warren@kumari.net, rwilton@cisco.com, keyur@arrcus.com, morrowc@ops-netman.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: tdekock@ripe.net, sidrops@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20221107163523.04502C8AF4@rfcpa.amsl.com>
Date: Mon, 07 Nov 2022 08:35:22 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/nFbjWawZ8R8uulSNCRLBVARtd_s>
X-Mailman-Approved-At: Mon, 07 Nov 2022 12:09:31 -0800
Subject: [Sidrops] [Technical Errata Reported] RFC9286 (7243)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 16:35:27 -0000

The following errata report has been submitted for RFC9286,
"Manifests for the Resource Public Key Infrastructure (RPKI)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7243

--------------------------------------
Type: Technical
Reported by: Ties de Kock <tdekock@ripe.net>

Section: 4.2.1.  Manifest

Original Text
-------------
   thisUpdate:
      This field contains the time when the manifest was created.  This
      field has the same format constraints as specified in [RFC5280]
      for the CRL field of the same name.  The issuer MUST ensure that
      the value of this field is more recent than any previously
      generated manifest.  Each RP MUST verify that this field value is
      greater (more recent) than the most recent manifest it has
      validated.  If this field in a purported "new" manifest is smaller
      (less recent) than previously validated manifests, the RP SHOULD
      use locally cached versions of objects, as described in
      Section 6.6.

Corrected Text
--------------
    thisUpdate:
      This field contains the time when the manifest was created. This
      field has the same format constraints as specified in [RFC5280]
      for the CRL field of the same name. The issuer MUST ensure that
      the value of this field is equal to the current time and higher or
      equal to the thisUpdate of any previously generated manifest. Each
      RP MUST verify that this field value is greater or equal to (as,
      or more recent) than the most recent manifest it has validated.
      Suppose this field in a purported "new" manifest is smaller (less
      recent) than previously validated manifests. In that case, the RP
      SHOULD use locally cached versions of objects, as described in
      Section 6.6.



Notes
-----
First of all: The previous text was not explicit that thisUpdate MUST contain the current time.

Second, in practice (e.g. multiple calls to a synchronous API) multiple manifests can be issued with the same thisUpdate. Under the previous text this would technically be misissuance. The propose text allows multiple manifests to be issued in the same second.

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. 

--------------------------------------
RFC9286 (draft-ietf-sidrops-6486bis-11)
--------------------------------------
Title               : Manifests for the Resource Public Key Infrastructure (RPKI)
Publication Date    : June 2022
Author(s)           : R. Austein, G. Huston, S. Kent, M. Lepinski
Category            : PROPOSED STANDARD
Source              : SIDR Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

v2.23.0 | Report a Bug | By Email