--- 1/draft-ietf-sidrops-rtr-keying-03.txt 2019-02-27 18:14:18.288838037 -0800 +++ 2/draft-ietf-sidrops-rtr-keying-04.txt 2019-02-27 18:14:18.332839104 -0800 @@ -1,21 +1,21 @@ Network Working Group R. Bush Internet-Draft IIJ Lab / Dragon Research Lab Intended status: Best Current Practice S. Turner -Expires: July 20, 2019 sn3rd +Expires: August 31, 2019 sn3rd K. Patel Arrcus, Inc. - January 16, 2019 + February 27, 2019 Router Keying for BGPsec - draft-ietf-sidrops-rtr-keying-03 + draft-ietf-sidrops-rtr-keying-04 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. @@ -55,204 +55,238 @@ publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Management / Router Communication . . . . . . . . . . . . . . 3 + 2. Management / Router Communication . . . . . . . . . . . . . . 4 3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5 - 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5 - 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5 - 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 6 - 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6 - 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7 - 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 - 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 - 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 12.1. Informative References . . . . . . . . . . . . . . . . . 13 - Appendix A. Management/Router Channel Security . . . . . . . . . 14 - Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6 + 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6 + 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7 + 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7 + 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8 + 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 + 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10 + 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 12.1. Informative References . . . . . . . . . . . . . . . . . 14 + Appendix A. Management/Router Channel Security . . . . . . . . . 15 + Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction BGPsec-speaking routers are provisioned with private keys, which allow them to digitally sign BGPsec announcements. To verify the signature, the public key, in the form of a certificate [RFC8209], is published in the Resource Public Key Infrastructure (RPKI). This document describes provisioning of BGPsec-speaking routers with the appropriate public-private key-pairs. There are two methods, router- driven and operator-driven. These two methods differ in where the keys are generated: on the router in the router-driven method, and elsewhere in the operator-driven method. Routers are required to support at least one of the methods in order to work in various deployment environments. - Some routers may not allow the private key to be off-loaded while - others may. While off-loading private keys would ease swapping of + Some routers may not allow the private key to be exported while + others may. While exporting private keys would ease swapping of routing engines, exposure of private keys is a well known security risk. In the operator-driven method, the operator generates the private/public key-pair and sends it to the router. In the router-driven method, the router generates its own public/private key-pair. The router-driven method mirrors the model used by traditional PKI subscribers; the private key never leaves trusted storage (e.g., Hardware Security Module). This is by design and supports classic PKI Certification Policies for (often human) subscribers which require the private key only ever be controlled by the subscriber to ensure that no one can impersonate the subscriber. For non-humans, - this method does not always work. For example, when an operator - wants to support hot-swappable routers, the same private key needs to - be installed in the soon-to-be online router that was used by the the - soon-to-be offline router. This motivated the operator-driven - method. + this method does not always work. The operator-driven model is + motivated by the extreme importance placed on ensuring the continued + operation of the network. In some deployments, the same private key + needs to be installed in the soon-to-be online router that was used + by the soon-to-be offline router, since this "hot-swapping" behavior + can result in minimal downtime, especially compared with the normal + RPKI procedures to propagate a new key, which can take a day or + longer to converge. + + For example, when an operator wants to support hot-swappable routers, + the same private key needs to be installed in the soon-to-be online + router that was used by the soon-to-be offline router. This + motivated the operator-driven method. Sections 2 through 7 describe the various steps involved for an operator to use the two methods to provision new and existing routers. The methods described involve the operator configuring the two end points (i.e., the management station and the router) and acting as the intermediary. Section 8 describes another method that requires more capable routers. - Useful References: [RFC8205] describes gritty details, [RFC8209] + Useful References: [RFC8205] describes details of BGPsec, [RFC8209] specifies the format for the PKCS#10 certification request, and - [RFC8208] specifies the algorithms used to generate the PKCS#10's + [RFC8208] specifies the algorithms used to generate the PKCS#10 signature. 2. Management / Router Communication Operators are free to use either the router-driven or operator-driven - method as supported by the platform. Regardless of the method - chosen, operators first establish a protected channel between the - management system and the router. How this protected channel is + method as supported by the platform. Prudent security practice + recommends router-generated keying, if the delay in replacing a + router (or router engine) is acceptable to the operator. Regardless + of the method chosen, operators first establish a protected channel + between the management system and the router; this protected channel + prevents eavesdropping, tampering, and message forgery as well as + provides mutual authentication. How this protected channel is established is router-specific and is beyond scope of this document. - Though other configuration mechanisms might be used, e.g. NetConf - (see [RFC6470]), the protected the protected channel between the - management platform and the router is assumed to be an SSH-protected - CLI. See Appendix A for security considerations for this protected - channel. + Though other configuration mechanisms might be used, e.g. NETCONF + (see [RFC6470]), the protected channel used between the management + platform and the router is assumed to be an SSH-protected CLI. See + Appendix A for security considerations for this protected channel. + + The previous paragraph assumes the management system-to-router + communications are over a network. When the management system has a + direct physical connection to the router, e.g., via the craft port, + there is no assumption that there is a protected channel between the + two. 3. Exchange Certificates A number of options exist for the operator management station to exchange PKI-related information with routers and with the RPKI including: - Using application/pkcs10 media type [RFC5967] to extract certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751- bis] to return the issued certificate, - Using FTP or HTTP per [RFC2585], and - Using Enrollment over Secure Transport (EST) protocol per [RFC7030]. + Despite the fact that Certificates are integrity-protected and do not + necessarily need additional protection, transports that also provide + integrity protection are RECOMMENDED. + 4. Set-Up To start, the operator uses the protected channel to install the appropriate RPKI Trust Anchor's Certificate (TA Cert) in the router. This will later enable the router to validate the router certificate returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis]. - The operator also configures the Autonomous System (AS) number to be - used in the generated router certificate. This may be the sole AS + The operator 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. A router with multiple ASs can be configured with multiple router certificates by following the process - of this document for each desired certificate. + of this document for each desired certificate. This configured AS + number is also used during verification of keys, if generated by the + operator (see Section 5.2), as well as during certificate + verification steps (see Sections 6, 7, and 8). The operator configures or extracts from the router the BGP - Identifier [RFC4271] to be used in the generated router certificate. + Identifier [RFC6286] to be used in the generated router certificate. In the case where the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used. + The operator configures the router's access control mechanism to + ensure that only authorized users are able to later access the + router's configuration. + 5. Generate PKCS#10 The private key, and hence the PKCS#10 certification request, which is sometimes referred to as a Certificate Signing Request (CSR), may be generated by the router or by the operator. - The PKCS#10 request SHOULD be saved to enable verifying that the - returned public key in the certificate corresponds to the private - used to generate the signature on the CSR. + Retaining the CSR allows for verifying that the returned public key + in the certificate corresponds to the private key used to generate + the signature on the CSR. NOTE: The PKCS#10 certification request does not include the AS number or the BGP Identifier for the router certificate. Therefore, the operator transmits the AS it has chosen on the router and the BGP Identifier as well when it sends the CSR to the CA. 5.1. Router-Generated Keys In the router-generated method, once the protected channel is established and the initial Set-Up (Section 4) performed, the operator issues a command or commands for the router to generate the public/private key pair, to generate the PKCS#10 certification request, and to sign the PKCS#10 certification request with the private key. Once the router has generated the PKCS#10 certification request, it returns it to the operator over the protected channel. The operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA. - NOTE: If a router were to communicate directly with a CA to have the - CA certify the PKCS#10 certification request, there would be no way - for the CA to authenticate the router. As the operator knows the + 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]. + + NOTE: The CA needs to know that the router-generated CSR is + authorized. The easiest way to accomplish this for the operator to + mediate the communication with the CA. Other workflows are possible, + e.g., where the router sends the CSR to the CA but the operator logs + in to the CA independently and is presented with a list of pending + requests to approve. See Section 8 for an additional workflow. + + If a router were to communicate directly with a CA to have the CA + certify the PKCS#10 certification request, there would be no way for + the CA to authenticate the router. As the operator knows the authenticity of the router, the operator mediates the communication with the CA. 5.2. Operator-Generated Keys In the operator-generated method, the operator generates the public/private key pair on a management station and installs the private key into the router over the protected channel. Beware that experience has shown that copy-and-paste from a management station to a router can be unreliable for long texts. The operator then creates and signs the PKCS#10 certification request with the private key; the operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA. - 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]. - 5.2.1. Using PKCS#8 to Transfer Private Key A private key can be encapsulated in a PKCS#8 Asymmetric Key Package - - [RFC5958] and should be further encapsulated in Cryptographic Message + [RFC5958] and SHOULD be further encapsulated in Cryptographic Message Syntax (CMS) SignedData [RFC5652] and signed with the operators's End Entity (EE) private key. The router SHOULD verify the signature of the encapsulated PKCS#8 to ensure the returned private key did in fact come from the operator, but this requires that the operator also provision via the CLI or include in the SignedData the RPKI CA certificate and relevant - operator's EE certificate(s). The router should inform the operator + operator's EE certificate(s). The router SHOULD inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope. 6. Send PKCS#10 and Receive PKCS#7 The operator uses RPKI management tools to communicate with the global RPKI system to have the appropriate CA validate the PKCS#10 certification request, sign the key in the PKCS#10 (i.e., certify it) and generate a PKCS#7 certs-only message, as well as publishing the certificate in the Global RPKI. External network connectivity may be @@ -266,31 +300,34 @@ Global RPKI. 2. Returns the certificate to the operator's management station, packaged in a PKCS#7 certs-only message, using the corresponding method by which it received the certificate request. It SHOULD include the certificate chain below the TA Certificate so that the router can validate the router certificate. In the operator-generated method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message, and verify that the - private key it holds corresponds to the returned public key. If the - operator saved the PKCS#10 it can check this correspondence by - comparing the public key in the CSR to the public key in the returned - certificate. If the operator has not saved the PKCS#10, it can check - this correspondence by generating a signature on any data and then - verifying the signature using the returned certificate. + public key the operator holds corresponds to the returned public key + in the PKCS#7 certs-only message. If the operator saved the PKCS#10 + it can check this correspondence by comparing the public key in the + CSR to the public key in the returned certificate. If the operator + has not saved the PKCS#10, it can check this correspondence by + regenerating the public key from the private key and then verifying + that the regenerated public key matches the public key returned in + the certificate. In the operator-generated method, the operator has already installed the private key in the router (see Section 5.2). 7. Install Certificate + The operator provisions the PKCS#7 certs-only message into the router over the protected channel. The router SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key corresponds to the stored private key. If the router stored the PKCS#10, it can check this correspondence by comparing the public key in the CSR to the public key in the returned certificate. If the router did not store the PKCS#10, it can check this correspondence by generating a signature on any data and then verifying the signature using the returned @@ -307,21 +344,21 @@ inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope. 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. 8. Advanced Deployment Scenarios - More PKI-capable routers can take advantage of this increased + More PKI-capable routers can take advantage of increased functionality and lighten the operator's burden. Typically, these routers include either pre-installed manufacturer-generated certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed manufacturer-generated Pre-Shared Keys (PSK) as well as PKI-enrollment functionality and transport protocol, e.g., CMC's "Secure Transport" [RFC7030] or the original CMC transport protocol's [RFC5273]. When the operator first establishes a protected channel between the management system and the router, this pre-installed key material is used to authenticate the router. @@ -336,40 +373,46 @@ 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 BGP Identifier) or to the router (i.e., the operator uses the vendor-supplied management interface to include the AS number and BGP Identifier in the router-generated CSR). 2. Enabling the router to communicate with the CA. While the router-to-CA communications are operator-initiated, the operator's management interface need not be involved in the - communications path. Enabling the router-to-CA connectivity MAY - require connections to external networks (i.e., through + communications path. Enabling the router-to-CA connectivity + requires connections to external networks (i.e., through firewalls, NATs, etc.). + 3. Ensuring the cryptographic chain of custody from the + manufacturer. For the pre-installed key material, the operator + needs guarantees that either no one has accessed the private key + or an authenticated log of those who have accessed it has been + provided to the operator. + Once configured, the operator can begin the process of enrolling the router. Because the router is communicating directly with the CA, there is no need for the operator to retrieve the PKCS#10 certification request from the router as in Section 5 or return the PKCS#7 certs-only message to the router as in Section 6. Note that the checks performed by the router in Section 7, namely extracting the certificate from the PKCS#7 certs-only message, verifying the public key corresponds to the private key, and that the returned certificate validated back to an installed trust anchor, SHOULD be performed. Likewise, the router SHOULD notify the operator if any of these fail, but this notification mechanism is out of scope. When a router is so configured, the communication with the CA SHOULD be automatically re-established by the router at future times to - renew or rekey the certificate automatically when necessary (See - Section 9). This further reduces the tasks required of the operator. + renew the certificate automatically when necessary (See Section 9). + This further reduces the tasks required of the operator. 9. Key Management Key management does not only include key generation, key provisioning, certificate issuance, and certificate distribution. It also includes assurance of key validity, key roll-over, and key preservation during router replacement. All of these responsibilities persist for as long as the operator wishes to operate the BGPsec-speaking router. @@ -450,40 +493,42 @@ the compromised key, and then make a next generation soon-to-be-operational key. Hopefully, all this can be done without needing to take offline or reboot the router. For routers which support only one operational key, the operators should create or install the new private key, and then request revocation of the certificate corresponding to the compromised private key. 9.4. Router Replacement Currently routers often generate private keys for uses such as SSH, - and the private keys may not be seen or off-loaded from the router. + and the private keys may not be seen or exported from the router. While this is good security, it creates difficulties when a routing engine or whole router must be replaced in the field and all software which accesses the router must be updated with the new keys. Also, any network based initial contact with a new routing engine requires trust in the public key presented on first contact. 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 be inserted via a protected channel, 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 router MAY allow the private - key to be to be off-loaded via the protected channel, but this SHOULD - be paired with functionality that sets the key into a permanent non- - exportable state to ensure that it is not off-loaded at a future time - by unauthorized operations. + key to be to be exported via the protected channel after key + generation, but this SHOULD be paired with functionality that sets + the newly generated key into a permanent non-exportable state to + ensure that it is not exported at a future time by unauthorized + operations. 10. Security Considerations + The router's manual will describe whether the router supports one, the other, or both of the key generation options discussed in the earlier sections of this draft as well as other important security- related information (e.g., how to SSH to the router). After familiarizing one's self with the capabilities of the router, an operator is encouraged to ensure that the router is patched with the latest software updates available from the manufacturer. This document defines no protocols. So, in some sense, it introduces no new security considerations. However, it relies on many others @@ -507,21 +552,21 @@ all private keys MUST be protected when at rest in a secure fashion. Obviously, how each router protects private keys is implementation specific. Likewise, the local storage format for the private key is just that, a local matter. Private key protection in transit: Mistakes here are, for all, practical purposes catastrophic because disclosure of the private key allows another entity to masquerade as (i.e., impersonate) the signer; transport security is therefore strongly RECOMMENDED. The level of security provided by the transport layer's security - mechanism SHOULD be commensurate with the strength of the BGPsec + mechanism SHOULD be at least as good as the strength of the BGPsec key; there's no point in spending time and energy to generate an excellent public-private key pair and then transmit the private key in the clear or with a known-to-be-broken algorithm, as it just undermines trust that the private key has been kept private. Additionally, operators SHOULD ensure the transport security mechanism is up to date, in order to addresses all known implementation bugs. Though the CA's certificate is installed on the router and used to verify that the returned certificate is in fact signed by the CA, the @@ -555,33 +600,32 @@ [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . - [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A - Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI - 10.17487/RFC4271, January 2006, . - [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, . + [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP + Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, + June 2011, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, . @@ -660,21 +704,21 @@ Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management - Part 1 (Revised), March 2007. Appendix A. Management/Router Channel Security Encryption, integrity, authentication, and key exchange algorithms - used by the protected channel SHOULD be of equal or greater strength + used by the protected channel should be of equal or greater strength than the BGPsec keys they protect, which for the algorithm specified in [RFC8208] is 128-bit; see [RFC5480] and by reference [SP800-57] for information about this strength claim as well as [RFC3766] for "how to determine the length of an asymmetric key as a function of a symmetric key strength requirement." In other words, for the encryption algorithm, do not use export grade crypto (40-56 bits of security), do not use Triple DES (112 bits of security). Suggested minimum algorithms would be AES-128: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256 @@ -686,22 +730,22 @@ certificates used for BGPsec. The certificates used with SSH should also enable a level of security commensurate with BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for authentication. The protected channel must provide confidentiality, authentication, and integrity and replay protection. Appendix B. The n00b Guide to BGPsec Key Management - This appendix is informative. It attempts to explain all of the PKI - technobabble in plainer language. + This appendix is informative. It attempts to explain some of the PKI + lingo in plainer language. BGPsec speakers send signed BGPsec updates that are verified by other BGPsec speakers. In PKI parlance, the senders are referred to as signers and the receivers are referred to as relying parties. The signers with which we are concerned here are routers signing BGPsec updates. Signers use private keys to sign and relying parties use the corresponding public keys, in the form of X.509 public key certificates, to verify signatures. The third party involved is the entity that issues the X.509 public key certificate, the Certification Authority (CA). Key management is all about making @@ -731,24 +775,24 @@ If you are generating keys on the router (router-driven), then you will need to access the router. Again, how you access the router is router-specific, but generally the DIY approach uses the CLI and accessing the router either directly via the router's craft port or over the network on an administrative interface. If accessing the router over the network be sure to do it securely (i.e., use SSHv2). Once logged into the router, issue a command or a series of commands that will generate the key pair for the algorithms referenced in the main body of this document; consult your router's documentation for - the specific commands. The key generation process will yield - multiple files: the private key and the public key; the file format - varies depending on the arcane command you issued, but generally the - files are DER or PEM-encoded. + the specific commands. The key generation process will yield one or + more files the private key and the public key; the file format varies + depending on the arcane command you issued, but generally the files + are DER or PEM-encoded. The second step is to generate the certification request, which is often referred to as a certificate signing request (CSR) or PKCS#10 certification request, and to send it to the CA to be signed. To generate the CSR, you issue some more arcane commands while logged into the router; using the private key just generated to sign the certification request with the algorithms referenced in the main body of this document; the CSR is signed to prove to the CA that the router has possession of the private key (i.e., the signature is the proof-of-possession). The output of the command is the CSR file; the @@ -763,26 +807,26 @@ CSR to the CA, is beyond the scope of this document. While you are still connected to the router, install the Trust Anchor (TA) for the root of the PKI. At this point, you no longer need access to the router for BGPsec-related initiation purposes. The fourth step is for the CA to issue the certificate based on the CSR you sent; the certificate will include the subject name, serial number, public key, and other fields as well as being signed by the CA. After the CA issues the certificate, the CA returns the certificate, and posts the certificate to the RPKI repository. Check - that the certificate corresponds to the private key by verifying the - signature on the CSR sent to the CA; this is just a check to make - sure that the CA issued a certificate that includes a public key that - is the pair of the private key (i.e., the math will work when - verifying a signature generated by the private with the returned - certificate). + that the certificate corresponds to the pubic key contained in the + certificate by verifying the signature on the CSR sent to the CA; + this is just a check to make sure that the CA issued a certificate + that includes a public key that is the pair of the private key (i.e., + the math will work when verifying a signature generated by the + private with the returned certificate). If generating the keys off-router (operator-driven), then the same steps are used as the on-router key generation, (possibly with the same arcane commands as those used in the on-router approach), but no access to the router is needed the first three steps are done on an administrative workstation: o Step 1: Generate key pair; o Step 2: Create CSR and sign CSR with private key, and; o Step 3: Send CSR file with the subject name and serial number to CA. After the CA has returned the certificate and you have checked the