idnits 2.17.00 (12 Aug 2021) /tmp/idnits42749/draft-ietf-sidr-bgpsec-algs-13.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 (November 4, 2015) is 2389 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) == Missing Reference: 'FIPS186' is mentioned on line 119, but not defined == Missing Reference: 'RFC6919' is mentioned on line 187, but not defined == Unused Reference: 'RFC6487' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'FIPS-186-3' is defined on line 307, but no explicit reference was found in the text ** 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. 'SHS' == Outdated reference: draft-ietf-sidr-rfc6485bis has been published as RFC 7935 == Outdated reference: draft-ietf-sidr-bgpsec-protocol has been published as RFC 8205 == Outdated reference: draft-ietf-sidr-bgpsec-pki-profiles has been published as RFC 8209 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-3' Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 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) November 4, 2015 5 Intended status: Standards Track 6 Expires: May 7, 2016 8 BGPsec Algorithms, Key Formats, & Signature Formats 9 draft-ietf-sidr-bgpsec-algs-13 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) 2015 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 . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 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]. BGPsec routers use these algorithms when requesting 79 BGPsec certificates [ID.sidr-bgpsec-pki-profiles], signing BGPsec 80 Update messages [ID.sidr-bgpsec-protocol], and verifying BGPsec 81 Update messages [ID.sidr-bgpsec-protocol]. 83 This document is referenced by the BGPsec specification [ID.sidr- 84 bgpsec-protocol] and the profile for BGPsec Router Certificates and 85 Certification Requests [ID.sidr-bgpsec-pki-profiles]. Familiarity 86 with these documents is assumed. Implementers are reminded, however, 87 that, as noted in Section 2 of [ID.sidr-bgpsec-pki-profiles], the 88 algorithms used to sign CA Certificates, BGPsec Router Certificates, 89 and CRLs are found in [ID.sidr-rfc6485bis]. 91 This document updates [ID.sidr-rfc6485bis] to add support for a) a 92 different algorithm for BGPsec certificate requests, which are issued 93 only by BGPsec speakers; b) a different Subject Public Key Info 94 format for BGPsec certificates, which is needed for the specified 95 BGPsec signature algorithm; and, c) a different signature format for 96 BGPsec signatures, which is needed for the specified BGPsec signature 97 algorithm. The BGPsec certificate are differentiated from other RPKI 98 certificates by the use of the BGPsec Extended Key Usage defined in 99 [ID.sidr-bgpsec-pki-profiles]. 101 1.1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 2. Algorithms 110 The algorithms used to compute signatures on CA certificates, BGPsec 111 Router Certificates, and CRLs are as specified in Section 2 of 112 [ID.sidr-rfc6485bis]. The remainder of this section addresses 113 algorithms used when BGPsec routers request certificates, RPKI CAs 114 verify BGPsec certification request, BGPsec routers generate BGPsec 115 Update messages, and when BGPsec routers verify BGPsec Update 116 messages: 118 o The signature algorithm used MUST be the Elliptic Curve Digital 119 Signature Algorithm (ECDSA) with curve P-256 [RFC6090][FIPS186]. 121 o The hash algorithm used MUST be SHA-256 [SHS]. 123 Hash algorithms are not identified by themselves in certificates or 124 BGPsec Update messages. They are represented by an OID that combines 125 the hash algorithm with the digital signature algorithm as follows: 127 o The ecdsa-with-SHA256 OID [RFC5480] MUST appear in the PKCS #10 128 signatureAlgorithm field [RFC2986] or in Certificate Request 129 Message Format (CRMF) POPOSigningKey algorithm field [RFC4211], 130 which location depends on the certificate request format 131 generated. 133 o In BGPsec Update messages, the ECDSA with SHA-256 Algorithm Suite 134 Identifier from Section 7 is included in the Signature-Block 135 List's Algorithm Suite Identifier field. 137 3. Asymmetric Key Pair Formats 139 The key formats used to compute signatures on CA certificates, BGPsec 140 Router Certificates, and CRLs are as specified in Section 3 of 141 [ID.sidr-rfc6485bis]. The remainder of this section addresses key 142 formats found in the BGPsec router certificate requests and in BGPsec 143 Router Certificates. 145 The ECDSA private keys used to compute signatures for certificate 146 requests and BGPsec Update messages MUST come from the P-256 curve 147 [RFC5480]. The public key pair MUST use the uncompressed form. 149 3.1. Public Key Format 151 The Subject's public key is included in subjectPublicKeyInfo 152 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 153 The values for the structures and their sub-structures follow: 155 o algorithm (an AlgorithmIdentifier type): The id-ecPublicKey OID 156 MUST be used in the algorithm field, as specified in Section 157 2.1.1 of [RFC5480]. The value for the associated parameters MUST 158 be secp256r1, as specified in Section 2.1.1.1 of [RFC5480]. 160 o subjectPublicKey: ECPoint MUST be used to encode the 161 certificate's subjectPublicKey field, as specified in Section 2.2 162 of [RFC5480]. 164 3.2. Private Key Format 166 Local Policy determines private key format. 168 4. Signature Format 170 The structure for the certificate's and CRL's signature field MUST be 171 as specified in Section 4 of [ID.sidr-rfc6485bis], which is the same 172 format used by other RPKI certificates. The structure for the 173 certification request's and BGPsec Update message's signature field 174 MUST be as specified in Section 2.2.3 of [RFC3279]. 176 5. Additional Requirements 178 It is anticipated that BGPsec will require the adoption of updated 179 key sizes and a different set of signature and hash algorithms over 180 time, in order to maintain an acceptable level of cryptographic 181 security. This profile should be updated to specify such future 182 requirements, when appropriate. 184 CAs and RPs SHOULD be capable of supporting a transition to allow for 185 the phased introduction of additional encryption algorithms and key 186 specifications, and also accommodate the orderly deprecation of 187 previously specified algorithms and keys [RFC6919]. Accordingly, CAs 188 and RPs SHOULD be capable of supporting multiple RPKI algorithm and 189 key profiles simultaneously within the scope of such anticipated 190 transitions. The recommended procedures to implement such a 191 transition of key sizes and algorithms are not specified in this 192 document, see Section 6 in [ID.sidr-bgpsec-protocol] for more 193 information. 195 6. Security Considerations 197 The Security Considerations of [RFC3279], [RFC5480], [RFC6090], 198 [ID.sidr-rfc6485bis], and [ID.sidr-bgpsec-pki-profiles] apply to 199 certificates. The security considerations of [RFC3279], [RFC6090], 200 [ID.sidr-rfc6485bis], [ID.sidr-bgpsec-pki-profiles] apply to 201 certification requests. The security considerations of [RFC3279], 202 [ID.sidr-bgpsec-protocol], and [RFC6090] apply to BGPsec Update 203 messages. No new security considerations are introduced as a result 204 of this specification. 206 7. IANA Considerations 208 The Internet Assigned Numbers Authority (IANA) is requested to define 209 the "BGPsec Algorithm Suite Registry" described below. 211 An algorithm suite consists of a digest algorithm and a signature 212 algorithm. This specification creates an IANA registry of one-octet 213 BGPsec algorithm suite identifiers. Additionally, this document 214 registers a single algorithm suite which uses the digest algorithm 215 SHA-256 and the signature algorithm ECDSA on the P-256 curve 216 [RFC5480]. 218 BGPsec Algorithm Suites Registry 220 Digest Signature Algorithm Specification 221 Algorithm Algorithm Suite Pointer 222 Identifier 224 +-------------------------------------------------------+ 225 | Reserved | Reserved | 0x0 | This draft | 226 +-------------------------------------------------------+ 227 | SHA-256 | ECDSA P-256 | TBD | RFC 5480 | 228 +-------------------------------------------------------+ 229 | Unassigned | Unassigned | TBD..0xF | This draft | 230 +-------------------------------------------------------+ 231 | Reserved | Reserved | 0xF | This draft | 232 +-------------------------------------------------------+ 234 Future assignments are to be made using either the Standards Action 235 process defined in [RFC5226], or the Early IANA Allocation process 236 defined in [RFC7120]. Assignments consist of a digest algorithm 237 name, signature algorithm name, and the algorithm suite identifier 238 value. 240 8. Acknowledgements 242 The author wishes to thank Geoff Huston and George Michaelson for 243 producing [ID.sidr-rfc6485bis], which this document is entirely based 244 on. I'd also like to thank Roque Gagliano, David Mandelberg, Sam 245 Weiller, and Stephen Kent for their reviews and comments. 247 9. References 249 9.1. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 255 Request Syntax Specification Version 1.7", RFC 2986, 256 November 2000. 258 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 259 Identifiers for the Internet X.509 Public Key 260 Infrastructure Certificate and Certificate Revocation List 261 (CRL) Profile", RFC 3279, April 2002. 263 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 264 Certificate Request Message Format (CRMF)", RFC 4211, 265 September 2005. 267 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 268 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 269 2008. 271 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 272 Housley, R., and W. Polk, "Internet X.509 Public Key 273 Infrastructure Certificate and Certificate Revocation List 274 (CRL) Profile", RFC 5280, May 2008. 276 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 277 "Elliptic Curve Cryptography Subject Public Key 278 Information", RFC 5480, March 2009. 280 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 281 Curve Cryptography Algorithms", RFC 6090, February 2011. 283 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 284 X.509 PKIX Resource Certificates", RFC 6487, February 2012. 286 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 287 Points", BCP 100, RFC 7120, January 2014. 289 [SHS] National Institute of Standards and Technology (NIST), "FIPS 290 Publication 180-3: Secure Hash Standard", FIPS Publication 291 180-3, October 2008. 293 [ID.sidr-rfc6485bis] Huston, G., and G. Michaelson, "The Profile for 294 Algorithms and Key Sizes for use in the Resource Public Key 295 Infrastructure", draft-ietf-sidr-rfc6485bis, work-in- 296 progress. 298 [ID.sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol 299 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 300 progress. 302 [ID.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile 303 for BGPSEC Router Certificates, Certificate Revocation 304 Lists, and Certification Requests", draft-ietf-sidr-bgpsec- 305 pki-profiles, work-in-progress. 307 [FIPS-186-3] National Institute of Standards and Technology, U.S. 308 Department of Commerce, "Digital Signature Standard", FIPS 309 186-4, July 2013. 311 9.2. Informative References 313 None. 315 Authors' Addresses 317 Sean Turner 318 IECA, Inc. 319 3057 Nutley Street, Suite 106 320 Fairfax, VA 22031 321 USA 323 EMail: turners@ieca.com