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.
hmmmm. 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. hmmmm. 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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
