Hi, This looks reasonable to me, but I can’t speak really to the router implementation - being neither a network operator nor a router vendor. As a CA operator I note that the draft is not restrictive about exactly how the RPKI CA gets the CSR, and the signed certificate is returned. That’s a good thing to me at this point, so I would say ship it. But I believe it would be good to keep this in mind in the sidr-ops WG - if this proves operationally difficult then it may be something to discuss further later.
Tim > On 3 Oct 2017, at 05:14, Christopher Morrow <christopher.mor...@gmail.com> > wrote: > > WG Folk, > I thought I had sent this note our previously, but... better late then never > sent: > > Please consider this the WGLC for: > https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-13 > > Abstract: > "BGPsec-speaking routers are provisioned with private keys in order to > sign BGPsec announcements. The corresponding public keys are > published in the global Resource Public Key Infrastructure, enabling > verification of BGPsec messages. This document describes two methods > of generating the public-private key-pairs: router-driven and > operator-driven." > > Please send along comments/complaints/issues/kudos (to the authors), to the > list and I'll see you all in ~14 or so days. > > Thanks! > -chris > co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
