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].
<reference anchor="rpki-client" target="https://www.rpki-client.org/";>
<front>
<title>rpki-client</title>
<author fullname="Claudio Jeker"/>
<author fullname="Job Snijders"/>
<author fullname="Kristaps Dzonsons"/>
<author fullname="Theo Buehler"/>
<date month="July" year="2023" />
</front>
</reference>
<reference anchor="HOWTO"
target="https://sobornost.net/~job/using_geofeed_authenticators.txt";>
<front>
<title>Example on how to use rpki-client to authenticate a signed
Geofeed</title>
<author fullname="Job Snijders"/>
<date month="September" year="2023" />
</front>
</reference>
> > 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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
