Apologies for taking so long to get back to these. I’ve gone ahead and posted
-15; -14 was about to expire. I suspect that there will be a -16 to address
changes that result from resolving #3-5 and #9.
spt
> On Nov 14, 2017, at 21:07, Sandra Murphy wrote:
>
> Well.
>
> The mail archive does not seem to show attachments. For me. I see do see
> attachments on other messages.
>
> It would be nice to know if anyone has seen attachments on my messages in the
> last few weeks.
>
> At any rate, for the mail archive, the comments are copied below the
> signature.
>
> —Sandy
>
>
> Points that might get lost in the long detailed list that follows:
>
> 1. RFC4271 (and RFC6286) and RFC8209 use the term “BGP Identifier”. The
> main text says RouterID and the Appendix B says “serial number”. I believe
> both are talking about what RFC8209 calls the “BGP Identifier”. Most of the
> tech sites say router ID or router-id or routerid or RID or some such. But I
> think consistency with the referenced text would be good.
#Sean: Changed throughout the draft to BGP Identifier and added a reference to
4271.
> 2. I was initially confused by the text in various places that talks about
> the operator adding the AS and RouterID (sic) and sends to the CA. I thought
> that meant the operator adds those to the CSR, which would be hard since the
> CSR is signed. This occurs a couple of places. I suggest a sentence early
> on that says the router certificate includes the AS and router identifier but
> the CSR does not include such fields, so the operator must include the AS and
> routerID when it sends the CSR to the CA.
#Sean: The setup section explains that the Operator either needs to configure
the AS and to configure/extract the BGP Identifier. These values are included
in the cert req; I guess the way I said they are added was confusing? I guess
in s5.1/s5.2 as opposed to saying the operator adds it should just say:
The PKCS#10 includes the chosen AS number and
BGP Identifier that the RPKI CA will certify.
> 3. “corresponds” - there are several places that say the certificate must be
> validated to prove that the public key corresponds with the private key. The
> main body does not say how that correspondence is validated. The appendix
> suggests that the operator could validate the signature on the CSR with the
> returned router cert in order to validate the key. (a) When the operator
> generated the public/private key pair, why not just do a comparison to the
> generated public key, presuming it was retained? (b) When the operator
> passed the CSR generated by the router to the CA, why not validate the public
> key before sending it to the CA? The public key in the returned router
> certificate could subsequently be validated by a comparison, presuming the
> public key was retained. (c) When the router is supposed to validate the
> public key of the router cert it receives, and the operator generated the
> public/private key pair, it does not have a copy of the CSR to validate the
> correspondence. Took me a bit to realize the router could sign just any old
> bit of bytes and then validate the signature with the received router cert.
> Right?
#Keyur: Ack on A and B. Sean and Randy Can u validate if that makes sense? On C
we should call this results in incorrect signing of “old bit of bytes”.
Assuming there is a key rollover period this should be okay as old keys could
be active?
#Randy: yes, if the router has both the private and alleged pubic keys, it
could sign a nonce and then verify it. but if you worry that the operertor is
lying to the router, she would be smart enough to give the router a
public/private pair which matches but is not the same as she negotited with the
CA. the router would have to make some sort of check with the CA, i.e. the
router would need the CA's public key or up-chain.
#Sean: So corresponds means that the public key in the certificate and private
key are actually a key pair, i.e., the public key can be used to validate a
signature generated with the private. In this draft we only do the check on
the returned certificate because the CA does the check on the certificate
submitted for certification; that bit is called POP or proof-of-possession.
Now you can do this by verifying any old signed bag-o-bits or the PKCS#10 and
if the RPKI package you used to generate the key pair supports it special
functions that do the verification. The check in s6 is done when the operator
does it to check that the CA didn’t screw up and send it the wrong cert; the
check in s7 covers both the router and operator generated cases because in the
former the router needs to the check because it made the request and in the
later the operator may have screwed up and sent the router the wrong cert. The
check is repeated in s8 and AppA because we’ll those sections are variations on
a theme. So, I was maybe a bit lazy wi
