idnits 2.17.1 draft-turner-asymmetrickeyformat-algs-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 : ---------------------------------------------------------------------------- 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1, 2010) is 5197 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'P12' ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) == Outdated reference: A later version (-05) exists of draft-turner-asymmetrickeyformat-03 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sean Turner, IECA 2 Internet Draft February 1, 2010 3 Intended Status: Standard Track 4 Expires: August 1, 2010 6 Algorithms for Asymmetric Key Package Content Type 7 draft-turner-asymmetrickeyformat-algs-01.txt 9 Abstract 11 This document describes the conventions for using several 12 cryptographic algorithms with the EncryptedPrivateKeyInfo structure, 13 as defined in RFC TBD1. It also includes conventions necessary to 14 protect the AsymmetricKeyPackage content type with SignedData, 15 EnvelopedData, EncryptedData, AuthenticatedData, and 16 AuthEnvelopedData. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may contain material 22 from IETF Documents or IETF Contributions published or made publicly 23 available before November 10, 2008. The person(s) controlling the 24 copyright in some of this material may not have granted the IETF 25 Trust the right to allow modifications of such material outside the 26 IETF Standards Process. Without obtaining an adequate license from 27 the person(s) controlling the copyright in such materials, this 28 document may not be modified outside the IETF Standards Process, and 29 derivative works of it may not be created outside the IETF Standards 30 Process, except to format it for publication as an RFC or to 31 translate it into languages other than English. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on August 1, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 1. Introduction 67 This document describes the conventions for using several 68 cryptographic algorithms with the EncryptedPrivateKeyInfo structure 69 [RFCTBD1]. The EncryptedPrivateKeyInfo is used by [P12] to encrypt 70 PrivateKeyInfo [RFCTBD1]. It is similar to EncryptedData [RFC5652] in 71 that it has no recipients, no originators, and no content encryption 72 keys and requires keys be managed by other means. 74 This document also includes conventions necessary to protect the 75 AsymmetricKeyPackage content type [RFCTBD1] with Cryptographic 76 Message Syntax (CMS) protecting content types: SignedData [RFC5652], 77 EnvelopedData [RFC5652], EncryptedData [RFC5652], AuthenticatedData 78 [RFC5652], and AuthEnvelopedData [RFC5083]. Implementations of 79 AsymmetricKeyPackage do not require support for any CMS protecting 80 content type; however, if the AsymmetricKeyPackage is CMS protected 81 it is RECOMMENDED that conventions defined herein be followed. 83 This document does not define any new algorithms instead it refers to 84 previously defined algorithms. 86 1.1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. EncryptedPrivateKeyInfo 94 The de facto standard used to encrypt the PrivateKeyInfo structure, 95 which is subsequently placed in the EncryptedPrivateKeyInfo 96 encryptedData field, is Password Based Encryption (PBE) based on 97 PKCS#5 [RFC2898] and PKCS#12 [P12]. The major difference between PKCS 98 #5 and PKCS #12 is the supported encoding for the password: ASCII for 99 PKCS #5 and Unicode for PKCS #12. [RFC2898] specifies two PBE 100 Schemes (PBES) 1 and 2, the defacto is PBES 1. The notation for the 101 PBES 1 is: PBEWithAnd. The following schemes are 102 defined in PKCS #5: PBEWithMD2AndDES-CBC, PBEWithMD2AndRC2, 103 PBEWithMD5AndDES-CBC, PBEWithMD5AndRC2, PBEWithSHA1AndDES-CBC, 104 PBEWithSHA1AndRC2. The following schemes are defined in PKCS #12: 105 PBEWithSHAAnd3-KeyTripleDES-CBC, PBEWithSHAAnd2-KeyTripleDES-CBC, 106 PBEWithSHAAnd128BitRC2-CBC, PBEWithSHAAnd40BitRC2-CBC, 107 PBEWithSHAAnd128BitRC4, and PBEWithSHAAnd40BitRC4. Implementation 108 defaults vary. 110 The PBES 1 algorithms require salt and iteration count values. The 111 salt length in PKCS #5 is 8 octets while there is no restriction on 112 the length of the salt in PKCS #12, but PKCS #12 recommends the salt 113 be as long as the digest algorithms output (e.g., 20 octets for SHA- 114 1). The iteration count in PKCS #5 is recommended to be at least 115 1000 and PKCS #12 recommends at least 1024. 117 It is RECOMMENDED that implementations support AES-128 Key Wrap with 118 Padding [RFC5649] or AES-256 Key Wrap with Padding [RFC5649]. 120 3. AsymmetricKeyPackage 122 As noted in Asymmetric Key Packages [RFCTBD1], CMS can be used to 123 protect the AsymmetricKeyPackage. The following provides guidance 124 for SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData 125 [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData 126 [RFC5083]. 128 3.1. SignedData 130 If an implementation supports SignedData, then it MUST support the 131 signature scheme RSA [RFC3370] and SHOULD support the signature 132 schemes RSASSA-PSS [RFC4056] and DSA [RFC3370]. Additionally, 133 implementations MUST support in concert with these signature schemes 134 the hash function SHA-256 [RFC5754] and it SHOULD support the hash 135 function SHA-1 [RFC3370]. 137 3.2. EnvelopedData 139 If an implementation supports EnvelopedData, then it MUST implement 140 the key transport and it MAY implement the key agreement mechanism. 142 When key transport is used, RSA encryption [RFC3370] MUST be 143 supported and RSAES-OAEP [RFC3560] SHOULD be supported. 145 When key agreement is used, Diffie-Hellman ephemeral-static [RFC3370] 146 SHOULD be supported. 148 Regardless of the key management technique choice, implementations 149 MUST support AES-128 Key Wrap with Padding [RFC5649]. 150 Implementations SHOULD support AES-256 Key Wrap with Padding 151 [RFC5649]. 153 When key agreement is used, a key wrap algorithm is also specified to 154 wrap the content encryption key. If the content encryption algorithm 155 is AES-128 Key Wrap with Padding, then the key wrap algorithm MUST be 156 AES-128 Key Wrap with Padding [RFC5649]. If the content encryption 157 algorithm is AES-256 Key Wrap with Padding, then the key wrap 158 algorithm MUST be AES-256 Key Wrap with Padding [RFC5649]. 160 3.3. EncryptedData 162 If an implementation supports EncryptedData, then it MUST implement 163 AES-128 Key Wrap with Padding [RFC5649] and MAY implement AES-256 Key 164 Wrap with Padding [RFC5649]. 166 NOTE: EncryptedData requires that keys be managed by other means; 167 therefore, the only algorithm specified is the content encryption 168 algorithm. 170 3.4. AuthenticatedData 172 If an implementation supports AuthenticatedData, then it MUST 173 implement SHA-256 [RFC5754] and SHOULD support SHA-1 [RFC3370] as the 174 message digest algorithm. Additionally, HMAC with SHA-256 [RFC4231] 175 MUST be supported and HMAC with SHA-1 [RFC3370] SHOULD be supported. 177 3.5. AuthEnvelopedData 179 If an implementation supports AuthEnvelopedData, then it MUST 180 implement the EnvelopedData recommendations except for the content 181 encryption algorithm, which in this case MUST be AES-GCM [RFC5084]; 182 the 128-bit version MUST be implemented and the 256-bit version 183 SHOULD be implemented. Implementations MAY also support for AES-CCM 184 [RFC5084]. 186 4. Public Key Sizes 188 The easiest way to implement the key transport requirement for 189 EnvelopedData and AuthenticatedData is with public key certificates 190 [RFC5280]. If an implementation support RSA, RSAES-OAEP, or DH, then 191 it MUST support key lengths from 1024-bit to 2048-bit, inclusive. 193 5. SMIMECapabilities Attribute 195 [RFC5751] defines the SMIMECapabilities attribute as a mechanism for 196 recipients to indicate their supported capabilities including the 197 algorithms they support. The following are values for the 198 SMIMECapabilities attribute for AES Key Wrap with Padding [RFC5649] 199 when used as a content encryption algorithm: 201 AES-128 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 08 202 AES-192 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 1C 203 AES-256 KW with Padding: 30 0d 06 09 60 86 48 01 65 03 04 01 30 205 6. Security Considerations 207 The security considerations from [RFC3370], [RFC3394], [RFC3560], 208 [RFC5652], [RFC4056], [RFC4231], [RFC5083], [RFC5084], [RFC5649], 209 [RFC5754], and [RFCTBD1] apply. 211 The strength of any encryption scheme is only as good as its weakest 212 link, which in the case of a PBES is the password. Passwords need to 213 provide sufficient entropy to ensure they cannot be easily guessed. 214 The U.S. National Institute of Standards and Technology (NIST) 215 Electronic Authentication Guidance [SP800-63] provides some 216 information on password entropy. [SP800-63] indicates that a user 217 chosen 20-character password from a 94-character keyboard with no 218 checks provides 36 bits of entropy. If the 20-character password is 219 randomly chosen, then the amount of entropy is increased to roughly 220 131 bits of entropy. The amount of entropy in the password does not 221 correlate directly to bits of security but in general the more than 222 the better. 224 The choice of content encryption algorithms for this document was 225 based on [RFC5649]: "In the design of some high assurance 226 cryptographic modules, it is desirable to segregate cryptographic 227 keying material from other data. The use of a specific cryptographic 228 mechanism solely for the protection of cryptographic keying material 229 can assist in this goal." Unfortunately, there is no AES-CCM or AES- 230 GCM mode that provides the same properties. If an AES-CCM and AES- 231 GCM mode that provides the same properties is defined, then this 232 document will be updated to adopt that algorithm. 234 [SP800-57] provides comparable bits of security for some algorithms 235 and key sizes. [SP800-57] also provides time frames during which 236 certain numbers of bits of security are appropriate and some 237 environments may find these time frames useful. 239 7. IANA Considerations 241 None. Please remove this section prior to publication as an RFC. 243 8. References 245 8.1. Normative References 247 [P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information 248 Exchange Syntax", June 1999. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 254 Specification Version 2.0", RFC 2898, September 2000. 256 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 257 Algorithms", RFC 3370, August 2002. 259 [RFC3394] Housley, R., and J. Schaad, "Advanced Encryption Standard 260 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 262 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 263 Algorithm in the Cryptographic Message Syntax (CMS)", RFC 264 3560, July 2003. 266 [RFC4056] Schaad, J., "Use of RSASSA-PSS Signature Algorithm in 267 Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. 269 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 270 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 271 4231, December 2005 273 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 274 Authenticated-Enveloped-Data Content Type", RFC 5083, 275 November 2007. 277 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 278 Encryption in the Cryptographic Message Syntax (CMS)", 279 RFC 5084, November 2007. 281 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 282 Housley, R., and W. Polk, "Internet X.509 Public Key 283 Infrastructure Certificate and Certificate Revocation 284 List (CRL) Profile", RFC 5280, May 2008. 286 [RFC5649] Housley, R., and M. Dworkin, "Advanced Encryption 287 Standard (AES) Key Wrap with Padding Algorithm", RFC 288 5649, August 2009. 290 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 291 5652, September 2009. 293 [RFC5751] Turner, S., and B. Ramsdell, "Secure/Multipurpose 294 Internet Mail Extensions (S/MIME) Version 3.2 Message 295 Specification", RFC 5751, January 2010. 297 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 298 Message Syntax", RFC 5754, January 2010. 300 [RFCTBD1] Turners, S., "Asymmetric Key Packages", draft-turner- 301 asymmetrickeyformat-03.txt, work-in-progress. 303 /** 304 RFC Editor: Please replace "RFCTBD1" with "RFC####" where #### is the 305 number of the published RFC. Please do this in both the references 306 and the text. 307 **/ 309 8.2. Informative References 311 [SP800-57] National Institute of Standards and Technology (NIST), 312 Special Publication 800-57: Recommendation for Key 313 Management - Part 1 (Revised), March 2007. 315 [SP800-63] National Institute of Standards and Technology (NIST), 316 Special Publication 800-63: Electronic Authentication 317 Guidance, April 2006. 319 Authors' Addresses 321 Sean Turner 322 IECA, Inc. 323 3057 Nutley Street, Suite 106 324 Fairfax, VA 22031 325 USA 327 EMail: turners@ieca.com