> Identifying the private key associated with the certificate, and > getting the department with the HSM to sign the CMS blob is left as > an exercise for the implementor.
This cynical comment jumped out at me.
It seems that you don't have a lot of confidence that the key will be easily
used.
As I understand it, you are not creating the geofeed: attribute, but instead
shoving a URL into a "remark". (Wasn't JCL afflicted by endless hacks like
this?)
(I don't see an IANA Considerations in RFC2622... so many you have to Updates?)
I gather from my quick reading that the geofeed data should be signed by the
same RPKI key, and that such keys are rather high value.
Should they be signing geofeed data?
I understand RFC8805 to be a simple CSV format.
One thought I have is to just stuff that into the "remark" directly.
I think that each inetnum:/inet6num: entry will be unique per prefix.
Maybe the geography is not 1:1, particularly with larger IPv6 allocations.
But, if the HTTP(S) indirection via URL requires a signature from the same
key as the RPSL signature, then why not just put a SHA256 hash into the
remark, eliminating the need to find the private key?
That way, the same person with access signs both?
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
