idnits 2.17.1 draft-ietf-sidr-bgpsec-algs-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6485bis, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2016) is 2927 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing Working Group S. Turner 3 Internet-Draft IECA, Inc. 4 Updates: 6485bis (if approved) April 21, 2016 5 Intended status: Standards Track 6 Expires: October 23, 2016 8 BGPsec Algorithms, Key Formats, & Signature Formats 9 draft-ietf-sidr-bgpsec-algs-15 11 Abstract 13 This document specifies the algorithms, algorithm parameters, 14 asymmetric key formats, asymmetric key size and signature format used 15 in BGPsec (Border Gateway Protocol Security). This document updates 16 the Profile for Algorithms and Key Sizes for Use in the Resource 17 Public Key Infrastructure (ID.sidr-rfc6485bis). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . 3 55 3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 4 57 4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Additional Requirements . . . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 This document specifies: 70 o the digital signature algorithm and parameters; 71 o the hash algorithm and parameters; 72 o the public and private key formats; and, 73 o the signature format 74 used by Resource Public Key Infrastructure (RPKI) Certification 75 Authorities (CA), and BGPsec (Border Gateway Protocol Security) 76 speakers (i.e., routers). CAs use these algorithms when processing 77 requests for BGPsec Router Certificates [ID.sidr-bgpsec-pki- 78 profiles]. Examples when BGPsec routers use these algorithms include 79 requesting BGPsec certificates [ID.sidr-bgpsec-pki-profiles], signing 80 BGPsec Update messages [ID.sidr-bgpsec-protocol], and verifying 81 BGPsec Update messages [ID.sidr-bgpsec-protocol]. 83 This document updates [ID.sidr-rfc6485bis] to add support for a) a 84 different algorithm for BGPsec certificate requests, which are issued 85 only by BGPsec speakers; b) a different Subject Public Key Info 86 format for BGPsec certificates, which is needed for the specified 87 BGPsec signature algorithm; and, c) a different signature format for 88 BGPsec signatures, which is needed for the specified BGPsec signature 89 algorithm. The BGPsec certificate are differentiated from other RPKI 90 certificates by the use of the BGPsec Extended Key Usage defined in 91 [ID.sidr-bgpsec-pki-profiles]. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 [RFC2119]. 100 2. Algorithms 102 The algorithms used to compute signatures on CA certificates, BGPsec 103 Router Certificates, and CRLs are as specified in Section 2 of 104 [ID.sidr-rfc6485bis]. This section addresses BGPsec algorithms, for 105 example these algorithms are used by BGPsec routers to request BGPsec 106 certificates, by RPKI CAs to verify BGPsec certification requests, by 107 BGPsec routers to generate BGPsec Update messages, and by BGPsec 108 routers to verify BGPsec Update message: 110 o The signature algorithm used MUST be the Elliptic Curve Digital 111 Signature Algorithm (ECDSA) with curve P-256 [RFC6090][DSS]. 113 o The hash algorithm used MUST be SHA-256 [SHS]. 115 Hash algorithms are not identified by themselves in certificates or 116 BGPsec Update messages. They are represented by an OID that combines 117 the hash algorithm with the digital signature algorithm as follows: 119 o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10 120 signatureAlgorithm field [RFC2986] or in Certificate Request 121 Message Format (CRMF) POPOSigningKey algorithm field [RFC4211], 122 which location depends on the certificate request format 123 generated. 125 o In BGPsec Update messages, the ECDSA with SHA-256 Algorithm Suite 126 Identifier from Section 7 is included in the Signature-Block 127 List's Algorithm Suite Identifier field. 129 3. Asymmetric Key Pair Formats 131 The key formats used to compute signatures on CA certificates, BGPsec 132 Router Certificates, and CRLs are as specified in Section 3 of 133 [ID.sidr-rfc6485bis]. This section addresses key formats found in 134 the BGPsec router certificate requests and in BGPsec Router 135 Certificates. 137 The ECDSA private keys used to compute signatures for certificate 138 requests and BGPsec Update messages MUST come from the P-256 curve 139 [RFC5480]. The public key pair MUST use the uncompressed form. 141 3.1. Public Key Format 143 The Subject's public key is included in subjectPublicKeyInfo 144 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 145 The values for the structures and their sub-structures follow: 147 o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID 148 MUST be used in the algorithm field, as specified in Section 149 2.1.1 of [RFC5480]. The value for the associated parameters MUST 150 be secp256r1, as specified in Section 2.1.1.1 of [RFC5480]. 152 o subjectPublicKey: ECPoint MUST be used to encode the 153 certificate's subjectPublicKey field, as specified in Section 2.2 154 of [RFC5480]. 156 3.2. Private Key Format 158 Local Policy determines private key format. 160 4. Signature Format 162 The structure for the certificate's and CRL's signature field MUST be 163 as specified in Section 4 of [ID.sidr-rfc6485bis], which is the same 164 format used by other RPKI certificates. The structure for the 165 certification request's and BGPsec Update message's signature field 166 MUST be as specified in Section 2.2.3 of [RFC3279]. 168 5. Additional Requirements 170 It is anticipated that BGPsec will require the adoption of updated 171 key sizes and a different set of signature and hash algorithms over 172 time, in order to maintain an acceptable level of cryptographic 173 security. This profile should be updated to specify such future 174 requirements, when appropriate. 176 The recommended procedures to implement such a transition of key 177 sizes and algorithms is specified in [RFC6916]. 179 6. Security Considerations 181 The Security Considerations of [RFC3279], [RFC5480], [RFC6090], 182 [ID.sidr-rfc6485bis], and [ID.sidr-bgpsec-pki-profiles] apply to 183 certificates. The security considerations of [RFC3279], [RFC6090], 184 [ID.sidr-rfc6485bis], [ID.sidr-bgpsec-pki-profiles] apply to 185 certification requests. The security considerations of [RFC3279], 186 [ID.sidr-bgpsec-protocol], and [RFC6090] apply to BGPsec Update 187 messages. No new security considerations are introduced as a result 188 of this specification. 190 7. IANA Considerations 192 The Internet Assigned Numbers Authority (IANA) is requested to define 193 the "BGPsec Algorithm Suite Registry" described below in the Resource 194 Public Key Infrastructure (RPKI) group. 196 An algorithm suite consists of a digest algorithm and a signature 197 algorithm. This specification creates an IANA registry of one-octet 198 BGPsec algorithm suite identifiers. Additionally, this document 199 registers a single algorithm suite which uses the digest algorithm 200 SHA-256 and the signature algorithm ECDSA on the P-256 curve 201 [RFC5480]. 203 BGPsec Algorithm Suites Registry 205 Digest Signature Algorithm Specification 206 Algorithm Algorithm Suite Pointer 207 Identifier 209 +-------------------------------------------------------+ 210 | Reserved | Reserved | 0x0 | This draft | 211 +-------------------------------------------------------+ 212 | SHA-256 | ECDSA P-256 | TBD | RFC 5480 | 213 +-------------------------------------------------------+ 214 | Unassigned | Unassigned | TBD+1..0xE | This draft | 215 +-------------------------------------------------------+ 216 | Reserved | Reserved | 0xF | This draft | 217 +-------------------------------------------------------+ 219 Future assignments are to be made using either the Standards Action 220 process defined in [RFC5226], or the Early IANA Allocation process 221 defined in [RFC7120]. Assignments consist of a digest algorithm 222 name, signature algorithm name, and the algorithm suite identifier 223 value. 225 8. Acknowledgements 227 The author wishes to thank Geoff Huston and George Michaelson for 228 producing [ID.sidr-rfc6485bis], which this document is entirely based 229 on. I'd also like to thank Roque Gagliano, David Mandelberg, Tom 230 Petch, Sam Weiller, and Stephen Kent for their reviews and comments. 232 9. References 234 9.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 240 Request Syntax Specification Version 1.7", RFC 2986, 241 November 2000. 243 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 244 Identifiers for the Internet X.509 Public Key 245 Infrastructure Certificate and Certificate Revocation List 246 (CRL) Profile", RFC 3279, April 2002. 248 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 249 Certificate Request Message Format (CRMF)", RFC 4211, 250 September 2005. 252 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 253 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 254 2008. 256 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 257 Housley, R., and W. Polk, "Internet X.509 Public Key 258 Infrastructure Certificate and Certificate Revocation List 259 (CRL) Profile", RFC 5280, May 2008. 261 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 262 "Elliptic Curve Cryptography Subject Public Key 263 Information", RFC 5480, March 2009. 265 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 266 Curve Cryptography Algorithms", RFC 6090, February 2011. 268 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 269 Procedure for the Resource Public Key Infrastructure 270 (RPKI)", BCP 182, RFC 6916, April 2013. 272 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 273 Points", BCP 100, RFC 7120, January 2014. 275 [ID.sidr-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for 276 Algorithms and Key Sizes for use in the Resource Public Key 277 Infrastructure", draft-ietf-sidr-rfc6485bis, work-in- 278 progress. 280 [ID.sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol 281 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 282 progress. 284 [ID.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile 285 for BGPSEC Router Certificates, Certificate Revocation 286 Lists, and Certification Requests", draft-ietf-sidr-bgpsec- 287 pki-profiles, work-in-progress. 289 [DSS] National Institute of Standards and Technology (NIST), U.S. 290 Department of Commerce, "Digital Signature Standard", FIPS 291 Publication 186-4, July 2013. 293 [SHS] National Institute of Standards and Technology (NIST), U.S. 294 Department of Commerce, "Secure Hash Standard", FIPS 295 Publication 180-4, August 2015. 297 9.2. Informative References 299 None. 301 Authors' Addresses 303 Sean Turner 304 IECA, Inc. 305 3057 Nutley Street, Suite 106 306 Fairfax, VA 22031 307 USA 309 EMail: turners@ieca.com