Hi Tim, all, > On 22 Aug 2022, at 10:29, Tim Bruijnzeels <t...@nlnetlabs.nl> 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 <war...@kumari.net >> <mailto:war...@kumari.net>> 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=40workonline.afr...@dmarc.ietf.org> 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 <benm@workonline.africa> >> >> 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 >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org <mailto:sidr@ietf.org> >> https://www.ietf.org/mailman/listinfo/sidr >> <https://www.ietf.org/mailman/listinfo/sidr> > > _______________________________________________ > sidr mailing list > sidr@ietf.org <mailto:sidr@ietf.org> > https://www.ietf.org/mailman/listinfo/sidr > <https://www.ietf.org/mailman/listinfo/sidr>
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
