idnits 2.17.1 draft-turner-sidr-bgpsec-algs-00.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 (July 26, 2011) is 4648 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- No information found for draft-turner-sidr-bpgsec-pki-profiles - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID.bgpsec-pki-profiles' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Turner 3 Internet-Draft IECA 4 Updates: [ID.sidr-rpki-algs] July 26, 2011 5 Intended Status: Standards Track 6 Expires: January 27, 2012 8 BGP Algorithms, Key Formats, & Signature Formats 9 draft-turner-sidr-bgpsec-algs-00 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 January 27, 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 certificates [ID.bgpsec-pki-profiles], generating BGPSEC Update 64 messages [ID.sidr-bgpsec-protocol], and verifying BGPSEC Update 65 messages. 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 1.1. Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 79 "OPTIONAL" in this document are to be interpreted as described in 80 [RFC2119]. 82 2. Algorithms 84 Four cryptographic algorithms are used to support BGPSEC: 86 o The signature algorithm used when issuing certificates and CRLs 87 MUST be as specified in [ID.sidr-rpki-algs]. 89 o The signature algorithm used in certification requests and BGPSEC 90 Update messages MUST be Elliptic Curve Digital Signature 91 Algorithm (ECDSA) [DSS]. 93 o The hashing algorithm used when issuing certificates and CRLs 94 MUST be as specified in [ID.sidr-rpki-algs]. 96 o The hashing algorithm use when generating certification requests 97 and BGPSEC Update messages MUST be SHA-256 [SHS]. Hash 98 algorithms are not identified by themselves in certificates, or 99 BGPSEC Update messages instead they are combined with the digital 100 signature algorithm (see below). 102 NOTE: The exception to the above hashing algorithm is the use of 103 SHA-1 [SHS] when CAs generate authority and subject key 104 identifiers [ID.bgpsec-pki-profiles]. 106 To support BGPSEC, the algorithms are identified as follows: 108 o In certificates and CRLs, an Object Identifier (OID) is used. 109 The value and locations are as specified in section 2 of 110 [ID.sidr-rpki-algs]. 112 o In certification request, an OID is used. The ecdsa-with-SHA256 113 OID [RFC5480] MUST appear in the PKCS #10 signatureAlgorithm 114 field [RFC4211] or in Certificate Request Message Format (CRMF) 115 POPOSigningKey signature field [RFC2986]. 117 o In BGPSEC Update messages, the ECDSA with SHA-256 Algorithm Suite 118 Identifier from Section 7 is included in the Signature-Block 119 List's Algorithm Suite Identifier field. 121 3. Asymmetric Key Format 123 The RSA key pairs used to compute signatures on CA certificates, 124 BGPSEC Router Certificates, and CRLs are as specified in section 3 of 125 [ID.sidr-rpki-algs]. The remainder of this section addresses key 126 formats found in the BGPSEC router certificate requests and in BGPSEC 127 Router Certificates. 129 The ECDSA key pairs used to compute signatures for certificate 130 requests and BGPSEC Update messages MUST come from the P-256 curve 131 [RFC5480]. The public key pair MUST use the uncompressed form. 133 3.1. Public Key Format 135 The Subject's public key is included in subjectPublicKeyInfo 136 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 137 The values for the structures and their sub-structures follow: 139 o algorithm (which is an AlgorithmIdentifier type): The id- 140 ecPublicKey OID MUST be used in the algorithm field, as specified 141 in 2.1.1 of [RFC5480]. The value for the associated parameters 142 MUST be secp256r1, as specified in 2.1.1.1 of [RFC5480]. 144 o subjectPublicKey: ECPublicKey MUST be used to encode the 145 certificate's subjectPublicKey field, as specified in Section 2.2 146 of [RFC5480]. 148 3.2. Private Key Format 150 Local Policy determines private key format. 152 4. Signature Format 154 The structure for the certificate's and CRL's signature field MUST be 155 as specified in Section 4 of [ID.sidr-rpki-algs]. The structure for 156 the certification request's and BGPSEC Update message's signature 157 field MUST be as specified in Section 2.2.3 of [RFC3279]. 159 5. Additional Requirements 161 It is anticipated that BGPSEC will require the adoption of updated 162 key sizes and a different set of signature and hash algorithms over 163 time, in order to maintain an acceptable level of cryptographic 164 security to protect the integrity of BGPSEC. This profile should be 165 updated to specify such future requirements, when appropriate. 167 CAs and RPs SHOULD be capable of supporting a transition to allow for 168 the phased introduction of additional encryption algorithms and key 169 specifications, and also accommodate the orderly deprecation of 170 previously specified algorithms and keys. Accordingly, CAs and RPs 171 SHOULD be capable of supporting multiple RPKI algorithm and key 172 profiles simultaneously within the scope of such anticipated 173 transitions. The recommended procedures to implement such a 174 transition of key sizes and algorithms is not specified in this 175 document. 177 6. Security Considerations 179 The Security Considerations of [RFC3279], [RFC5480], [ID.sidr-rpki- 180 algs], and [ID.bgpsec-pki-profiles] apply to certificates. The 181 security considerations of [RFC3279], [ID.sidr-rpki-algs], 182 [ID.bgpsec-pki-profiles] apply to certification requests. The 183 security considerations of [RFC3279] and [ID.sidr-bgpsec-protocol] 184 apply to BGPSEC Update messages. No new security are introduced as a 185 result of this specification. 187 7. IANA Considerations 189 The Internet Assigned Numbers Authority (IANA) is requested to define 190 the "BGPSEC Algorithm Suite Registry" described below. 192 An algorithm suite consists of a digest algorithm and a signature 193 algorithm. This specification creates an IANA registry of one-octet 194 BGPSEC algorithm suite identifiers. Additionally, this document 195 registers a single algorithm suite which uses the digest algorithm 196 SHA-256 and the signature algorithm ECDSA on the P-256 curve 197 [RFC5480]. 199 BGPSEC Algorithm Suites Registry 201 Digest Signature Algorithm Suite Specification 202 Algorithm Algorithm Identifier Pointer 203 +----------------------------------------------------------------+ 204 | SHA-256 | ECDSA P-256 | TBD | RFC 5480 | 205 +----------------------------------------------------------------+ 207 Future assignments are to be made using either the Standards Action 208 process defined in [RFC5226], or the Early IANA Allocation process 209 defined in [RFC4020]. Assignments consist of a digest algorithm 210 name, signature algorithm name, and the algorithm suite identifier 211 value. 213 10. Acknowledgements 215 The author wishes to thank Geoff Huston for producing [ID.sidr-rpki- 216 algs], which this document is heavily based on. 218 11. References 220 11.1. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 226 Request Syntax Specification Version 1.7", RFC 2986, 227 November 2000. 229 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 230 Identifiers for the Internet X.509 Public Key 231 Infrastructure Certificate and Certificate Revocation List 232 (CRL) Profile", RFC 3279, April 2002. 234 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 235 Standards Track Code Points", BCP 100, RFC 4020, February 236 2005. 238 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 239 Certificate Request Message Format (CRMF)", RFC 4211, 240 September 2005. 242 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 243 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 244 2008. 246 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 247 Housley, R., and W. Polk, "Internet X.509 Public Key 248 Infrastructure Certificate and Certificate Revocation List 249 (CRL) Profile", RFC 5280, May 2008. 251 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 252 "Elliptic Curve Cryptography Subject Public Key 253 Information", RFC 5480, March 2009. 255 [DSS] National Institute of Standards and Technology (NIST), FIPS 256 Publication 186-3: Digital Signature Standard, June 2009. 258 [SHS] National Institute of Standards and Technology (NIST), "FIPS 259 Publication 180-3: Secure Hash Standard", FIPS Publication 260 180-3, October 2008. 262 [ID.sidr-res-cert-profile] Huston, G., Michaelson, G., and R. 263 Loomans, "A Profile for X.509 PKIX Resource Certificates", 264 draft-ietf-sidr-res-certs, work-in-progress. 266 [ID.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key 267 Sizes for use in the Resource Public Key Infrastructure", 268 draft-ietf-sidr-rpki-algs, work-in-progress. 270 [ID.sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol 271 Specification", draft-lepinski-bgpsec-protocol, work-in- 272 progress. 274 [ID.bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile for 275 BGPSEC Router Certificates, Certificate Revocation Lists, 276 and Certification Requests", draft-turner-sidr-bpgsec-pki- 277 profiles-00, work-in-progress. 279 11.1. Informative References 281 None. 283 Authors' Addresses 285 Sean Turner 286 IECA, Inc. 287 3057 Nutley Street, Suite 106 288 Fairfax, VA 22031 289 USA 290 EMail: turners@ieca.com