idnits 2.17.1 draft-ietf-sidr-bgpsec-algs-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 5, 2011) is 4526 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 4020 (Obsoleted by RFC 7120) ** 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' -- No information found for draft-ietf-sidr-bpgsec-pki-profiles - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID.bgpsec-pki-profiles' Summary: 4 errors (**), 0 flaws (~~), 2 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 4 Updates: [ID.sidr-rpki-algs] December 5, 2011 5 Intended Status: Standards Track 6 Expires: June 7, 2012 8 BGP Algorithms, Key Formats, & Signature Formats 9 draft-ietf-sidr-bgpsec-algs-01 11 Abstract 13 This document specifies the algorithms, algorithms' 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 (draft-ietf-sidr-rpki-algs). 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 This Internet-Draft will expire on June 7, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 This document specifies: 54 o the digital signature algorithm and parameters; 55 o the hash algorithm and parameters; 56 o the public and private key formats; and, 57 o the signature format 58 used by Resource Public Key Infrastructure (RPKI) Certification 59 Authorities (CA), and BGPSEC (Border Gateway Protocol Security) 60 speakers (i.e., routers). CAs use these algorithms when issuing 61 BGPSEC Router Certificates [ID.bgpsec-pki-profiles] and CRLs 62 [ID.sidr-res-cert-profile]. BGPSEC routers use these when requesting 63 BGPSEC certificates [ID.bgpsec-pki-profiles], generating BGPSEC 64 Update messages [ID.sidr-bgpsec-protocol], and verifying BGPSEC 65 Update messages [ID.sidr-bgpsec-protocol]. 67 This document is referenced by the BGPSEC specification [ID.bgpsec- 68 protocol] and the profile for BGPSEC Router Certificates and 69 Certification Requests [ID.bgpsec-pki-profiles]. Familiarity with 70 these documents is assumed. Implementers are reminded, however, 71 that, as noted in Section 2 of [ID.bgpsec-pki-profiles], the 72 algorithms used to sign CA Certificates, BGPSEC Router Certificates, 73 and CRLs are found in [ID.sidr-rpki-algs]. 75 This document updates [ID.sidr-rpki-algs] to add support for a) a 76 different algorithm for BGPSEC certificate requests, which are only 77 issued by BGPSEC speakers; b) a different Subject Public Key Info 78 format for BGPSEC certificates, which is needed for the specified 79 BGPSEC signature algorithm; and, c) a different signature format for 80 BGPSEC signatures, which is needed for the specified BGPSEC signature 81 algorithm. The BGPSEC certificate are differentiated from other RPKI 82 certificates by the use of the BGPSEC Extended Key Usage defined in 83 [ID.bgpsec-pki-profiles]. 85 1.1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in 90 [RFC2119]. 92 2. Algorithms 94 Four cryptographic algorithms are used to support BGPSEC: 96 o The signature algorithm used when issuing BGPSEC certificates and 97 CRLs, which would revoke BGPSEC certificates, MUST be as 98 specified in [ID.sidr-rpki-algs]. 100 o The signature algorithm used in certification requests and BGPSEC 101 Update messages MUST be Elliptic Curve Digital Signature 102 Algorithm (ECDSA) [RFC6090]. 104 o The hashing algorithm used when issuing certificates and CRLs 105 MUST be as specified in [ID.sidr-rpki-algs]. 107 o The hashing algorithm use when generating certification requests 108 and BGPSEC Update messages MUST be SHA-256 [SHS]. Hash 109 algorithms are not identified by themselves in certificates, or 110 BGPSEC Update messages instead they are combined with the digital 111 signature algorithm (see below). 113 NOTE: The exception to the above hashing algorithm is the use of 114 SHA-1 [SHS] when CAs generate authority and subject key 115 identifiers [ID.bgpsec-pki-profiles]. 117 To support BGPSEC, the algorithms are identified as follows: 119 o In certificates and CRLs, an Object Identifier (OID) is used. 120 The value and locations are as specified in section 2 of 121 [ID.sidr-rpki-algs]. 123 o In certification request, an OID is used. The ecdsa-with-SHA256 124 OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm 125 field [RFC4211] or in Certificate Request Message Format (CRMF) 126 POPOSigningKey signature field [RFC2986]. 128 o In BGPSEC Update messages, the ECDSA with SHA-256 Algorithm Suite 129 Identifier from Section 7 is included in the Signature-Block 130 List's Algorithm Suite Identifier field. 132 3. Asymmetric Key Format 134 The RSA key pairs used to compute signatures on CA certificates, 135 BGPSEC Router Certificates, and CRLs are as specified in section 3 of 136 [ID.sidr-rpki-algs]. The remainder of this section addresses key 137 formats found in the BGPSEC router certificate requests and in BGPSEC 138 Router Certificates. 140 The ECDSA key pairs used to compute signatures for certificate 141 requests and BGPSEC Update messages MUST come from the P-256 curve 142 [RFC5480]. The public key pair MUST use the uncompressed form. 144 3.1. Public Key Format 146 The Subject's public key is included in subjectPublicKeyInfo 147 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 149 The values for the structures and their sub-structures follow: 151 o algorithm (which is an AlgorithmIdentifier type): The id- 152 ecPublicKey OID MUST be used in the algorithm field, as specified 153 in 2.1.1 of [RFC5480]. The value for the associated parameters 154 MUST be secp256r1, as specified in 2.1.1.1 of [RFC5480]. 156 o subjectPublicKey: ECPublicKey MUST be used to encode the 157 certificate's subjectPublicKey field, as specified in Section 2.2 158 of [RFC5480]. 160 3.2. Private Key Format 162 Local Policy determines private key format. 164 4. Signature Format 166 The structure for the certificate's and CRL's signature field MUST be 167 as specified in Section 4 of [ID.sidr-rpki-algs]. The structure for 168 the certification request's and BGPSEC Update message's signature 169 field MUST be as specified in Section 2.2.3 of [RFC3279]. 171 5. Additional Requirements 173 It is anticipated that BGPSEC will require the adoption of updated 174 key sizes and a different set of signature and hash algorithms over 175 time, in order to maintain an acceptable level of cryptographic 176 security to protect the integrity of BGPSEC. This profile should be 177 updated to specify such future requirements, when appropriate. 179 CAs and RPs SHOULD be capable of supporting a transition to allow for 180 the phased introduction of additional encryption algorithms and key 181 specifications, and also accommodate the orderly deprecation of 182 previously specified algorithms and keys. Accordingly, CAs and RPs 183 SHOULD be capable of supporting multiple RPKI algorithm and key 184 profiles simultaneously within the scope of such anticipated 185 transitions. The recommended procedures to implement such a 186 transition of key sizes and algorithms is not specified in this 187 document. 189 6. Security Considerations 191 The Security Considerations of [RFC3279], [RFC5480], [RFC6090], 192 [ID.sidr-rpki-algs], and [ID.bgpsec-pki-profiles] apply to 193 certificates. The security considerations of [RFC3279], [RFC6090], 194 [ID.sidr-rpki-algs], [ID.bgpsec-pki-profiles] apply to certification 195 requests. The security considerations of [RFC3279], [ID.sidr-bgpsec- 196 protocol], and [RFC6090] apply to BGPSEC Update messages. No new 197 security are introduced as a result of this specification. 199 7. IANA Considerations 201 The Internet Assigned Numbers Authority (IANA) is requested to define 202 the "BGPSEC Algorithm Suite Registry" described below. 204 An algorithm suite consists of a digest algorithm and a signature 205 algorithm. This specification creates an IANA registry of one-octet 206 BGPSEC algorithm suite identifiers. Additionally, this document 207 registers a single algorithm suite which uses the digest algorithm 208 SHA-256 and the signature algorithm ECDSA on the P-256 curve 209 [RFC5480]. 211 BGPSEC Algorithm Suites Registry 213 Digest Signature Algorithm Suite Specification 214 Algorithm Algorithm Identifier Pointer 215 +----------------------------------------------------------------+ 216 | SHA-256 | ECDSA P-256 | TBD | RFC 5480 | 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 [RFC4020]. Assignments consist of a digest algorithm 222 name, signature algorithm name, and the algorithm suite identifier 223 value. 225 10. Acknowledgements 227 The author wishes to thank Geoff Huston for producing [ID.sidr-rpki- 228 algs], which this document is heavily based on. I'd also like to 229 thank Roque Gagliano for his review and comments. 231 11. References 233 11.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 239 Request Syntax Specification Version 1.7", RFC 2986, 240 November 2000. 242 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 243 Identifiers for the Internet X.509 Public Key 244 Infrastructure Certificate and Certificate Revocation List 245 (CRL) Profile", RFC 3279, April 2002. 247 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 248 Standards Track Code Points", BCP 100, RFC 4020, February 249 2005. 251 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 252 Certificate Request Message Format (CRMF)", RFC 4211, 253 September 2005. 255 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 256 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 257 2008. 259 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 260 Housley, R., and W. Polk, "Internet X.509 Public Key 261 Infrastructure Certificate and Certificate Revocation List 262 (CRL) Profile", RFC 5280, May 2008. 264 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 265 "Elliptic Curve Cryptography Subject Public Key 266 Information", RFC 5480, March 2009. 268 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 269 Curve Cryptography Algorithms", RFC 6090, February 2011. 271 [SHS] National Institute of Standards and Technology (NIST), "FIPS 272 Publication 180-3: Secure Hash Standard", FIPS Publication 273 180-3, October 2008. 275 [ID.sidr-res-cert-profile] Huston, G., Michaelson, G., and R. 276 Loomans, "A Profile for X.509 PKIX Resource Certificates", 277 draft-ietf-sidr-res-certs, work-in-progress. 279 [ID.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key 280 Sizes for use in the Resource Public Key Infrastructure", 281 draft-ietf-sidr-rpki-algs, work-in-progress. 283 [ID.sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol 284 Specification", draft-ietf-sidr-bgpsec-protocol, work-in- 285 progress. 287 [ID.bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile for 288 BGPSEC Router Certificates, Certificate Revocation Lists, 289 and Certification Requests", draft-ietf-sidr-bpgsec-pki- 290 profiles, work-in-progress. 292 11.1. Informative References 294 None. 296 Authors' Addresses 298 Sean Turner 299 IECA, Inc. 300 3057 Nutley Street, Suite 106 301 Fairfax, VA 22031 302 USA 304 EMail: turners@ieca.com