Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt)

[Sean Turner <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Wellllll.
> 
> 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 with respect to how to ensure the two keys correspond to each other, but there’s a number of ways to do it and it depends on what you got installed.  I guess I just need to know how much more you want and where to put it because I’d rather not repeat all of this four times.

> 4.  “corresponds” again - there’s no mention of a router verifying that the router cert it receives has an AS that is configured on the router.  There are lots of other checks and double checks - why not this one?  And if the router has multiple ASs and multiple CSRs have been generated (either by the router or by the operator), then the router uses the received router certificate to associate the AS with the public/private key pair, so it knows which private key to use over which session.  Right?

#Keyur: Yep.

#Sean: Sure we can add that check.  Can I put all of this in s6 and then refer the other sections back to this section so it’s not repeated?

> 5.  Section 8 on “Advanced Deployment Scenarios” talks about routers that already have pre-installed keys (with mentions of types of crypto that are not known to me, and I did not dig up the refs, so I might be missing something here).  The first paragraph talks about “pre-installed key material”.  I could understand why these pre-installed keys might be useful in authenticating the router directly to the CA.  The “burdens” 1 and 2 also talk abut “key material”.  It did not look to me like the “key material” in 1 and 2 are talking about these “pre-installed” keys.  But I admit to being very confused by the way the term is used.

#Sean: The ADS section was to appease Max; it’s the paragraph that’s not like the others.  His point was that hopefully in the not to distant future you router will come pre-installed with goodies from the manufacturer.  At the top of that list are keys either asymmetric (IEEE AR certificates) or symmetric (Pre-Shared Keys); these keys can be used to authenticate the router to the management station or the CA.  But, you still have to get the keys from the router to the management station/CA and if this is all going to happen automagically then you need to make sure the router can talk to the CA; these are bullets 1 and 2.  After that, it’s easy-peasy (or so we hope) ;). Make more sense?

> 6.  Section 5.2.1 is titled ”Using PKCS#8 to Transfer Public Key”.  The text talks about using PKCS #8 in RFC5958, which allows for including both the public and private key.  But the text of that section is talking about using PKCS #8 to transmit the private key to the router.  I presume the title should be Using PKCS#8 to Transfer Private Key

#Keyur: Should be fixed.

#Sean: p2f (palm-to-face) - fixed

> 7.  There is an early assumption that all the communication between the operator and the router is over a protected channel.  Section 5.2.1 suggests using a CMS SignedData to transmit the PKCS#8.  RFC5958 suggests several different “CMS protecting content types” for the PKCS#8 - EncryptedData, EnvelopedData, etc.  I presume that the encrypted versions are not used here because the protected channel ensures confidentiality.  So (a) Appendix A talks about the key strength to be used for the different crypto algorithms (encryption, key exchange, …).  That’s a big hint that the channel should provide the related security protections.  I think it would be good to explicitly state the protections the protected channel must provide: “The protected channel must provide confidentiality, authentication, integrity and replay protection”.  (b) if the protected channel provides authentication and integrity, why is the protection of the CMS SignedData needed?  One possible reason follows -> (c) The AS EE certificate has an AS extension, not an IP extension, I presume.  So the AS EE certificate would be a second way for the router to associate a private key with an AS and an appropriate BGP session (see my comment 3c above).  But this applies only when the operator generated the public/private key pair.

#Keyur: Agree on incorporating the suggestion

#Sean: So no problem adding the requirements on the protected channel.  What might help in the understanding here is that the PKCS#7s that are returned from the CA are the so called certs-only messages, i.e., there’s no content so no sig only the cert-bag.  The other uses of CMS SignedData to protect the private key (s5.2.1) is just good security so that the router will know that the key came from somebody it trusts, i.e., the operator; also not it’s a “should”.

> 8.  PKCS#7 needs a reference.  I looked at RFC2315.  RFC2315 defines several types of content, e.g., signed-data, enveloped-data, signed-and-enveloped-data, etc.  Is there any reason to specify which type?  Is it operator choice?

#Keyur: Should be left to an operator.

#Sean: The reference is there in s3 for application/pkcs7-mime, but I can add it next to PKCS#7 as well.  As noted in response to q7, the PKCS#7 is a certs-only message.  I’ll point to 5751bis, which is in IETF LC right now so should be done before this.

> 9.  The term “operator” is used to talk about carbon-based units (who are forgetful), ISP organizations (who peer with other operators), ASs (who have an AS EE certificates) and management system stations (that receive CSRs from the router).  It was a bit unsettling, but after multiple reads through I’m getting used to it.  I’m not sure I could suggest a term that would fit all those uses.  Perhaps network operators (the ones with DNA) identify personally with all those uses and think of their person in all cases.  “I am the AS”, “I am the peering entity”, “I am the management of the network”, etc.

#Keyur: Ok by me to replace operator with network operators.

#Sean: I just don’t see how adding this qualifier helps; I think folks pretty quickly ought to be able to catch on that we’re talking about the folks who press buttons on a computer to make stuff happen.  Are we also renaming the “operator-driven” model?

> 10.  I do not understand the last two paragraphs of section 7 at the bottom of page 6.  It sounds to me like they are out of place, like they belong elsewhere in the text.

#Keyur: I would leave them there.

#Sean: I’m hoping we can just leave them there too.

> 11.  There are some occurrences of “must” and only a few of “MUST” - the draft is standards track, so how much of the described behaviors are mandatory?

#Keyur: Will let Randy Chime in here.

#Randy: i do not believe these were accidents.  i am really careful with MUST.  examples would be helpful.

#Sean: Very little actually.  This is a choose your own PKI adventure kind of draft it’s not a protocol draft.  We can’t say you must do it this way or that way because there’s plenty of ways to do it and the options available to you are entirely dependent on what router you’re using.

> 12. Some consistency nits - PKCS sometimes followed by a space, sometimes not.  protected channel, secure channel, communications channel, protected session, SSH session, . . .  

#Keyur: Lets fix them.

#Sean: I will try, but I am sure the RFC editor will do a much better job than I will in catching all of the inconsistencies.

> ========================================
> 
> OK, so on to the detailed comments, sequentially through the document
> 
> p3, section 1:
> 
>   two methods to provision new and existing routers.  The methods
>   described involve the operator configuring the two end points and
>   acting as the intermediary.
> 
> What are the two endpoints?  The router and the management station?  The router and the CA?  I can imagine the operator configuring the management station, but not the CA.  I can imagine the operator acting as the intermediary between the router and the CA, but not between the router and the management station.

#Keyur: I interpret as management station and the router. We should clarify it Sean.

#Sean: Yep management station and router.

> p3, section 1: (nit)
> 
>                                                   [RFC8208]
>   specifies the algorithms used to generate the signature.
> 
> If I read correctly, “the” signature in this text would be the signature on the PKCS#10.  
> 
> suggest:
> 
>                                                  [RFC8208]
>   specifies the algorithms used to generate the PKCS#10 signature.

#Keyur: Ack. Text to be incorporated.

#Sean: Minor tweak r/PKCS#10/PKCS#10’s

> p4, section 2
> 
>                           See Appendix A for security considerations
>   for this channel.
> 
> I think it is important to say what security protection are required for this protected channel.
> Appendix A talks about the strength of the key used in the various crypto algorithms.  I think a
> sentence something like the following would be useful here or in Appendix A.
> 
> “The protected channel must provide confidentiality, authentication, integrity” and replay protection.”

#Keyur: Ack. Text to be incorporated.

#Sean: Incorporated.

> p4, section 4 (nit)
> 
>   appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router.
> 
> suggest:
> 
>   appropriate RPKI Trust Anchor Certificate (TA Cert) in the router.
> or
>   appropriate RPKI Trust Anchor’s Certificate (TA Cert) in the router.

#Keyur: IMHO its later!!

#Sean: Incorporated.

> p4, section 4
> 
>   The operator also configures the Autonomous System (AS) number to be
>   used in the generated router certificate.  This may be the sole AS
>   configured on the router, or an operator choice if the router is
>   configured with multiple ASs.
> 
> There’s a hint here that the operator configures the router to generate just one router certificate.
> RFC8209 allows the router certificate to have one or more ASs, but recommends that there be multiple router certificates with one AS each.  Does this paragraph intend to limit a router to one router certificate or just to limit the router to one AS per router certificate?  I have questions later about what happens if the router wants a router certificate for each of multiple ASs.
> 
> Perhaps “A router with multiple ASs can be configured with multiple router certificates”, maybe also “by following the process of this document for reach desired certificate”.
> 
>   The operator configures or extracts from the router the BGP RouterID

#Keyur: Ack. Text to be incorporated.

#Sean: Added to the end of the 2nd para.

   The operator configures or extracts from the router the BGP RouterID ...

> RFC4271 and RFC8209 say “BGP Identifier”.  OSPF uses RouterID, and lots of C/J commands use RouterID, or router-id, or router id, or RID, or . . .  But consistency with the referenced specs would a good thing.

#Sean: It’s now BGP Identifier throughout.

> p4, section 5
> 
> I think it would be great to add a sentence here explaining that the PKCS#10 (CSR) format does not include the AS and RouterID (sic).  Therefore, the operator must transmit the AS and RouterID (sic) as well when it sends the CSR to the CA.  

#Keyur: Ack. Text to be incorporated.

#Sean: Text added, but I already thought it was in both sections.

> That sentence applies to both the router generated keys and the operator generated keys, so maybe it could go here.
> 
> The PKCS#10 format does not include the AS and RouterID for the router certificate.  Therefore, the operator must include the AS it has chosen for the router and the RouterID when it sends the CSR to the RPKI CA.
> 
> That should be a MUST, shouldn’t it?

#Sean: Okay so it took me forever to figure out that this is text you’re proposing not something the draft.  No I don’t think it has to be MUST, the operator could send it via carrier pigeon or in some other email.  So how about:

   The PKCS#10 format does not include the AS and
   RouterID for the router certificate.  Therefore, the
   operator transmits the AS it has chosen for the router
   and the RouterID when it sends the CSR to the RPKI CA.

> p5, section 5.1
> 
>   The operator adds the chosen AS number and the RouterID to send to
>   the RPKI CA for the CA to certify.
> 
> My first reading was that the text meant the AS and RouterID were added to the CSR.  First, that’s not possible because of the signature, unless there’s some key sharing going on.  Second, that’s not possible because the CSR format does not include the AS and RouterID.  Hence my comment above.
> 
> suggest:
> 
>   The operator includes the chosen AS number and the RouterID when it sends the CSR to

#Keyur: Ack. Text to be incorporated with RouterID replaced by BGP Identifier.

#Sean: Sure, include is a synonym for add ;)

> p4, section 5.1 (nit)
> 
>   NOTE: If a router was to communicate directly with a CA to have the
> 
> suggest:
> 
>   NOTE: If a router were to communicate directly with a CA to have the
> 
> p5, section 5.2
> 
>   and adds the chosen AS number and RouterID to be sent to the RPKI CA
>   for the CA to certify.
> 
> suggest:
> 
>   and includes the chosen AS number and the RouterID when it sends the CSR to the RPKI CA
>   for the CA to certify.

#Keyur: Ack. Text to be incorporated with RouterID replaced by BGP Identifier.

#Sean: Sold!

> p5, section 5.2.1
> 
> section title “Using PKCS#8 to Transfer Public Key”
> 
> PKCS#8 in RFC5958 can transfer public keys.  But the following text is talking about transferring the private key to the router.  
> 
> I think this title should be “Using PKCS#8 to Transfer Private Key”
> 
> 
>   A private key encapsulated in a PKCS #8 [RFC5958] should be further
>   encapsulated in Cryptographic Message Syntax (CMS) SignedData
>   [RFC5652] and signed with the AS's End Entity (EE) private key.

#Keyur: Ack. Text to be incorporated.

#Sean: Incorporated.

> Would “A private key encapsulated in a PKCS #8” be followed by "OTOH, a private key that is not encapsulated in a PKCS#8”?  :-)
> 
> Suggest:
> 
>   A private key can be encapsulated in a PKCS #8 [RFC5958] and should be further
>    (or “is” encapsulated or “should be” encapsulated) 

#Keyur: Ack. Text to be incorporated.

#Sean: Incorporated.

> Section 3 suggests various ways to “exchange PKI-related information with routers”.  Is this PKCS#8 just one more way, or is it the recommended way?  The intro to section 5 suggests that copy and paste could also be used, but doesn’t say if that would be copy and paste of the PKCS#8.  If Section 5 is also talking about straight copy and paste of the hex or the PEM block, then that’s another alternative.
> 
> RFC5958 discusses several “CMS protecting content types” to protect the AsymmetricKeyPackage.  I presume that the encryption/enveloping content types are not needed because confidentiality is being provided by the protected channel.  But then why use the CMS SignedData - would not the protected channel provide the authentication and integrity needed?  (But see potential reason below)
> 
> 
>   [RFC5652] and signed with the AS's End Entity (EE) private key.
> 
> Does it matter which AS’s EE cert the operator uses to sign the PKCS#8?  I presume that the AS must match an AS with which the router is configured.  Should the router check that?  Does a router that is configured with multiple ASs use this communication to tie the private key to the appropriate AS & BGPsec session?  
> 
> If the answer is yes to both questions, should those actions be mentioned here?
> 
> (I admit to being a bit dizzy here, but maybe the mapping of private key to AS happens in the receipt of the router certificate.)  
> 
>   include in the SignedData the RPKI CA certificate and relevant AS's
>   EE certificate(s).  
> 
> Maybe this is the reason for using the SignedData - to be able to include the AS’s EE cert and give the router the means to tie the private key to the right AS.
> 
>   The router SHOULD verify the signature of the encapsulated PKCS#8 to
>   ensure the returned private key did in fact come from the operator,
> 
> Then shouldn’t it be signed with the operator’s personal cert?  :-)  
> 
>   include in the SignedData the RPKI CA certificate and relevant AS's
>   EE certificate(s).
> 
> Elsewhere (sections 6 & 7) it mentions including the entire cert chain.  Should that be mentioned here as well?

#Keyur: Think we discussed this point earlier.

> p5, section 6 (nit)
> 
>   The operator uses RPKI management tools to communicate with the
>   global RPKI system to have the appropriate CA validate the PKCS#10
>   request, sign the key in the PKCS#10 (i.e., certify it) and generated
>   PKCS#7 response, as well as publishing the certificate in the Global
>   RPKI.
> 
> for symmetry, suggest:
> 
>   The operator uses RPKI management tools to communicate with the
>   global RPKI system to have the appropriate CA validate the PKCS#10
>   request, sign the key in the PKCS#10 (i.e., certify it) and generate a
>   PKCS#7 response, as well as publish the certificate in the Global
>   RPKI.

#Sean: Incorporated.

> p5, section 6 
> 
>          External network connectivity may be needed if the certificate
>   is to be published in the Global RPKI.
> 
> The previous sentence and the following paragraph do not hint that there is any “if” about the publication of the certificate.  Is there a case where the certificate is NOT “to be published in the Global RPKI”?

#Keyur: VPNs? Multiple ASs under same admin domain. Would leave the line as is.

#Sean: It should stay based on RFC6484:

   Each CA MUST maintain a
   publicly accessible online repository and publish all RPKI-signed
   objects (intended for public consumption) via this repository in a
   manner that conforms with "A Profile for Resource Certificate
   Repository Structure" [RFC6481].

> p6, section 6 (nit)
> 
>   2.  Returns the certificate to the operator's management station,
>       packaged in a PKCS#7
> 
> Needs a reference.  RFC2315?

#Sean: Nope - I-D.lamps-rfc5751-bis, but I think that and adding PKCS#7 certs-only message ought to clear this up.

>   In the operator-generated method, the operator SHOULD extract the
>   certificate from the PKCS#7, and verify that the private key it holds
>   corresponds to the returned public key.
> 
> “it” means the operator, right?

#Keyur: Yep.

> You get to Appendix B before the verification of the correspondence is explained.  I think it should be explained here.
> 
> The Appendix B says the operator should verify the signature on the PKCS#10 CSR to verify the correspondence.  But the operator generated the key - can’t the correspondence be verified by checking the certificate’s public key against the operator generated public key (presuming the key was retained)?  That seems too easy - I fear I am missing some important part here.

#Sean: Yes, but there’s more than one way to do that as discussed earlier.  I’m hoping the tweaks to s6 as mentioned earlier clears this up.

> p6, section 7
> 
>   The router SHOULD extract the certificate from the PKCS#7 and verify
>   that the public key corresponds to the stored private key. 
> 
> I think more needs to be said about how the correspondence would be verified. 
> 
> Appendix B says the operator should verify the signature on the PKCS#10 with the certificate to verify the correspondence to the private key.  That would work for the router as well if the router generated the PKCS#10, but not if the operator generated the key pair and the PKCS#10.  But the router could sign any random bunch of bits and verify the signature with the certificate to verify the correspondence.  Should those things be said?
> 
> Also, in the router-driven method, the router can verify the correspondence simply by matching the certificate’s public key with one of the router’s stored public keys.  (Right?  What am I missing here?)
> 
> Should the router also verify that the AS mentioned in the returned router certificate is an AS with which it is configured?
> 
> For a router that is configured with multiple ASs, is this where the router ties the private key to the AS & BGPsec session with which the private key should be used?

#Keyur: In general for multiple AS it should have private key association with each AS. The keys could overlap or be different?

#Sean: I think we got a fix, if we can figure out where to put the text that says there’s a bunch of ways to do this and just point to it so that it’s not repeated everywhere.

> The last two paragraphs of section 7 confuse me.
> 
>   Even if the operator cannot extract the private key from the router,
>   this signature still provides a linkage between a private key and a
>   router.  That is the operator can verify the proof of possession
>   (POP), as required by [RFC6484].
> 
> What is “this signature”?  And there’s been no mention in this section of extracting the private key from the router.
> 
> This sounds to me like it belongs in section 5.1, maybe after: 
>                                                               “to sign
>   the PKCS#10 with the private key.  Once generated, the PKCS#10 is
>   returned to the operator over the protected channel.
> 
> And then:
> 
>   NOTE: The signature on the PKCS#8 and Certificate need not be made by
>   the same entity.  Signing the PKCS#8, permits more advanced
>   configurations where the entity that generates the keys is not the
>   direct CA.
> 
> Maybe this belongs in section 5.2.1 where it is talking about the PKCS#8?
> 
> Even so, I’m not sure what Certificate this text references.  The AS EE cert?
> 
> Both the router-driven method and the operator-driven method are not the direct CA.  Nowhere in this draft does it mention the CA generating the keys.  So the entire draft is one of these “advanced configurations”.  What am I missing here?
> 
> p7, section 8 (nit)
> 
>   Transport" [RFC7030] or the original CMC transport protocol's
> 
> Is the possessive really needed here?  I didn’t peruse the RFC5273 thoroughly, but I can see that it defines a number of transport methods, so maybe there is a “CMC transport protocol’s X” missing here.

#Sean: I leave this to the RFC editor to suggest the right way to do this.  I don’t think it’s confusing or even wrong to do this.

> p7, section 8
> 
> 
> This section uses “key material” several places.  But I’m not certain each use is talking about the same key material.
> 
>                When the operator first establishes a secure
>   communication channel between the management system and the router,
>   this pre-installed key material is used to authenticate the router.
> 
> So the router gets keys as part of the manufacturing, where the “pre-installed key material” can be used in communication with the operator.
> 
> I can see that this might make it easier for the router to communicate directly with the CA and authenticate itself using these keys.  But section 5.1 notes that the CA has no way to authenticate the router.  I don’t know that the pre-installed key material could provide that way to authenticate the router, without the participation of the operator at some point.
> 
>   The operator burden shifts here to include:
> 
> I’m not sure how to read this.  Maybe “The operator burdens that shift here can/will include”.
> 
> I’m also not sure if both 1 and 2 are presumed to be shifted/lifted, or if it is either.
> 
> 
>   1.  Securely communicating the router's authentication material to
>       the CA prior to operator initiating the router's CSR.  CAs use
>       authentication material to determine whether the router is
>       eligible to receive a certificate. Authentication material at a
>       minimum includes the router's AS number and RouterID as well as
>       the router's key material, but can also include additional
>       information. Authentication material can be communicated to the
>       CA (i.e., CSRs signed by this key material are issued
>       certificates with this AS and RouterID) or to the router (i.e.,
>       the operator uses the vendor-supplied management interface to
>       include the AS number and routerID in the router-generated CSR).
> 
> Who is doing the communicating in “securely communicating to the CA” and “can be communicated to the CA”?  In the following paragraph, the text says “the router is communicating directly with the CA” - is the communication in this part 1 text going from the router to the CA?
> 
> What is the “router’s key material”?  I could read it both ways:
> 
> The paragraph above says that the pre-installed key material is used to authenticate the router, so maybe the “router’s key material” is the pre-installed key material.  The text says that the CA “uses” the authentication material, which includes the router’s key material, to determine whether to issue the certificate.  I don’t know how the pre-installed key material could assure the CA that the router could be issued a cert, without some coordination with the operator about that particular key material.
> 
> Then the text says “CSRs signed by this key material” which implies that the “router’s key material” is the public/private key pair.
> 
> So I’m not certain what is going on here, or how the pre-installed key material is helping.

#Sean: See earlier discussion about why this is here.

>   Once configured, the operator can begin the process of enrolling the
>   router.  
> 
> What does “once configured” mean?  configuring the router-operator protected channel?  Doing the communication of authentication material in 1 and 2 above?  Configuring the router with AS and RouterID?
> 
>            Because the router is communicating directly with the CA,
>   there is no need for the operator to retrieve the PKCS#10 from the
>   router or return the PKCS#7 to the router as in Section 6.    Note that
>   the checks performed by the router,
> 
> Section 5 says the router returns the PKCS#10 to the operator.
> Section 7 says the operator sends the PKCS#7 to the router and the router performs checks.
> 
> suggest:
> 
>            Because the router is communicating directly with the CA,
>   there is no need for the operator to retrieve the PKCS#10 from the
>   router as in Section 5 or return the PKCS#7 to the router as in Section 7.  Note that
>   the checks performed by the router in Section 7,

#Sean: Incorporated

>   When a router is so configured the communication with the CA SHOULD
>   be automatically re-established
> 
> what does “so configured” mean here?  configured with pre-installed key material?  configured by the operator with AS and RouterID?

#Keyur: I understand it as “configured with authentication material described in the section”.

> p8, section 9.1 (nit)
> 
> just for symmetry:
> 
>   4.  Use some other kind of automated process to search for and track
> 
> suggest:
> 
>   4.  The operator uses some other kind of automated process to search for and track

#Keyur: Ack. We should incorporate the text.

#Sean: Sure.

> p8, section 9.1
> 
>   Regardless of the technique used to track router certificate expiry
>   times, it is advisable to notify additional operators in the same
>   organization
> 
> “notify additional operators” — In addition to what? or after what?
> 
> I think you mean “multiple” operators, or I misunderstand.

#Sean: This is about ensuring that no single human can be at fault for forgetting to get a new key.  I.e., set up a calendar, tell your buddy, etc. that this key (and others) expire on day X and we’d better make sure that there’s a new key in place before then.

> p9, section 9.3  (nits)
> 
>   certificate to the router), and distributing the status takes time
> 
> Not sure what you mean by “status” that needs to be distributed.  Are you talking about distributing the revocation “status” in the CRL?
> 
>   Keeping the router operational and BGPsec-speaking is the ideal goal,
>   but if operational practices do not allow this then reconfiguring the
>   router to disabling BGPsec is likely preferred to bringing the router
>   offline.
> 
> suggest:
> 
>  router to disable BGPsec is likely preferred to bringing the router

#Keyur: Incorporate the suggestion please.

#Sean: Incorporated.

> p10, section 9.4
> 
>   To allow operators to quickly replace routers without requiring
>   update and distribution of the corresponding public keys in the RPKI,
>   routers SHOULD allow the private BGPsec key to inserted via a
>   protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP.  This
>   lets the operator escrow the old private key via the mechanism used
>   for operator-generated keys, see Section 5.2, such that it can be re-
>   inserted into a replacement router.
> 
> The topic here is routers that won’t allow off-loading of their keys.  
> 
> “routers SHOULD allow the private BGPsec key to inserted”
> 
> is the router that is doing the allowing the old, soon to be replaced routers, or the newly installed routers?
> 
> “to <be> inserted” - where? - in the newly installed router or in the management station?
> 
> “This lets the operator escrow the old private key” - sounds like the old router is allowing the private key to be “inserted in” (exported to?) the management station.  Right?

#Keyur: The above text is merely stating that routers SHOULD allow private BGPsec Key to be inserted via….. It is obviously for routers (old with new image and old replaced by a newer router and NOT the management station).

> Is there a suggestion of how to get the routers to allow export of the key, which is currently not allowed?

#Sean: They either support this or they don’t.

> I don’t see that section 5.2 says anything about a mechanism for escrowing keys.  It talks about installing a private key into a router over the protected channel.  If the citation to 5.2 is about the “such that it can be re-inserted” part of the sentence, then I get it.  But the citation should move  to the end of the sentence.

#Sean: If the operator generated the keys pair then it can send the private key in the PKCS#8 to anybody it wants.

> p10, section 10 (nit)
> 
>                                                         After
>   familiarizing one's self with the capabilities of the router,
>   operators are encouraged
> 
> suggest:
> 
>                                                         After
>   familiarizing themselves with the capabilities of the router,
>   operators are encouraged
> 
> 
> or
> 
>                                                         After
>   familiarizing one's self with the capabilities of the router,
>   an operator is encouraged

#Keyur: Suggest the later line.

#Sean: Incorporated.

> p11, section 10 (nit)
> 
>                           employees that no longer need access to
>   routers SHOULD be removed the router 
> 
> suggest
> 
>                           employees that no longer need access to
>   a router SHOULD be removed from the router 
> 
> or
> 
>                          employees that no longer need access to
>   a router SHOULD be removed from the router access [list]

#Keyur: Suggest the later line.

#Sean: Incorporated.

> p11, section 10 (nit)
> 
>                                                                The
>   operator MUST ensure that installed CA certificate is valid.
> 
> suggest:
> 
>                                                                The
>   operator MUST ensure that the installed CA certificate is valid.

#Keyur: Incorporate the text please.

#Sean: Incorporated.

> p14, section Appendix A
> 
>   x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
>   authentication.
> 
> is that an example, or a recommendation?

#Keyur: Suggestion

> p15, section Appendix B (nit)
> 
>   that will generate the key pair for the algorithms noted in the main
>   body of this document;
> 
> the algorithms are not noted in the main body, but the end of section 1 does cite RFC8208.  
> 
>   the private key just generated to sign the certification request with
>   the algorithms specified in the main body of this document;
> 
> the algorithms are not specified in the main body, but the end of section 1 does cite RFC8208.

#Keyur: Ok. Maybe change the text to reflect the end of section 1.

#Sean: I mean they are in the main body but it’s by reference so how about I use “referenced”.  Incorporated.

> p16, Appendix B
> 
> Uses of “serial number”:
> 
>   the subject name and serial number for the router.  The CA needs this
> and
>   CSR you sent; the certificate will include the subject name, serial
>   number, public key, and other fields
> and
>   Create CSR and sign CSR with private key, and; o Step 3: Send CSR
>   file with the subject name and serial number to CA.
> 
> The first of these seem to mean the BGP Identifier aka RouterID.  As said before, RFC4271 and RFC8209 use the term BGP Identifier.
> 
> The second and third use of “serial number” probably also mean BGP Identifier aka RouterID (not the issued cert’s serial number).

#Keyur: Already handled above.

> p17, section Appendix B (typo nit)
> 
>   way through GPsec-enabling the router.
> 
> suggest:
> 
>   way through BGPsec-enabling the router.

#Keyur: Ack. Incorporate the text please.

#Sean: Incorporated.

> p17, section Appendix B
> 
>                      To avoid having routers with expired certificates
>   follow the recommendations in the Certification Policy (CP) [RFC6484]
> 
> you could also mention section 9.1.

#Keyur: Ack. 

#Sean: I could, but where does that end?  I could also put references in each of AppA’s paragraph to front part of the document.  I think that I’m going to rely on readers having read the entire document.

spt