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

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 07 December 2022 12:42 UTC

Return-Path: <tim@nlnetlabs.nl>
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 248A4C1526E8 for <sidr@ietfa.amsl.com>; Wed, 7 Dec 2022 04:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 gZU3P-JtVxFe for <sidr@ietfa.amsl.com>; Wed, 7 Dec 2022 04:42:29 -0800 (PST)
Received: from dane.soverin.net (dane.soverin.net [IPv6:2a10:de80:1:4092:b9e9:2294:0:1]) (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 BE191C152587 for <sidr@ietf.org>; Wed, 7 Dec 2022 04:42:29 -0800 (PST)
Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4NRxkp27cxz2xP7; Wed, 7 Dec 2022 12:42:26 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4NRxkn4wvJz1d; Wed, 7 Dec 2022 12:42:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1670416946; bh=cNaBVFYbUEUvMh6HV7mK/XfS30zpHqtijn7MZecbRSw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ddwAIqpKt2Rnokn0hChn66VzR7uvHGlE32ECnSsTSFeb/QGZe0NmICcQlWfHLBiXn Z+vuDlqYXugEgWWeA/JAQZGng3L1O21hCou97aBpzIZHY5m39hSkv8jDfl6fx9ENwN dkL54sEYUniX/HBdzwSKkLOnlotIEssbPHVtCtQcadsv226bR7z7OnZ97AnwNTHAsH seRIJkgy7blqKsKIMe84y2hQOlynZ+g2pr7zIao0IgUIkFw3arGWA/9Swr9sly/+J7 VhRREm6d05Yr1aTzBEW9P/gp+ctLfIkgOVKuLps6MeMQTLuozuutrfVte3hWHvCKrS Ge2JE9SBNZh7A==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
X-Soverin-Authenticated: true
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <E14935D6-CD13-4987-B973-79BA92775996@cobenian.com>
Date: Wed, 07 Dec 2022 13:42:25 +0100
Cc: Tom Harrison <tomh@apnic.net>, job@fastly.com, sra@hactrn.net, sidr@ietf.org, morrowc@ops-netman.net, andrew-ietf@liquid.tech, jgs@juniper.net, RFC Errata System <rfc-editor@rfc-editor.org>, tim@ripe.net
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE9E96BA-8929-4FB5-8AE2-A2BAE17A7D2E@nlnetlabs.nl>
References: <20221104113812.3303455F68@rfcpa.amsl.com> <Y5AjG3AJjHaFIRdv@TomH-802418> <E14935D6-CD13-4987-B973-79BA92775996@cobenian.com>
To: Cobenian <bryan@cobenian.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/jvLYrmCzp-38CXM0u8h6ezGtNGo>
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 12:42:34 -0000

Hi,

I agree with this report.

The clarification should have been included. CA certificates were intended - RPKI object retrieval is irrelevant in the context of the EE certificates in RPKI signed objects. And as Job pointed out the addition of the access description would not be allowed there.

Speaking for myself only I have used the term "resource certificate" in the RPKI colloquially to refer specifically to RPKI CA certificates. It seems that leaked into this specification unintentionally.

Tim

> On 7 Dec 2022, at 13:30, Cobenian <bryan@cobenian.com> wrote:
> 
> I agree that the proposed errata would be a good clarification.
> 
> Thanks,
> Bryan
> 
> 
>> On Dec 7, 2022, at 12:22 AM, Tom Harrison <tomh@apnic.net> wrote:
>> 
>> 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 this report.  (APNIC is the RIR referred to in this
>> paragraph, and we also found the text to be unclear when we were
>> implementing this specification.)
>> 
>> -Tom
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr