idnits 2.17.1 draft-ietf-sidr-rfc6485bis-03.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 obsoletes RFC6485, 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 (July 24, 2015) is 3193 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 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 6480 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Obsolete informational reference (is this intentional?): RFC 6485 (Obsoleted by RFC 7935) -- Obsolete informational reference (is this intentional?): RFC 6486 (Obsoleted by RFC 9286) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR G. Huston 3 Internet-Draft G. Michaelson, Ed. 4 Obsoletes: 6485 (if approved) APNIC 5 Intended status: Standards Track July 24, 2015 6 Expires: January 25, 2016 8 The Profile for Algorithms and Key Sizes for use in the Resource Public 9 Key Infrastructure 10 draft-ietf-sidr-rfc6485bis-03.txt 12 Abstract 14 This document specifies the algorithms, algorithms' parameters, 15 asymmetric key formats, asymmetric key size, and signature format for 16 the Resource Public Key Infrastructure (RPKI) subscribers that 17 generate digital signatures on certificates, Certificate Revocation 18 Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and 19 certification requests as well as for the relying parties (RPs) that 20 verify these digital signatures. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 25, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . . . 4 60 3.1. Public Key Format . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 5 62 4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Additional Requirements . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 8. Changes Aplied to RFC6485 . . . . . . . . . . . . . . . . . . . 6 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 This document specifies: 77 * the digital signature algorithm and parameters; 78 * the hash algorithm and parameters; 79 * the public and private key formats; and, 80 * the signature format 81 used by Resource Public Key Infrastructure (RPKI) [RFC6480] 82 subscribers when they apply digital signatures to certificates and 83 Certificate Revocation Lists (CRLs) [RFC5280], Cryptographic Message 84 Syntax (CMS) signed objects [RFC5652] (e.g., Route Origin 85 Authorizations (ROAs) [RFC6482] and manifests [RFC6486]), and 86 certification requests [RFC2986][RFC4211]. Relying parties (RPs) 87 also use the algorithms defined in this document to verify RPKI 88 subscribers' digital signatures [RFC6480]. 90 This document is referenced by other RPKI profiles and 91 specifications, including the RPKI Certificate Policy (CP) [RFC6484], 92 the RPKI Certificate Profile [RFC6487], the RPKI Architecture 93 [RFC6480], and the Signed Object Template for the RPKI [RFC6488]. 94 Familiarity with these documents is assumed. 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Algorithms 104 Two cryptographic algorithms are used in the RPKI: 106 * The signature algorithm used in certificates, CRLs, CMS signed 107 objects, and certification requests is RSA Public-Key 108 Cryptography Standards (PKCS) #1 Version 1.5 (sometimes 109 referred to as "RSASSA-PKCS1-v1_5") from Section 8.2 of 110 [RFC3447]. 112 * The hashing algorithm used in certificates, CRLs, CMS signed 113 objects and certification requests is SHA-256 [SHS] (see note 114 below). 116 NOTE: The exception is the use of SHA-1 [SHS] when CAs generate 117 authority and subject key identifiers [RFC6487]. 119 In certificates, CRLs, and certification requests the hashing and 120 digital signature algorithms are identified together, i.e., "RSA 121 PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The 122 Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST 123 be used in these products. 125 For CMS SignedData, the object identifier and parameters for SHA-256 126 in [RFC5754] MUST be used for the SignedData digestAlgorithms field 127 and the SignerInfo digestAlgorithm field when generating and 128 verifying CMS SignedData objects. The object identifier and 129 parameters for rsaEncryption MUST be used for the SignerInfo 130 signatureAlgorithm field when generating CMS SignedData objects. 131 RPKI implementations MUST accept CMS SignedData objects that use the 132 object identifier and parameters for either rsaEncryption or 133 sha256WithRSAEncryption for the SignerInfo signatureAlgorithm field 134 when verifying CMS SignedData objects. 136 The OID is in the following locations: 138 In the certificate, the OID appears in the signature and 139 signatureAlgorithm fields [RFC4055]; 141 In the CRL, the OID appears in the signatureAlgorithm field 142 [RFC4055]; and 144 In a certification request, the OID appears in the PKCS #10 145 signatureAlgorithm field [RFC2986], or in the Certificate Request 146 Message Format (CRMF) POPOSigningKey algorithmIdentifier field 147 [RFC4211]. 149 In CMS SignedData, the hashing (message digest) and digital signature 150 algorithms are identified separately. The object identifier and 151 parameters for SHA-256 (as defined in [RFC5754]) MUST be used for the 152 SignedData digestAlgorithms field and the SignerInfo digestAlgorithm 153 field. The object identifier and parameters for rsaEncryption 154 [RFC3370] MUST be used for the SignerInfo signatureAlgorithm field 155 when generating CMS SignedData objects. RPKI implementations MUST 156 accept either rsaEncryption or sha256WithRSAEncryption for the 157 SignerInfo signatureAlgorithm field when verifying CMS SignedData 158 objects (for compatibility with objects produced by implementations 159 conforming to [RFC6485]. 161 3. Asymmetric Key Pair Formats 163 The RSA key pairs used to compute the signatures MUST have a 2048-bit 164 modulus and a public exponent (e) of 65,537. 166 3.1. Public Key Format 168 The subject's public key is included in subjectPublicKeyInfo 169 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 170 The values for the structures and their sub-structures follow: 172 algorithm (which is an AlgorithmIdentifier type): 173 The object identifier for RSA PKCS#1 v1.5 with SHA-256 MUST be 174 used in the algorithm field, as specified in Section 5 of 175 [RFC4055]. The value for the associated parameters from that 176 clause MUST also be used for the parameters field. 178 subjectPublicKey: 179 RSAPublicKey MUST be used to encode the certificate's 180 subjectPublicKey field, as specified in [RFC4055]. 182 3.2. Private Key Format 184 Local policy determines the private key format. 186 4. Signature Format 188 The structure for the certificate's signature field is as specified 189 in Section 1.2 of [RFC4055]. The structure for the CMS SignedData's 190 signature field is as specified in [RFC5652]. 192 5. Additional Requirements 194 It is anticipated that the RPKI will require the adoption of updated 195 key sizes and a different set of signature and hash algorithms over 196 time, in order to maintain an acceptable level of cryptographic 197 security to protect the integrity of signed products in the RPKI. 198 This profile should be replaced to specify such future requirements, 199 as and when appropriate. 201 Certification Authorities (CAs) and RPs SHOULD be capable of 202 supporting a transition to allow for the phased introduction of 203 additional encryption algorithms and key specifications, and also 204 accommodate the orderly deprecation of previously specified 205 algorithms and keys. Accordingly, CAs and RPs SHOULD be capable of 206 supporting multiple RPKI algorithm and key profiles simultaneously 207 within the scope of such anticipated transitions. The recommended 208 procedures to implement such a transition of key sizes and algorithms 209 is not specified in [RFC6916] 211 6. Security Considerations 213 The Security Considerations of [RFC4055], [RFC5280], and [RFC6487] 214 apply to certificate and CRLs. The Security Considerations of 215 [RFC2986], [RFC4211], and [RFC6487] apply to certification /> 216 requests. The Security Considerations of [RFC5754] apply to CMS 217 signed objects. No new security threats are introduced as a result 218 of this specification. 220 7. IANA Considerations 222 [Remove before publication. There are no IANA considerations in this 223 document.] 225 8. Changes Aplied to RFC6485 227 This update includes a slight technical change to [RFC6485] that is 228 considered to be outside the limited scope of an erratum. The 229 document update process has included other errata and also corrected 230 a number of nits. 232 Section 2 of [RFC6485] specified sha256WithRSAEncryption as the OID 233 to use for the SignerInfo signatureAlgorithm field in CMS 234 SignedObjects. However, existing implementations use the 235 rsaEncryption OID for this field. (Support for rsaEncryption in 3rd 236 party cryptographic libraries is better than sha256WithRSAEncryption, 237 perhaps because [RFC3370] says that support for rsaEncryption is 238 required while support for OIDs that specify both RSA and a digest 239 algorithm is optional.) 241 Rather than force existing implementations to switch to 242 sha256WithRSAEncryption, this document was changed to follow existing 243 practice. This does not represent a cryptographic algorithm change, 244 just an identifier change. (Unlike certificates, CRLs, and 245 certification requests, CMS signed objects have a separate algorithm 246 identifier field for the hash (digest) algorithm, and that field is 247 already required to contain the id-sha256 OID per Section 2.) 249 To avoid compatibility problems, RPs are still required to accept 250 sha256WithRSAEncryption if encountered. 252 Other changes include: 254 * Minor wording and typo fixes. 256 * Some incorrect references were fixed ([RFC5652] instead of 257 [RFC3370], [RFC3447] instead of [RFC4055]). 258 * Additional citations were added to the Introduction. 259 * Section 2 now references the correct CRMF POPOSigningKey field 260 (algorithmIdentifier instead of signature). 261 * Certification requests are now mentioned along with 262 certificates, CRLs, and CMS signed objects. 263 * Section 5 now cites [RFC6916] (algorithm agility). 264 * "Signed object" is now "CMS signed object" everywhere. 266 9. Acknowledgments 268 The authors acknowledge the reuse in this document of material 269 originally contained in working drafts the RPKI Certificate Policy 270 [RFC6484] and resource certificate profile [RFC6487] documents. The 271 co-authors of these two documents, namely Stephen Kent, Derrick Kong, 272 Karen Seo, Ronald Watro, George Michaelson and Robert Loomans, are 273 acknowledged, with thanks. The constraint on key size noted in this 274 profile is the outcome of comments from Stephen Kent and review 275 comments from David Cooper. Sean Turner has provided additional 276 review input to this document. 278 Andrew Chi and David Mandelberg discovered the issue addressed in 279 this update to [RFC6485], and the changes in this updated 280 specification reflect the outcome of a discussion between Rob Austein 281 and Matt Lepinski on the SIDR Working group mailing list. Richard 282 Hansen edited this update to the document. 284 10. References 286 10.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 290 RFC2119, March 1997, 291 . 293 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 294 Request Syntax Specification Version 1.7", RFC 2986, 295 DOI 10.17487/RFC2986, November 2000, 296 . 298 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 299 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 300 . 302 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 303 Standards (PKCS) #1: RSA Cryptography Specifications 304 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, 305 February 2003, . 307 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 308 Algorithms and Identifiers for RSA Cryptography for use in 309 the Internet X.509 Public Key Infrastructure Certificate 310 and Certificate Revocation List (CRL) Profile", RFC 4055, 311 DOI 10.17487/RFC4055, June 2005, 312 . 314 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 315 Certificate Request Message Format (CRMF)", RFC 4211, 316 DOI 10.17487/RFC4211, September 2005, 317 . 319 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 320 Housley, R., and W. Polk, "Internet X.509 Public Key 321 Infrastructure Certificate and Certificate Revocation List 322 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 323 . 325 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 326 RFC 5652, DOI 10.17487/RFC5652, September 2009, 327 . 329 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 330 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, 331 January 2010, . 333 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 334 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 335 February 2012, . 337 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 338 Policy (CP) for the Resource Public Key Infrastructure 339 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, 340 February 2012, . 342 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 343 X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/ 344 RFC6487, February 2012, 345 . 347 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 348 Template for the Resource Public Key Infrastructure 349 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 350 . 352 [SHS] National Institute of Standards and Technology (NIST), 353 "FIPS Publication 180-3: Secure Hash Standard", FIPS 354 Publication 180-3, October 2008. 356 10.2. Informative References 358 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 359 Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/ 360 RFC6482, February 2012, 361 . 363 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 364 Use in the Resource Public Key Infrastructure (RPKI)", 365 RFC 6485, DOI 10.17487/RFC6485, February 2012, 366 . 368 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 369 "Manifests for the Resource Public Key Infrastructure 370 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 371 . 373 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 374 Procedure for the Resource Public Key Infrastructure 375 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, 376 April 2013, . 378 Authors' Addresses 380 Geoff Huston 381 APNIC 383 Email: gih@apnic.net 385 George Michaelson (editor) 386 APNIC 388 Email: ggm@apnic.net