Re: [sidr] [Technical Errata Reported] RFC8416 (7080)

[Ties de Kock <[e-mail]>]

Hi Tim, all,

> On 22 Aug 2022, at 10:29, Tim Bruijnzeels <[e-mail]> wrote:
> 
> Hi Warren, all,
> 
> I (co-author) agree that this was an oversight. I have no objections to the change.
> 
> However.. I haven't checked, but beware that current implementations might fail to parse the file if a "comment" member is added here, if they are (overly) strict. I expect that most will simply ignore this member. Perhaps it's wise that this is verified before finalising the errata.

I checked two implementations. The (archived) RIPE NCC validator accepts a
comment field in bgpsecAssertions. StayRTR does not parse the bgpsecAssertions
structure and I expect it to ignore additional attributes.

However, if there are any compliant implementations, following section 3.1,
they would not accept a file that incorporates that follows the change proposed
in this erratum:

> ... An RP MUST consider any deviations from the specifications to
> be errors.

I think we need to keep this in mind when discussing this erratum.

Kind regards,
Ties
> 
> Tim
> 
>> On 21 Aug 2022, at 17:57, Warren Kumari <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> Dear SIDROPS, at al,
>> 
>> I believe that this Errata is correct, and I intends to mark it Verified unless I hear a clear objection by this Friday (August 26th).
>> 
>> W
>> 
>> 
>> 
>> On Wed, Aug 10, 2022 at 5:25 PM, Ben Maddison <benm=[e-mail]> wrote:
>> Adding sidrops@
>> 
>> On 08/10, RFC Errata System wrote:
>> 
>> The following errata report has been submitted for RFC8416, 
>> "Simplified Local Internet Number Resource Management with the RPKI (SLURM)".
>> 
>> -------------------------------------- 
>> You may review the report below and at: 
>> https://www.rfc-editor.org/errata/eid7080
>> 
>> -------------------------------------- 
>> Type: Technical 
>> Reported by: Ben Maddison <[e-mail]>
>> 
>> Section: 3.4.2
>> 
>> Original Text 
>> ------------- 
>> The above is expressed as a value of the "bgpsecAssertions" member, as an array of zero or more objects. Each object MUST contain one each of all of the following members:
>> 
>> o An "asn" member, whose value is a number.
>> 
>> o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
>> 
>> o A "routerPublicKey" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the equivalent to the subjectPublicKeyInfo value of the router certificate's public key, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
>> 
>> Corrected Text 
>> -------------- 
>> The above is expressed as a value of the "bgpsecAssertions" member, as an array of zero or more objects. Each object MUST contain one each of all of the following members:
>> 
>> o An "asn" member, whose value is a number.
>> 
>> o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
>> 
>> o A "routerPublicKey" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the equivalent to the subjectPublicKeyInfo value of the router certificate's public key, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
>> 
>> In addition, each object MAY contain one optional "comment" member, whose value is a string.
>> 
>> Notes 
>> ----- 
>> The "comment" member is allowed to appear in every other structure defined by the document, and was clearly intended to be allowed here too, since it appears in the examples presented in sections 3.4.2 and 3.5
>> 
>> 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.
>> 
>> -------------------------------------- 
>> RFC8416 (draft-ietf-sidr-slurm-08) 
>> -------------------------------------- 
>> Title : Simplified Local Internet Number Resource Management with the RPKI (SLURM) Publication Date : August 2018 
>> Author(s) : D. Ma, D. Mandelberg, T. Bruijnzeels Category : PROPOSED STANDARD 
>> Source : Secure Inter-Domain Routing 
>> Area : Routing 
>> Stream : IETF 
>> Verifying Party : IESG
>> 
>> _______________________________________________ 
>> sidr mailing list 
>> [e-mail] 
>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> 
>> _______________________________________________
>> sidr mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/sidr <https://www.ietf.org/mailman/listinfo/sidr>
> 
> _______________________________________________
> sidr mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sidr <https://www.ietf.org/mailman/listinfo/sidr>