Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
> On Sep 15, 2023, at 1:29 PM, Randy Bush wrote: > >> 1/ the new EE certificate uses an 'inherit' element in its RFC3779 >> extension, but section 5 disallows the use of 'inherit' in EEs. > > sigh. russ? Oops. I'll dig into it. > >> 2/ given that the example EE was refreshed in -01, the example >> Base64-encoded CMS signature (page 24) also must be refreshed. > > russ? I did refresh it. Randy did you pull it from my email? Regardless, it will need refreshed again to fix the above. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
>>> Ah, ok. For both RSC and RTA distinct properties are listed such as >>> "applicable in long run", "usable", "complex code"; if no comparison is >>> intended I'd just remove the two paragraphs about RTA & RSC. >> >> we seem to be at cross-purposes here. the point was not comparison at >> all. never has been. the point is two illustrations of signing. > > Yes, indeed both RTA and RSC can be used to sign arbitrary digital objects > through reference of their respective SHA256 message digest. But that > applies to any and all digital objects. :) > > Given that the Geofeed specification includes a build-for-purpose > methodology (which has running code), are references to other illustrations > of signing maybe somewhat of distraction? analohgously for your bag on the side of rpki-client? :)/2 randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
On Sat, 16 Sep 2023 at 02:29, Randy Bush wrote: > > Ah, ok. For both RSC and RTA distinct properties are listed such as > > "applicable in long run", "usable", "complex code"; if no comparison is > > intended I'd just remove the two paragraphs about RTA & RSC. > > we seem to be at cross-purposes here. the point was not comparison at > all. never has been. the point is two illustrations of signing. Yes, indeed both RTA and RSC can be used to sign arbitrary digital objects through reference of their respective SHA256 message digest. But that applies to any and all digital objects. :) Given that the Geofeed specification includes a build-for-purpose methodology (which has running code), are references to other illustrations of signing maybe somewhat of distraction? The current draft outlines in a good and detailed way how to authenticate a signed Geofeed file; on the other hand, the references to RSC or RTA leave a lot up in the air what exactly the workflow could/should be in context of Geofeed files. I think the Geofeed authenticator specification is superior to RTA and RSC, for the purpose of signing Geofeed files. Kind regards, Job ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
> target="https://sobornost.net/~job/using_geofeed_authenticators.txt;> > > Example on how to use rpki-client to authenticate a signed > Geofeed > > > > thanks >>> In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to >>> each other in a subjective manner about perceived complexity. >> >> a *comparison* was not intended, and i don't see it there. > > Ah, ok. For both RSC and RTA distinct properties are listed such as > "applicable in long run", "usable", "complex code"; if no comparison is > intended I'd just remove the two paragraphs about RTA & RSC. we seem to be at cross-purposes here. the point was not comparison at all. never has been. the point is two illustrations of signing. > 1/ the new EE certificate uses an 'inherit' element in its RFC3779 >extension, but section 5 disallows the use of 'inherit' in EEs. sigh. russ? > 2/ given that the example EE was refreshed in -01, the example >Base64-encoded CMS signature (page 24) also must be refreshed. russ? > 3/ might be good to suggest the use of one-time-use EE certs, perhaps: > >The CA MUST sign only one Geofeed with each generated private key and >MUST generate a new key pair for each new version of the Geofeed. An >associated EE certificate used in this fashion is termed a >"one-time-use" EE certificate (see Section 3 of [RFC6487]). MUST is not "suggest." perhaps SHOULD? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
Dear Randy, others,
On Tue, Sep 12, 2023 at 01:36:08PM -0700, Randy Bush wrote:
>
> ok, i am trying to make some time for this. thanks for the review!
>
> > In section 8 'Implementation Status', a reference could be added to
> > https://www.rpki-client.org/. I extended this RPKI validator
> > implementation to have the ability to cryptographically verify a given
> > RPKI-signed Geofeed authenticator. Yay, running code!
>
> cool. but may we please have a cite to how to use this for "Finding and
> Using Geofeed Data?"
Perhaps in section 8:
Support to authenticate Geofeed files using the RPKI [HOWTO] was
implemented in [rpki-client].
https://www.rpki-client.org/;>
rpki-client
https://sobornost.net/~job/using_geofeed_authenticators.txt;>
Example on how to use rpki-client to authenticate a signed
Geofeed
> > In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to
> > each other in a subjective manner about perceived complexity.
>
> a *comparison* was not intended, and i don't see it there.
Ah, ok. For both RSC and RTA distinct properties are listed such as
"applicable in long run", "usable", "complex code"; if no comparison is
intended I'd just remove the two paragraphs about RTA & RSC.
> how about
>
> The address range of the signing certificate MUST cover all
> prefixes on the geofeed file it signs. The certificate MUST NOT
> include the Autonomous System Identifier Delegation certificate
> extension [RFC3779].
>
> and, for good measure
>
>The end-entity certificate is issued by the CA. This certificate
>grants signature authority for one IPv4 address block (192.0.2.0/24).
>Signature authority for AS numbers is not needed for geofeed data
>signatures, so AS numbers MUST NOT be included in the certificate.
Perfect.
> > The example EE certificate in Appendix A erroneously contains a
> > superfluous Subject Information Access AccessDescription pointing
> > towards a RRDP server. RRDP SIA ADs are only expected to appear on CA
> > certificates, not on EE certs. See
> > https://www.rfc-editor.org/errata/eid7239 for more information.
>
> so remove
>
>SEQUENCE {
> OBJECT IDENTIFIER subjectInfoAccess
> (1 3 6 1 5 5 7 1 11)
> OCTET STRING, encapsulates {
> SEQUENCE {
> SEQUENCE {
>OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 13'
>[6]
> 'https://rrdp.example.net/notification.xml'
> }
>}
> }
> }
Yes, that's what I meant. Thanks.
> > I've prepared newly generated certificates which the authors could
> > consider using: https://git.rg.net/randy/draft-9092update/pulls/1/files
> > I also took the liberty to include a missing CRL, and update the example
> > from IPv4 to IPv6 :-)
>
> way too much hacking for my taste without adding clarity. e.g. how does
> an ipv6 sales pitch add clarity for the implementor or user? let's see
> what other authors think.
>
> or, to put it another way, what *minimal* change would add significant
> clarity? in this wg, we're not paid by the word :)
Yeah, apologies for the massive churn, but without the other private
keys I couldn't regenerate just the bits that needed updating. I wish
the original RFC included the CA's private key rather than the EE's
private key. :-)
In this context I have a few comments applicable to
draft-ietf-opsawg-9092-update-01
1/ the new EE certificate uses an 'inherit' element in its RFC3779
extension, but section 5 disallows the use of 'inherit' in EEs.
2/ given that the example EE was refreshed in -01, the example
Base64-encoded CMS signature (page 24) also must be refreshed.
3/ might be good to suggest the use of one-time-use EE certs, perhaps:
The CA MUST sign only one Geofeed with each generated private key and
MUST generate a new key pair for each new version of the Geofeed. An
associated EE certificate used in this fashion is termed a
"one-time-use" EE certificate (see Section 3 of [RFC6487]).
There indeed is no specific need to use IPv6 in the examples, but it is
important that the provided examples comply with the specification and
contain enough information for reproduction to sign & authenticate.
Let me know if any help is needed with the above.
Thanks!
Kind regards,
Job
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
ok, i am trying to make some time for this. thanks for the review!
> In section 8 'Implementation Status', a reference could be added to
> https://www.rpki-client.org/. I extended this RPKI validator
> implementation to have the ability to cryptographically verify a given
> RPKI-signed Geofeed authenticator. Yay, running code!
cool. but may we please have a cite to how to use this for "Finding and
Using Geofeed Data?"
> In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to
> each other in a subjective manner about perceived complexity.
a *comparison* was not intended, and i don't see it there.
> If anything, RFC9323 probably is simpler to implement (compared to
> RPKI-RTA), because of RFC9323's similarity to other pre-existing RPKI
> profiles. Both specifications facilitate RPKI signatures over a bare
> SHA256 digest, but RFC9323 also allows the signer to optionally
> include a filename (which could be a reference to the Geofeed file at
> hand). Multiple implementations exist. RPKI-RTA however appears to be
> an abandonded project, probably because the RTA proposal deviated
> significantly from RFC 6488, this deviation increases the burden on
> implementers because less previous implementation work can be
> leveraged.
>
> Suggestion: remove the RPKI-RTA reference, or perhaps just remove both
> RFC9323 and RPKI-RTA references, as the Geofeed specification itself
> already outlines a workable RPKI-based authenticator.
h. these were intended as cites to usable protocol and code to
implement signing and verifying the authenticated files; a bit more
direct, but analogous to your suggestion to cite rpki-client code.
so maybe the cites are useful but not deeply necessary. otoh, moving to
Implementation Status seems inappropriate, as it's not really
implementation or status. h. let's see what other authors think.
> It would be helpful if the specification provides clarity to
> implementers by mandating that the Autonomous System Identifier
> Delegation certificate extension MUST be absent. ASNs are not used in
> Geofeed data, and thus such an extension would serve no purpose on the
> Geofeed EE certificate. Other RPKI profile specifications nowadays are
> very specific about which of the RFC 3779 extensions are expected to be
> present or absent.
how about
The address range of the signing certificate MUST cover all
prefixes on the geofeed file it signs. The certificate MUST NOT
include the Autonomous System Identifier Delegation certificate
extension [RFC3779].
and, for good measure
The end-entity certificate is issued by the CA. This certificate
grants signature authority for one IPv4 address block (192.0.2.0/24).
Signature authority for AS numbers is not needed for geofeed data
signatures, so AS numbers MUST NOT be included in the certificate.
> The example EE certificate in Appendix A erroneously contains a
> superfluous Subject Information Access AccessDescription pointing
> towards a RRDP server. RRDP SIA ADs are only expected to appear on CA
> certificates, not on EE certs. See
> https://www.rfc-editor.org/errata/eid7239 for more information.
so remove
SEQUENCE {
OBJECT IDENTIFIER subjectInfoAccess
(1 3 6 1 5 5 7 1 11)
OCTET STRING, encapsulates {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 13'
[6]
'https://rrdp.example.net/notification.xml'
}
}
}
}
> I've prepared newly generated certificates which the authors could
> consider using: https://git.rg.net/randy/draft-9092update/pulls/1/files
> I also took the liberty to include a missing CRL, and update the example
> from IPv4 to IPv6 :-)
way too much hacking for my taste without adding clarity. e.g. how does
an ipv6 sales pitch add clarity for the implementor or user? let's see
what other authors think.
or, to put it another way, what *minimal* change would add significant
clarity? in this wg, we're not paid by the word :)
again, thanks for review.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
> please resubmit this draft as draft-ietf-opsawg-9092-update-00 > replacing draft-ymbk-opsawg-9092-update. Do not make any other > changes to the document text. done. thanks. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
The CfA on this document has concluded. The comments received were supportive of the work, and the chairs feel the implementation thus far shows value in continuing its evolution. We hope this can proceed quickly. Authors, please resubmit this draft as draft-ietf-opsawg-9092-update-00 replacing draft-ymbk-opsawg-9092-update. Do not make any other changes to the document text. Thanks. Joe From: Joe Clarke (jclarke) Date: Monday, August 7, 2023 at 15:46 To: opsawg@ietf.org Subject: CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update Coming out of 117, there was an action to put the 9092bis document up for WG adoption. The authors have all responded that there is no known IPR pertaining to this document. This document is an update to the guidelines for finding and using geofeed data. Therefore, we would like to start a two week CfA for https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/. Please reply on-list with your comments and whether or not you support working on this document. The CfA will run until EOD on August 21, 2023. Thanks. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
Hi all, > Coming out of 117, there was an action to put the 9092bis document up > for WG adoption. The authors have all responded that there is no > known IPR pertaining to this document. This document is an update to > the guidelines for finding and using geofeed data. > > Therefore, we would like to start a two week CfA for > https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/. > Please reply on-list with your comments and whether or not you support > working on this document. The CfA will run until EOD on August 21, > 2023. TL;DR - I support adoption of this document. A few suggestions for improvement of the document: 1/ In section 8 'Implementation Status', a reference could be added to https://www.rpki-client.org/. I extended this RPKI validator implementation to have the ability to cryptographically verify a given RPKI-signed Geofeed authenticator. Yay, running code! 2/ In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to each other in a subjective manner about perceived complexity. If anything, RFC9323 probably is simpler to implement (compared to RPKI-RTA), because of RFC9323's similarity to other pre-existing RPKI profiles. Both specifications facilitate RPKI signatures over a bare SHA256 digest, but RFC9323 also allows the signer to optionally include a filename (which could be a reference to the Geofeed file at hand). Multiple implementations exist. RPKI-RTA however appears to be an abandonded project, probably because the RTA proposal deviated significantly from RFC 6488, this deviation increases the burden on implementers because less previous implementation work can be leveraged. Suggestion: remove the RPKI-RTA reference, or perhaps just remove both RFC9323 and RPKI-RTA references, as the Geofeed specification itself already outlines a workable RPKI-based authenticator. 3/ It would be helpful if the specification provides clarity to implementers by mandating that the Autonomous System Identifier Delegation certificate extension MUST be absent. ASNs are not used in Geofeed data, and thus such an extension would serve no purpose on the Geofeed EE certificate. Other RPKI profile specifications nowadays are very specific about which of the RFC 3779 extensions are expected to be present or absent. 4/ The example EE certificate in Appendix A erroneously contains a superfluous Subject Information Access AccessDescription pointing towards a RRDP server. RRDP SIA ADs are only expected to appear on CA certificates, not on EE certs. See https://www.rfc-editor.org/errata/eid7239 for more information. I've prepared newly generated certificates which the authors could consider using: https://git.rg.net/randy/draft-9092update/pulls/1/files I also took the liberty to include a missing CRL, and update the example from IPv4 to IPv6 :-) In Closing/ Thanks for taking the time and effort to cross some t's and dot some i's on the Geofeed specification! Kind regards, Job ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
I support adoption. This is a worthwhile update, its very simple and direct. Wider use of Geofeed would be net-beneficial for understanding how IP addresses are deployed, and who better to state that than the delegate with an ability to prove their locus of control with a signature? Sure, they can chose to misdirect. That will have consequences, especially if they sign it. -G ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
Speaking as a contributor and one who reviewed both the current draft as well as the previous, I support the adoption of this, and I appreciate the modifications to the implementation status section, as well as the clarity around when to use the geofeed: and remarks: attributes. I do wonder if the new text pertaining to geofeed files only being CSV (Section 2) could be simplified with normative language: Per [RFC8805], geofeed files MUST only consist of CSVs in UTF-8 text format. Joe From: OPSAWG on behalf of Joe Clarke (jclarke) Date: Monday, August 7, 2023 at 15:47 To: opsawg@ietf.org Subject: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update Coming out of 117, there was an action to put the 9092bis document up for WG adoption. The authors have all responded that there is no known IPR pertaining to this document. This document is an update to the guidelines for finding and using geofeed data. Therefore, we would like to start a two week CfA for https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/. Please reply on-list with your comments and whether or not you support working on this document. The CfA will run until EOD on August 21, 2023. Thanks. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
Coming out of 117, there was an action to put the 9092bis document up for WG adoption. The authors have all responded that there is no known IPR pertaining to this document. This document is an update to the guidelines for finding and using geofeed data. Therefore, we would like to start a two week CfA for https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/. Please reply on-list with your comments and whether or not you support working on this document. The CfA will run until EOD on August 21, 2023. Thanks. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
