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

Sandra Murphy <sandy@tislabs.com> Wed, 15 November 2017 02:07 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924E31200CF; Tue, 14 Nov 2017 18:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAj_x2EdYDip; Tue, 14 Nov 2017 18:07:24 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841E9126D73; Tue, 14 Nov 2017 18:07:24 -0800 (PST)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DF0CD28B0041; Tue, 14 Nov 2017 21:07:23 -0500 (EST)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1913A1F8036; Tue, 14 Nov 2017 21:07:22 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com>
Date: Tue, 14 Nov 2017 21:07:20 -0500
Cc: Sandra Murphy <sandy@tislabs.com>, Christopher Morrow <christopher.morrow@gmail.com>, sidr chairs <sidr-chairs@ietf.org>, draft-ietf-sidr-rtr-keying@ietf.org, sidr list <sidr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com>
References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com>
To: Sean Turner <sean@sn3rd.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/T-PB3WHCqUgBJPFdFS57x7fpfag>
Subject: Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 02:07:27 -0000

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.

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.

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?

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?

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.

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

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.

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?

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.

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.

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?

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

========================================

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.

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.


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.”

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.

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

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.

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.  

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?

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

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.

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.

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) 

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?

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.

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”?

p6, section 6 (nit)

   2.  Returns the certificate to the operator's management station,
       packaged in a PKCS#7

Needs a reference.  RFC2315?

   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?

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.

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?

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.

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.


   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,

   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?

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

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.

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

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?

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

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.

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

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]

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.

p14, section Appendix A

   x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
   authentication.

is that an example, or a recommendation?

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.

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).
 
p17, section Appendix B (typo nit)

   way through GPsec-enabling the router.

suggest:

   way through BGPsec-enabling the router.

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.





> On Nov 14, 2017, at 10:36 AM, Sandra Murphy <sandy@tislabs.com> wrote:
> 
> 
> 
> Sorry, the reply did not pick up the original attachment.
> 
> Attached here.
> 
> Let me know if there are problems reading the comments.
> 
> —Sandy
> 
> <draft-ietf-sidr-rtr-keying-14.mycomments.rtf>
> 
>> On Nov 14, 2017, at 10:33 AM, Sandra Murphy <sandy@tislabs.com> wrote:
>> 
>> Speaking as wg co-chair
>> 
>> Please, wg, do take a look at the comments attached.  This draft was requested by the operators and is important.
>> 
>> Some of the comments are about substance.  Those at the very least must be considered by the wg.
>> 
>> Please take advantage of focused attention and close proximity at the IETF meeting to discuss.  
>> 
>> I unfortunately can not be there to button hole people and shove printouts into their hands.
>> 
>> —Sandy, speaking as wg co-chair
>> 
>>> On Nov 5, 2017, at 9:25 PM, Sandra Murphy <sandy@tislabs.com> wrote:
>>> 
>>> I’m attaching some comments and questions I found in the -14 version.
>>> 
>>> —Sandy
>>> 
>>> <draft-ietf-sidr-rtr-keying-14.mycomments.rtf>
>>> 
>>>> On Oct 20, 2017, at 1:04 PM, Sean Turner <sean@sn3rd.com> wrote:
>>>> 
>>>> Chris,
>>>> 
>>>> This version includes changes to address Oliver’s and Sriram’s comments.
>>>> 
>>>> spt
>>>> 
>>>>> On Oct 20, 2017, at 13:02, internet-drafts@ietf.org wrote:
>>>>> 
>>>>> 
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>> This draft is a work item of the Secure Inter-Domain Routing WG of the IETF.
>>>>> 
>>>>>    Title           : Router Keying for BGPsec
>>>>>    Authors         : Randy Bush
>>>>>                      Sean Turner
>>>>>                      Keyur Patel
>>>>> 	Filename        : draft-ietf-sidr-rtr-keying-14.txt
>>>>> 	Pages           : 17
>>>>> 	Date            : 2017-10-20
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 
>>>>> 
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
>>>>> 
>>>>> There are also htmlized versions available at:
>>>>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14
>>>>> 
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-14
>>>>> 
>>>>> 
>>>>> Please note that it may take a couple of minutes from the time of submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>> 
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>> 
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> I-D-Announce@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>> 
>>>> _______________________________________________
>>>> sidr mailing list
>>>> sidr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>