idnits 2.17.1 draft-ietf-sidr-rfc6485bis-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 : ---------------------------------------------------------------------------- -- 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 (March 28, 2014) is 3681 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 ** 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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 March 28, 2014 6 Expires: September 29, 2014 8 The Profile for Algorithms and Key Sizes for use in the Resource Public 9 Key Infrastructure 10 draft-ietf-sidr-rfc6485bis-01.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 subscribers that generate 17 digital signatures on certificates, Certificate Revocation Lists, and 18 signed objects as well as for the Relying Parties (RPs) that verify 19 these digital signatures. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 29, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 This document specifies: 57 * the digital signature algorithm and parameters; 58 * the hash algorithm and parameters; 59 * the public and private key formats; and, 60 * the signature format 61 used by Resource Public Key Infrastructure (RPKI) subscribers when 62 they apply digital signatures to certificates, Certificate Revocation 63 Lists (CRLs), and signed objects (e.g., Route Origin Authorizations 64 (ROAs) and manifests). Relying Parties (RPs) also use this document 65 when verify RPKI subscribers' digital signatures [RFC6480]. 67 This document is referenced by other RPKI profiles and 68 specifications, including the RPKI Certificate Policy (CP) [RFC6484], 69 the RPKI Certificate Profile [RFC6487], the SIDR Architecture 70 [RFC6480], and the Signed Object Template for the RPKI [RFC2119]. 71 Familiarity with these documents is assumed. 73 1.1. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Algorithms 81 Two cryptographic algorithms are used in the RPKI: 83 * The signature algorithm used in certificates, CRLs, and signed 84 objects is RSA Public-Key Cryptography Standards (PKCS) #1 85 Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from 86 Section 5 of [RFC4055]. 88 * The hashing algorithm used in certificates, CRLs, and signed 89 objects is SHA-256 [SHS] (see note below). Hashing algorithms 90 are not identified individually in certificates and CRLs, as 91 the identity of the hashing algorithm is combined with the 92 identity of the digital signature algorithm. 94 When used in the context of the Cryptographic Message Syntax 95 (CMS) SignedData, the hashing algorithm is identified 96 individually (in this case the hashing algorithm is sometimes 97 called a message digest algorithm). 99 NOTE: The exception to the above hashing algorithm use is the 100 use of SHA-1 [SHS] when CAs generate authority and subject key 101 identifiers [RFC6487]. 103 For generating and verifying certificates, and CRLs the hashing and 104 digital signature algorithms are referred to together, i.e., "RSA 105 PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The 106 Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST 107 be used in this case. 109 For CMS SignedData, the object identifier and parameters for SHA-256 110 in [RFC5754] MUST be used for the SignedData digestAlgorithms field 111 and the SignerInfo digestAlgorithm field when generating and 112 verifying CMS SignedData objects. The object identifier and 113 parameters for rsaEncryption MUST be used for the SignerInfo 114 signatureAlgorithm field when generating CMS SignedData objects. 115 RPKI implementations MUST accept CMS SignedData objects that use the 116 object identifier and parameters for either rsaEncryption or 117 sha256WithRSAEncryption for the SignerInfo signatureAlgorithm field 118 when verifying CMS SignedData objects. 120 Locations for this OID are as follows: 122 In the certificate, the OID appears in the signature and 123 signatureAlgorithm fields [RFC4055]; 125 In the CRL, the OID appears in the signatureAlgorithm field 126 [RFC4055]; 128 In CMS SignedData, the OID appears in each SignerInfo 129 signatureAlgorithm field, the SignerInfo digestAlgorithm field, 130 and in the SignedData digestAlgorithms [RFC5652]; and, 132 In a certification request, the OID appears in the PKCS #10 133 signatureAlgorithm field [RFC2986], or in the Certificate Request 134 Message Format (CRMF) POPOSigningKey signature field [RFC4211]. 136 3. Asymmetric Key Pair Formats 138 The RSA key pairs used to compute the signatures MUST have a 2048-bit 139 modulus and a public exponent (e) of 65,537. 141 3.1. Public Key Format 143 The Subject's public key is included in subjectPublicKeyInfo 144 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 145 The values for the structures and their sub-structures follow: 147 algorithm (which is an AlgorithmIdentifier type): 148 The object identifier for RSA PKCS#1 v1.5 with SHA-256 MUST be 149 used in the algorithm field, as specified in Section 5 of 150 [RFC4055]. The value for the associated parameters from that 151 clause MUST also be used for the parameters field. 153 subjectPublicKey: 154 RSAPublicKey MUST be used to encode the certificate's 155 subjectPublicKey field, as specified in [RFC4055]. 157 3.2. Private Key Format 159 Local Policy determines private key format. 161 4. Signature Format 163 The structure for the certificate's signature field is as specified 164 in Section 1.2 of [RFC4055]. The structure for the Cryptographic 165 Message Syntax (CMS) SignedData's signature field is as specified in 166 [RFC5652]. 168 5. Additional Requirements 170 It is anticipated that the RPKI will require the adoption of updated 171 key sizes and a different set of signature and hash algorithms over 172 time, in order to maintain an acceptable level of cryptographic 173 security to protect the integrity of signed products in the RPKI. 174 This profile should be relaced to specify such future requirements, 175 as and when appropriate. 177 CAs and RPs SHOULD be capable of supporting a transition to allow for 178 the phased introduction of additional encryption algorithms and key 179 specifications, and also accommodate the orderly deprecation of 180 previously specified algorithms and keys. Accordingly, CAs and RPs 181 SHOULD be capable of supporting multiple RPKI algorithm and key 182 profiles simultaneously within the scope of such anticipated 183 transitions. The recommended procedures to implement such a 184 transition of key sizes and algorithms is not specified in this 185 document. 187 6. Security Considerations 189 The Security Considerations of [RFC4055], [RFC5280], and [RFC6487] 190 apply to certificate and CRLs. The Security Considerations of 191 [RFC5754] apply to signed objects. No new security are introduced as 192 a result of this specification. 194 7. IANA Considerations 196 [Remove before publication. There are no IANA considerations in this 197 document.] 199 8. Changes Aplied to RFC6485 201 This document represents a slight technical change to [RFC6485] that 202 is considered to be outside the limited scope of an erratum. 204 Section 2 of [RFC6485] specified a single signature algorithm (SHA- 205 256) and a single CMS OID, sha256withRSAEncryption, to be used for 206 the SignerInfo field of the CMS object. A closer reading of 207 [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field 208 must support use of the rsaEncryption OID for full conformance with 209 the CMS specifications, and the normative references in [RFC6485] 210 inherited this requirement. 212 This document changes Section 2 of [RFC4055]. By conforming to the 213 CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects 214 are less likely to be rejected as non-conformant with the CMS 215 standards. No change is made to the cryptographic status of the CMS 216 objects produced. This change reflects the behaviour of deployed 217 interoperating code. No other changes have been made to the 218 specification as described in [RFC6485]. 220 9. Acknowledgments 222 The author acknowledges the re-use in this draft of material 223 originally contained in working drafts the RPKI Certificate Policy 224 and Resource Certificate profile documents. The co-authors of these 225 two documents, namely Stephen Kent, Derrick Kong, Karen Seo, Ronald 226 Watro, George Michaelson and Robert Loomans, are acknowledged, with 227 thanks. The constraint on key size noted in this profile is the 228 outcome of comments from Stephen Kent and review comments from David 229 Cooper. Sean Turner has provided additional review input to this 230 document. 232 Andrew Chi and David Mandelberg discovered the issue addressed in 233 this update to [RFC6485], and the changes in this updated 234 specification reflect the outcome of a discussion between Rob Austein 235 and Matt Lepinski on the SIDR Working group mailing list. George 236 Michaelson edited the update to this document. 238 10. References 240 10.1. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 246 Request Syntax Specification Version 1.7", RFC 2986, 247 November 2000. 249 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 250 Algorithms and Identifiers for RSA Cryptography for use in 251 the Internet X.509 Public Key Infrastructure Certificate 252 and Certificate Revocation List (CRL) Profile", RFC 4055, 253 June 2005. 255 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 256 Certificate Request Message Format (CRMF)", RFC 4211, 257 September 2005. 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 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 265 RFC 5652, September 2009. 267 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 268 Message Syntax", RFC 5754, January 2010. 270 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 271 Secure Internet Routing", RFC 6480, February 2012. 273 [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 274 Policy (CP) for the Resource Public Key Infrastructure 275 (RPKI)", BCP 173, RFC 6484, February 2012. 277 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 278 X.509 PKIX Resource Certificates", RFC 6487, 279 February 2012. 281 [SHS] National Institute of Standards and Technology (NIST), 282 "FIPS Publication 180-3: Secure Hash Standard", FIPS 283 Publication 180-3, October 2008. 285 10.2. Informative References 287 [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for 288 Use in the Resource Public Key Infrastructure (RPKI)", 289 RFC 6485, February 2012. 291 Authors' Addresses 293 Geoff Huston 294 APNIC 296 Email: gih@apnic.net 298 George Michaelson (editor) 299 APNIC 301 Email: ggm@apnic.net