Michael: >> We went down this with RFC9632. Would an informational reference help here? >> "This document adopts the same incremental deployment process as was done for >> geofeed data in [RFC9632]" ?
Suggestion: OLD: This document also suggests an optional signature to strongly authenticate the data in the prefixlen files. NEW: This document also suggests an optional signature to strongly authenticate the data in the prefixlen files. The same approach to signatures is used in this document was was used in [RFC9632]. >> Section 5 about WHOIS data suggests FTP over WHOIS. >> Given that there are ~5 RIRs, I guess the choice of FTP,WHOIS,RDAP can be >> made by a human... I'm not sure, but I do not think you are asking for a change here. >> Is a canonicalization process really important for the signature? >> Why not just CMS-detached-sign whatever the series of bytes present is? >> It's not like HTTPS has the TXT/BIN issue that FTP had. >> I guess that this is identical to RFC9632, and I suggest noting that. >> I see that an eContentType is allocated, which is good. >> It should be mentioned in section 6, paragraph 6, along with the rest of the >> details. >>> The signing certificate MUST NOT include the Autonomous System >>> Identifier Delegation certificate extension [RFC3779]. If it is >>> present, the authenticator is invalid. >> I think the point here is not to use your RPKI certificate to sign? An RPKI certificate is used, but it is an EE that is just for the one signature. >>> The Certification Authority (CA) SHOULD sign only one prefixlen file >>> with each generated private key and SHOULD generate a new key pair >> But, CAs do not sign prefixlen files. They sign EEs that sign them, right? Correct, this is how the AS gets dropped out if the CA cert has one. >>> Identifying the private key associated with the certificate and >>> getting the department that controls the private key (which might be >>> stored in a Hardware Security Module (HSM)) to generate the CMS >>> signature is left as an exercise for the implementor. >> This adds nothing, and just confuses. Remove it. >> The amount of detail about the verification process seems excessive. >> Is it needed, as it all just seems like normal CMS stuff. I am fine with dropping those words. Russ _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
