From nobody Wed Dec 7 04:31:16 2022 Return-Path: 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 5E9B9C14CE59 for ; Wed, 7 Dec 2022 04:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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=cobenian-com.20210112.gappssmtp.com 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 Zdzz_qYdJZ9R for ; Wed, 7 Dec 2022 04:31:11 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 92BF0C14F72F for ; Wed, 7 Dec 2022 04:31:11 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id x28so14882301qtv.13 for ; Wed, 07 Dec 2022 04:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cobenian-com.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=WWr1PqSX0XW3gKEagwG9KqBw0ANW4CA5Hu++5aMFc0Q=; b=ysm0BUrIqZJtp6liivdcnImSv4CT8k5pkVX5ENDItcIFImbISDRGfQZ+koojcFq/fv bdXDy4O5jl2yjhRyhxKeErWzxULTer3YOR6DY4Ce/sdvQ0nMu7Q4BF/nRFXpnqLH7KkD RyqCDBbU+NjV4fSM0s0sEIIVO2XHN9krN86snu0UEjnkkg+dz8AOg7ipEGSB/kwqFiho KqIu+SwrzN9yiZNLCkCyzvSeCpSWpz/q5qFeL/gFSW50OJ5vLkFUf7jWVWiV1h8rH9NW 2e3YijDy1Xk4pLEC8deXk4QVgUWYzND/+c8wdHwfAr9+SWLEgkfmdiSoFzy+VAhvdKs3 rrkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WWr1PqSX0XW3gKEagwG9KqBw0ANW4CA5Hu++5aMFc0Q=; b=N5I/dUuwMROjLeb1+q7L0QghCSoHtDJTyoglzAmDv2H1y/cQ4XM4pVLe6pR17Ziw/+ uZ2FbOuh4467J83xCV8P1M42VrYIkH2D0MkrMpx/gnDYcGDHePPYQwrJn9TMJK3NSYCG lSta2QOA6z+EbPNVyWBL+D7cJjWRUmX2nfmUkzPDnHX2jUih4xEYrL7gTlPKzgXmRmL6 yLn0wIMj5BbahBSTJXiG2DteQiT6YYHVeYYavb+WZKz7jOep+iMqLeM4HVHUN1wDjcjB AtLq2Fg9gWXaI+JU6QSoDIQqHY/AnvGsbzhB6JmiJhJqFknWoPa33JjFL+AvDhGkDSk5 F2Xg== X-Gm-Message-State: ANoB5pkckgQC1i5N33uVnE9w8ynPtyBPa3l7CxcqL9122+AtQ72HCTfT WE+AfRstQ+lj9AqG9EJmHrSN+w== X-Google-Smtp-Source: AA0mqf6axVhLd2j42H+bsV7jwSsywwmB54E555wFXmGaJaqlS7jqb2n8ErsqC/0eHomzzrk7ysXn7w== X-Received: by 2002:a05:622a:1928:b0:3a6:9c77:eb00 with SMTP id w40-20020a05622a192800b003a69c77eb00mr806900qtc.43.1670416270180; Wed, 07 Dec 2022 04:31:10 -0800 (PST) Received: from smtpclient.apple (pool-173-73-17-117.washdc.fios.verizon.net. [173.73.17.117]) by smtp.gmail.com with ESMTPSA id i21-20020a05620a405500b006f8665f483fsm17766149qko.85.2022.12.07.04.31.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2022 04:31:09 -0800 (PST) From: Cobenian Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_09FEA49D-7DD3-4C5C-A573-8A21686B91EC" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Date: Wed, 7 Dec 2022 07:30:58 -0500 In-Reply-To: Cc: RFC Errata System , tim@ripe.net, oleg@ripe.net, 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 To: Tom Harrison References: <20221104113812.3303455F68@rfcpa.amsl.com> X-Mailer: Apple Mail (2.3731.200.110.1.12) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2022 12:31:15 -0000 --Apple-Mail=_09FEA49D-7DD3-4C5C-A573-8A21686B91EC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I agree that the proposed errata would be a good clarification. Thanks, Bryan > On Dec 7, 2022, at 12:22 AM, Tom Harrison 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 >> >> 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 --Apple-Mail=_09FEA49D-7DD3-4C5C-A573-8A21686B91EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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.
"""

=46rom 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

= --Apple-Mail=_09FEA49D-7DD3-4C5C-A573-8A21686B91EC--