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

2022-08-22 Thread Ties de Kock 
Hi Tim, all,

> On 22 Aug 2022, at 10:29, Tim Bruijnzeels  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 > > 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 
>>  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 
>> 
>> 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 
>>

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

2022-08-22 Thread Ben Maddison 
Hi Tim,

On 08/22, Tim Bruijnzeels 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.

The only one I checked was routinator/rpki-rs, which looks like it
already does "the right thing":

https://github.com/NLnetLabs/rpki-rs/blob/f1274c838eb05a39271db5bbb63cd70d706ec27b/src/slurm.rs#L489

I haven't checked any others, and I agree that it would be helpful if
implementors indicate whether this would be a breaking change for them.

Cheers,

Ben


signature.asc
Description: PGP signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

2022-08-22 Thread Tim Bruijnzeels 
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.

Tim

> On 21 Aug 2022, at 17:57, Warren Kumari  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 
>  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 
> 
> 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
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

2022-08-21 Thread Warren Kumari 
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 
>
> 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
https://www.ietf.org/mailman/listinfo/sidr

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

2022-08-10 Thread Ben Maddison 
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 
> 
> 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


signature.asc
Description: PGP signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr