[sidr] [Technical Errata Reported] RFC8182 (7239)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 04 November 2022 11:38 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51292C1527A2 for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2022 04:38:16 -0700 (PDT)
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 itszV-IpTmXU for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2022 04:38:12 -0700 (PDT)
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 7C056C15271C for <sidr@ietf.org>; Fri, 4 Nov 2022 04:38:12 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 3303455F68; Fri, 4 Nov 2022 04:38:12 -0700 (PDT)
To: tim@ripe.net, oleg@ripe.net, bryan@cobenian.com, sra@hactrn.net, aretana.ietf@gmail.com, jgs@juniper.net, andrew-ietf@liquid.tech, morrowc@ops-netman.net, sandy@tislabs.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: job@fastly.com, sidr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20221104113812.3303455F68@rfcpa.amsl.com>
Date: Fri, 04 Nov 2022 04:38:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/7ZwQsV9gsqEgZurkf1nAtCvlZes>
Subject: [sidr] [Technical Errata Reported] RFC8182 (7239)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2022 11:38:16 -0000

The following errata report has been submitted for RFC8182,
"The RPKI Repository Delta Protocol (RRDP)".

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

--------------------------------------
Type: Technical
Reported by: Job Snijders <job@fastly.com>

Section: 3.2

Original Text
-------------
Certificate Authorities that use RRDP MUST include an instance of an
SIA AccessDescription extension in resource certificates they
produce, in addition to the ones defined in [RFC6487]:

Corrected Text
--------------
Certificate Authorities that use RRDP MUST include an instance of an
SIA AccessDescription extension in CA resource certificates they
produce, in addition to the ones defined in [RFC6487]:

Notes
-----
Between draft-ietf-sidr-delta-protocol-04 and draft-ietf-sidr-delta-protocol-05 a bit of text was removed (perhaps because it was considered redundant). But, unfortunately that snippet helped establish important context as to what types of certificates are expected to contain the id-ad-rpkiNotify accessMethod inside the Subject Information Access extension. The text that was removed:

"""
Relying Parties that do not support this delta protocol MUST MUST NOT
reject a CA certificate merely because it has an SIA extension
containing this new kind of AccessDescription.
"""

>From the removed text is is clear that id-ad-rpkiNotify was only expected to show up on CA certificates. However, without the above text, Section 3.2 of RFC 8182 is somewhat ambiguous whether 'resource certificates' is inclusive of EE certificates or not.

RFC 6487 Section 4.8.8.2 sets expectations that only id-ad-signedObject is expected to show up in the SIA of EE certificates "Other AccessMethods MUST NOT be used for an EE certificates's SIA."

The ambiguity in RFC8182 led to one RIR including id-ad-rpkiNotify in the SIA of the EE certificate of all signed objects they produce (such as ROAs). The RIR indicated they'll work to remove id-ad-rpkiNotify from all EE certificates their CA implementation produces.

It should be noted that the presence of id-ad-rpkiNotify in EE certificates is superfluous; Relying Parties can't use the rpkiNotify accessMethod in EE certificates for any purpose in the validation decision tree.

(Verifying this Errata does not block a future transition from rsync to https; as RFC6487 Section 4.8.8.2 leaves room for additional instances of id-ad-signedObject with non-rsync URIs)

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. 

--------------------------------------
RFC8182 (draft-ietf-sidr-delta-protocol-08)
--------------------------------------
Title               : The RPKI Repository Delta Protocol (RRDP)
Publication Date    : July 2017
Author(s)           : T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG