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

Oleg Muravskiy <oleg@ripe.net> Wed, 07 December 2022 13:53 UTC

Return-Path: <oleg@ripe.net>
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 6177DC14CE5A for <sidr@ietfa.amsl.com>; Wed, 7 Dec 2022 05:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 dwVjMDnljZ7a for <sidr@ietfa.amsl.com>; Wed, 7 Dec 2022 05:53:04 -0800 (PST)
Received: from mail-mx-1.ripe.net (mail-mx-1.ripe.net [IPv6:2001:67c:2e8:11::c100:1311]) (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 99A1FC14CE3D for <sidr@ietf.org>; Wed, 7 Dec 2022 05:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date ; bh=+VWG4Ou2o3vgRIXmgcen3borxUbi8w9PkS26twApLgI=; b=pN8NLW2iU8QqpBakgtdAG857 HR9YMnjaGldFq7hbYMVPmfppCbOCOPoGu9yaFN1ADwGX9W/ds8tCO9ico3LoXfArdKI9o9EPeasqp LluCKPzE9Z3glxjMaPZAhWJavGHP93nS7bhZ05v/rll4qp+ut4W/3zF00KgcSlZoxZTCY/npDk1pL XoPYbdGWpaJQgKnlRyXC2AYDT28JB/ot9pbHyJmxrnEUjtAL+fsyYmbQzRiogJAiXeqWzX5eLaUWP PTDK4PEcRMmFKvVZuvQdBMFDMGVTueNH8RUi9RtuQ7idN+jSBpCmPVqHLrU/u5ccM7w7+7OIIxrJy pkbtpzII9g==;
Received: from appserv-1.ripe.net ([2001:67c:2e8:1::c100:10a]:43044) by mail-mx-1.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <oleg@ripe.net>) id 1p2ur2-00C1Kf-26; Wed, 07 Dec 2022 13:52:56 +0000
Received: from oleg by appserv-1.ripe.net with local (Exim 4.96) (envelope-from <oleg@ripe.net>) id 1p2ur2-000F9D-1v; Wed, 07 Dec 2022 13:52:56 +0000
Date: Wed, 07 Dec 2022 13:52:56 +0000
From: Oleg Muravskiy <oleg@ripe.net>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: 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, job@fastly.com, sidr@ietf.org
Message-ID: <20221207135256.GA57069@appserv-1.ripe.net>
References: <20221104113812.3303455F68@rfcpa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20221104113812.3303455F68@rfcpa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74fca01c24bb1fed4b412369a243b87a9e
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/OAsgujSvvCrxY5Kk2lL39Wgfgys>
Subject: Re: [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: Wed, 07 Dec 2022 13:53:09 -0000

On Fri, Nov 04, 2022 at 04:38:12AM -0700, RFC Errata System wrote:
> 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.

I agree with the correction provided in this report.

-- 
Oleg Muravskiy