idnits 2.17.1 draft-ietf-sidr-rfc6485bis-04.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 (October 16, 2015) is 3114 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 October 16, 2015 6 Expires: April 18, 2016 8 The Profile for Algorithms and Key Sizes for use in the Resource Public 9 Key Infrastructure 10 draft-ietf-sidr-rfc6485bis-04.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 April 18, 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 . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Private Key Format . . . . . . . . . . . . . . . . . . . . 5 62 4. Signature Format . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Additional Requirements . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 8 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 The OID is in the following locations: 127 In the certificate, the OID appears in the signature and 128 signatureAlgorithm fields [RFC4055]; 130 In the CRL, the OID appears in the signatureAlgorithm field 131 [RFC4055]; and 133 In a certification request, the OID appears in the PKCS #10 134 signatureAlgorithm field [RFC2986], or in the Certificate Request 135 Message Format (CRMF) POPOSigningKey algorithmIdentifier field 136 [RFC4211]. 138 In CMS SignedData, the hashing (message digest) and digital signature 139 algorithms are identified separately. The object identifier and 140 parameters for SHA-256 (as defined in [RFC5754]) MUST be used for the 141 SignedData digestAlgorithms field and the SignerInfo digestAlgorithm 142 field. The object identifier and parameters for rsaEncryption 143 [RFC3370] MUST be used for the SignerInfo signatureAlgorithm field 144 when generating CMS SignedData objects. RPKI implementations MUST 145 accept either rsaEncryption or sha256WithRSAEncryption for the 146 SignerInfo signatureAlgorithm field when verifying CMS SignedData 147 objects (for compatibility with objects produced by implementations 148 conforming to [RFC6485]). 150 3. Asymmetric Key Pair Formats 152 The RSA key pairs used to compute the signatures MUST have a 2048-bit 153 modulus and a public exponent (e) of 65,537. 155 3.1. Public Key Format 157 The subject's public key is included in subjectPublicKeyInfo 158 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 159 The values for the structures and their sub-structures follow: 161 algorithm (which is an AlgorithmIdentifier type): 162 The object identifier for RSA PKCS#1 v1.5 with SHA-256 MUST be 163 used in the algorithm field, as specified in Section 5 of 164 [RFC4055]. The value for the associated parameters from that 165 clause MUST also be used for the parameters field. 167 subjectPublicKey: 168 RSAPublicKey MUST be used to encode the certificate's 169 subjectPublicKey field, as specified in [RFC4055]. 171 3.2. Private Key Format 173 Local policy determines the private key format. 175 4. Signature Format 177 The structure for the certificate's signature field is as specified 178 in Section 1.2 of [RFC4055]. The structure for the CMS SignedData's 179 signature field is as specified in [RFC5652]. 181 5. Additional Requirements 183 It is anticipated that the RPKI will require the adoption of updated 184 key sizes and a different set of signature and hash algorithms over 185 time, in order to maintain an acceptable level of cryptographic 186 security to protect the integrity of signed products in the RPKI. 187 This profile should be replaced to specify such future requirements, 188 as and when appropriate. 190 Certification Authorities (CAs) and RPs SHOULD be capable of 191 supporting a transition to allow for the phased introduction of 192 additional encryption algorithms and key specifications, and also 193 accommodate the orderly deprecation of previously specified 194 algorithms and keys. Accordingly, CAs and RPs SHOULD be capable of 195 supporting multiple RPKI algorithm and key profiles simultaneously 196 within the scope of such anticipated transitions. The recommended 197 procedures to implement such a transition of key sizes and algorithms 198 is specified in [RFC6916] 200 6. Security Considerations 202 The Security Considerations of [RFC4055], [RFC5280], and [RFC6487] 203 apply to certificate and CRLs. The Security Considerations of 204 [RFC2986], [RFC4211], and [RFC6487] apply to certification /> 205 requests. The Security Considerations of [RFC5754] apply to CMS 206 signed objects. No new security threats are introduced as a result 207 of this specification. 209 7. IANA Considerations 211 [Remove before publication. There are no IANA considerations in this 212 document.] 214 8. Changes Aplied to RFC6485 216 This update includes a slight technical change to [RFC6485] that is 217 considered to be outside the limited scope of an erratum. The 218 document update process has included other errata and also corrected 219 a number of nits. 221 Section 2 of [RFC6485] specified sha256WithRSAEncryption as the OID 222 to use for the SignerInfo signatureAlgorithm field in CMS 223 SignedObjects. However, existing implementations use the 224 rsaEncryption OID for this field. (Support for rsaEncryption in 3rd 225 party cryptographic libraries is better than sha256WithRSAEncryption, 226 perhaps because [RFC3370] says that support for rsaEncryption is 227 required while support for OIDs that specify both RSA and a digest 228 algorithm is optional.) 230 Rather than force existing implementations to switch to 231 sha256WithRSAEncryption, this document was changed to follow existing 232 practice. This does not represent a cryptographic algorithm change, 233 just an identifier change. (Unlike certificates, CRLs, and 234 certification requests, CMS signed objects have a separate algorithm 235 identifier field for the hash (digest) algorithm, and that field is 236 already required to contain the id-sha256 OID per Section 2.) 238 To avoid compatibility problems, RPs are still required to accept 239 sha256WithRSAEncryption if encountered. 241 Other changes include: 243 * Minor wording and typo fixes. 244 * Some incorrect references were fixed ([RFC5652] instead of 245 [RFC3370], [RFC3447] instead of [RFC4055]). 246 * Additional citations were added to the Introduction. 247 * Section 2 now references the correct CRMF POPOSigningKey field 248 (algorithmIdentifier instead of signature). 249 * Certification requests are now mentioned along with 250 certificates, CRLs, and CMS signed objects. 251 * Section 5 now cites [RFC6916] (algorithm agility). 252 * "Signed object" is now "CMS signed object" everywhere. 254 9. Acknowledgments 256 The authors acknowledge the reuse in this document of material 257 originally contained in working drafts the RPKI Certificate Policy 258 [RFC6484] and resource certificate profile [RFC6487] documents. The 259 co-authors of these two documents, namely Stephen Kent, Derrick Kong, 260 Karen Seo, Ronald Watro, George Michaelson and Robert Loomans, are 261 acknowledged, with thanks. The constraint on key size noted in this 262 profile is the outcome of comments from Stephen Kent and review 263 comments from David Cooper. Sean Turner has provided additional 264 review input to this document. 266 Andrew Chi and David Mandelberg discovered the issue addressed in 267 this update to [RFC6485], and the changes in this updated 268 specification reflect the outcome of a discussion between Rob Austein 269 and Matt Lepinski on the SIDR Working group mailing list. Richard 270 Hansen edited this update to the document. 272 10. References 274 10.1. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 278 RFC2119, March 1997, 279 . 281 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 282 Request Syntax Specification Version 1.7", RFC 2986, 283 DOI 10.17487/RFC2986, November 2000, 284 . 286 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 287 Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, 288 . 290 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 291 Standards (PKCS) #1: RSA Cryptography Specifications 292 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, 293 February 2003, . 295 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 296 Algorithms and Identifiers for RSA Cryptography for use in 297 the Internet X.509 Public Key Infrastructure Certificate 298 and Certificate Revocation List (CRL) Profile", RFC 4055, 299 DOI 10.17487/RFC4055, June 2005, 300 . 302 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 303 Certificate Request Message Format (CRMF)", RFC 4211, 304 DOI 10.17487/RFC4211, September 2005, 305 . 307 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 308 Housley, R., and W. Polk, "Internet X.509 Public Key 309 Infrastructure Certificate and Certificate Revocation List 310 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 311 . 313 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 314 RFC 5652, DOI 10.17487/RFC5652, September 2009, 315 . 317 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 318 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, 319 January 2010, . 321 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 322 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 323 February 2012, . 325 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 326 Policy (CP) for the Resource Public Key Infrastructure 327 (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, 328 February 2012, . 330 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 331 X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/ 332 RFC6487, February 2012, 333 . 335 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 336 Template for the Resource Public Key Infrastructure 337 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 338 . 340 [SHS] National Institute of Standards and Technology (NIST), 341 "FIPS Publication 180-3: Secure Hash Standard", FIPS 342 Publication 180-3, October 2008. 344 10.2. Informative References 346 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 347 Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/ 348 RFC6482, February 2012, 349 . 351 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 352 Use in the Resource Public Key Infrastructure (RPKI)", 353 RFC 6485, DOI 10.17487/RFC6485, February 2012, 354 . 356 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 357 "Manifests for the Resource Public Key Infrastructure 358 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 359 . 361 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 362 Procedure for the Resource Public Key Infrastructure 363 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, 364 April 2013, . 366 Authors' Addresses 368 Geoff Huston 369 APNIC 371 Email: gih@apnic.net 373 George Michaelson (editor) 374 APNIC 376 Email: ggm@apnic.net