idnits 2.17.1 draft-ietf-sidr-rpki-algs-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 9, 2010) is 4888 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 draft: draft-ietf-sidr-arch (ref. 'ID.ietf-sidr-arch') == Outdated reference: A later version (-04) exists of draft-ietf-sidr-signed-object-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR G. Huston 3 Internet-Draft APNIC 4 Intended status: Standards Track November 9, 2010 5 Expires: May 13, 2011 7 A Profile for Algorithms and Key Sizes for use in the Resource Public 8 Key Infrastructure 9 draft-ietf-sidr-rpki-algs-04.txt 11 Abstract 13 This document specifies the algorithms, algorithms' parameters, 14 asymmetric key formats, asymmetric key size and signature format for 15 the Resource Public Key Infrastructure subscribers that generate 16 digital signatures on certificates, Certificate Revocation Lists, and 17 signed objects as well as for the Relying Parties (RPs) that verify 18 these digital signatures. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 13, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 This document specifies: 56 * the digital signature algorithm and parameters; 57 * the hash algorithm and parameters; 58 * the public and private key formats; and, 59 * the signature format 60 used by Resource Public Key Infrastructure (RPKI) subscribers when 61 they apply digital signatures to certificates, Certificate Revocation 62 Lists (CRLs), and signed objects (e.g., Route Origin Authorizations 63 (ROAs) and manifests). Relying Parties (RPs) also use this document 64 when verify RPKI subscribers' digital signatures [ID.ietf-sidr-arch]. 66 This document is referenced by other RPKI profiles and 67 specifications, including the RPKI Certificate Policy (CP) 68 [ID.ietf-sidr-cp], the RPKI Certificate Profile 69 [ID.ietf-sidr-res-certs], the SIDR architecture [ID.ietf-sidr-arch], 70 and the signed object template for the RPKI 71 [ID.ietf-sidr-signed-object]. Familiarity with these documents is 72 assumed. 74 1.1. Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC2119. 80 2. Algorithms 82 Two cryptographic algorithms are used in the RPKI: 84 * The signature algorithm used in certificates, CRLs, and signed 85 objects is RSA Public-Key Cryptography Standards (PKCS) #1 86 Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from 87 Section 5 of [RFC4055]. 89 * The hashing algorithm used in certificates, CRLs, and signed 90 objects is SHA-256 [SHS]. Hash algorithms are not identified 91 by themselves in certificates and CRLs instead they are 92 combined with the digital signature algorithm (see below). 93 When used in the Cryptographic Message Syntax (CMS) SignedData, 94 the hash algorithm (in this case, the hash algorithm is 95 sometimes called a message digest algorithm) is identified by 96 itself. For CMS SignedData, the object identifier and 97 parameters for SHA-256 in [RFC5754] MUST be used when 98 populating the digestAlgorithms and digestAlgorithm fields. 100 NOTE: The exception to the above hashing algorithm is the use 101 of SHA-1 [SHS] when CAs generate authority and subject key 102 identifiers [ID.ietf-sidr-res-certs]. 104 When used to generate and verify digital signatures the hash and 105 digital signature algorithms are referred together, i.e., "RSA PKCS#1 106 v1.5 with SHA-256" or more simply "RSA with SHA-256". The Object 107 Identifier (OID) sha256withRSAEncryption from [RFC4055] MUST be used. 109 Locations for this OID are as follows: 111 In the certificate, the OID appears in the signature and 112 signatureAlgorithm fields [RFC4055];- In the CRL, the OID appears 113 in the signatureAlgorithm field [RFC4055]; and,- In CMS 114 SignedData, the OID appears in each SignerInfo signatureAlgoithm 115 field [RFC3370] using the OID from above. 117 3. Asymmetric Key Pair Formats 119 The RSA key pairs used to compute the signatures MUST have a 2048-bit 120 modulus and a public exponent (e) of 65,537. 122 3.1. Public Key Format 124 The Subject's public key is included in subjectPublicKeyInfo 125 [RFC5280]. It has two sub-fields: algorithm and subjectPublicKey. 126 The values for the structures and their sub-structures follow: 128 algorithm (which is an AlgorithmIdentifier type): 129 The object identifier for RSA PKCS#1 v1.5 with SHA-256 MUST be 130 used in the algorithm field, as specified in Section 5 of 131 [RFC4055]. The value for the associated parameters from that 132 clause MUST also be used for the parameters field. 134 subjectPublicKey: 135 RSAPublicKey MUST be used to encode the certificate's 136 subjectPublicKey field, as specified in [RFC4055]. 138 3.2. Private Key Format 140 Local Policy determines private key format. 142 4. Signature Format 144 The structure for the certificate's signature field is as specified 145 in Section 1.2 of [RFC4055]. The structure for the Cryptographic 146 Message Syntax (CMS) SignedData's signature field is as specified in 147 [RFC3370]. 149 5. Additional Requirements 151 It is anticipated that the RPKI will require the adoption of updated 152 key sizes and a different set of signature and hash algorithms over 153 time, in order to maintain an acceptable level of cryptographic 154 security to protect the integrity of signed products in the RPKI. 155 This profile should be updated to specify such future requirements, 156 as and when appropriate. 158 CAs and RPs SHOULD be capable of supporting a transition to allow for 159 the phased introduction of additional encryption algorithms and key 160 specifications, and also accommodate the orderly deprecation of 161 previously specified algorithms and keys. Accordingly, CAs and RPs 162 SHOULD be capable of supporting multiple RPKI algorithm and key 163 profiles simultaneously within the scope of such anticipated 164 transitions. The recommended procedures to implement such a 165 transition of key sizes and algorithms is not specified in this 166 document. 168 6. Security Considerations 170 The Security Considerations of [RFC4055], [RFC5280], and 171 [ID.ietf-sidr-res-certs] a apply to certificate and CRLs. The 172 Security Considerations of [RFC5754] apply to signed objects. No new 173 security are introduced as a result of this specification. 175 7. IANA Considerations 177 [There are no IANA considerations in this document.] 179 8. Acknowledgments 181 The author acknowledges the re-use in this draft of material 182 originally contained in working drafts the RPKI Certificate Policy 183 and Resource Certificate profile documents. The co-authors of these 184 two documents, namely Stephen Kent, Derrick Kong, Karen Seo, Ronald 185 Watro, George Michaelson and Robert Loomans, are acknowledged, with 186 thanks. The constraint on key size noted in this profile is the 187 outcome of comments from Stephen Kent and review comments from David 188 Cooper. Sean Turner has provided additional review input to this 189 document. 191 9. Normative References 193 [ID.ietf-sidr-arch] 194 Lepinski, M. and S. Kent, "An Infrastructure to Support 195 Secure Internet Routing", draft-ietf-sidr-arch (work in 196 progress), September 2010. 198 [ID.ietf-sidr-cp] 199 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 200 Policy (CP) for the Resource PKI (RPKI)", 201 draft-ietf-sidr-cp (work in progress), September 2010. 203 [ID.ietf-sidr-res-certs] 204 Husotn, G., Michaelson, G., and R. Loomans, "A Profile for 205 X.509 PKIX Resource Certificates", 206 draft-ietf-sidr-res-certs (work in progress), May 2008. 208 [ID.ietf-sidr-signed-object] 209 Lepinski, M., Chi, A., and S. Kent, "Signed Object 210 Template for the Resource Public Key Infrastructure", 211 draft-ietf-sidr-signed-object-01.txt (work in progress), 212 October 2010. 214 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 215 Algorithms", RFC 3370, August 2002. 217 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 218 Algorithms and Identifiers for RSA Cryptography for use in 219 the Internet X.509 Public Key Infrastructure Certificate 220 and Certificate Revocation List (CRL) Profile", RFC 4055, 221 June 2005. 223 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 224 Housley, R., and W. Polk, "Internet X.509 Public Key 225 Infrastructure Certificate and Certificate Revocation List 226 (CRL) Profile", RFC 5280, May 2008. 228 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 229 Message Syntax", RFC 5754, January 2010. 231 [SHS] National Institute of Standards and Technology (NIST), 232 "FIPS Publication 180-3: Secure Hash Standard", FIPS 233 Publication 180-3, October 2008. 235 Author's Address 237 Geoff Huston 238 APNIC 240 Email: gih@apnic.net