idnits 2.17.1 draft-turner-ct-keypackage-receipt-n-error-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 (December 2, 2013) is 3795 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 5753 ** Downref: Normative reference to an Informational RFC: RFC 6090 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sean Turner 3 Internet Draft IECA 4 Intended Status: Standards Track December 2, 2013 5 Expires: June 5, 2014 7 Algorithms for Cryptographic Message Syntax (CMS) 8 Key Package Receipt and Error Content Types 9 draft-turner-ct-keypackage-receipt-n-error-algs-04.txt 11 Abstract 13 This document describes the conventions for using several 14 cryptographic algorithms with the Cryptographic Message Syntax (CMS) 15 key package receipt and error content types. Specifically, it 16 includes conventions necessary to implement SignedData, 17 EnvelopedData, EncryptedData, and AuthEnvelopedData. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 This document describes the conventions for using several 52 cryptographic algorithms with the Cryptographic Message Syntax (CMS) 53 key package receipt and error content types [ID.housley-keypackage- 54 receipt-n-error]. Specifically, it includes conventions necessary to 55 implement SignedData [RFC5652], EnvelopedData [RFC5652], 56 EncryptedData [RFC5652], and AuthEnvelopedData [RFC5083]. 58 This document does not define any new algorithms; instead, it refers 59 to previously defined algorithms. In fact, the algorithm 60 requirements in this document are the same as those in [RFC5959], 61 [RFC6033], [RFC6160], [RFC6161], and [RFC6162] with the following 62 exceptions: the content-encryption algorithm is AES in CBC mode as 63 opposed to AES Key Wrap with Message Length Indicator (MLI) and the 64 key-wrap algorithm is AES Key Wrap as opposed to AES Key Wrap with 65 MLI. The rationale for the difference is that the receipt and error 66 content types are not keys therefore AES Key Wrap with MLI is not 67 appropriate for the content-encryption algorithm and if an 68 implementation is not using AES Key Wrap with MLI as the content- 69 encryption algorithm then there's no need to keep the key-wrap 70 algorithm the same as the content encryption algorithm. 72 NOTE: [ID.housley-keypackage-receipt-n-error] only requires that the 73 key package receipt be signed. 75 1.1 Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 79 "OPTIONAL" in this document are to be interpreted as described in 80 [RFC2119]. 82 2. SignedData 84 If an implementation supports SignedData, then it MUST support the 85 signature scheme RSA [RFC3370] and SHOULD support the signature 86 schemes RSA Probabilistic Signature Scheme (RSASSA-PSS) [RFC4056] and 87 Digital Signature Algorithm (DSA) [RFC3370]. Additionally, 88 implementations MUST support the hash function SHA-256 [RFC5754] in 89 concert with these signature schemes, and they SHOULD support the 90 hash function SHA-1 [RFC3370]. Implementations can also choose the 91 to support Elliptic Curve Digital Signature Algorithm (ECDSA) 92 [RFC5753] and [RFC6090]. 94 3. EnvelopedData 96 If an implementation supports EnvelopedData, then it MUST implement 97 key transport, and it MAY implement key agreement. 99 When key transport is used, RSA encryption [RFC3370] MUST be 100 supported, and RSA Encryption Scheme - Optimal Asymmetric Encryption 101 Padding (RSAES-OAEP) [RFC3560] SHOULD be supported. 103 When key agreement is used, Diffie-Hellman (DH) ephemeral-static 104 [RFC3370] MUST be supported. When key agreement is used, Elliptic 105 Curve Diffie-Hellman (ECDH) [RFC5753][RFC6090] MAY be supported. 107 Regardless of the key management technique choice, implementations 108 MUST support AES-128 in CBC mode [AES] as the content-encryption 109 algorithm. Implementations SHOULD support AES-256 in CBC mode [AES] 110 as the content-encryption algorithm. 112 When key agreement is used, the same length for the underlying block 113 algorithm MUST be used. If the content-encryption algorithm is AES- 114 128 in CBC mode, then the key-wrap algorithm MUST be AES-128 Key Wrap 115 [RFC3394]. If the content-encryption algorithm is AES-256 in CBC 116 mode, then the key-wrap algorithm MUST be AES-256 Key Wrap [RFC3394]. 118 4. EncryptedData 120 If an implementation supports EncryptedData, then it MUST implement 121 AES-128 in CBC mode [AES] and SHOULD implement AES-256 in CBC mode 122 [AES]. 124 NOTE: EncryptedData requires that keys be managed by other means; 125 therefore, the only algorithm specified is the content-encryption 126 algorithm. 128 5. AuthEnvelopedData 130 If an implementation supports AuthEnvelopedData, then it MUST 131 implement the EnvelopedData recommendations except for the content- 132 encryption algorithm, which, in this case, MUST be AES-GCM [RFC5084]; 133 the 128-bit version MUST be implemented, and the 256-bit version 134 SHOULD be implemented. Implementations MAY also support AES-CCM 135 [RFC5084]. 137 6. Public Key Sizes 139 The easiest way to implement SignedData, EnvelopedData, and 140 AuthEnvelopedData is with public key certificates [RFC5280]. If an 141 implementation supports RSA, RSASSA-PSS, DSA, RSAES-OAEP, or Diffie- 142 Hellman, then it MUST support key lengths from 1024-bit to 2048-bit, 143 inclusive. If an implementation supports ECDSA or ECDH, then it MUST 144 support keys on the P-256 curve [RFC6090]. 146 7. IANA Considerations 148 None. 150 8. Security Considerations 152 The security considerations from [RFC3370], [RFC3394], [RFC3560], 153 [RFC4056], [RFC5084], [RFC5652], [RFC5753], and [RFC5754] apply. 155 [SP800-57] provides comparable bits of security for some algorithms 156 and key sizes. [SP800-57] also provides time frames during which 157 certain numbers of bits of security are appropriate, and some 158 environments may find these time frames useful. 160 9. Acknowledgements 162 I'd like to thank Russ Housley for his early feedback on this 163 document. 165 10. References 167 10.1. Normative References 169 [AES] National Institute of Standards and Technology, FIPS Pub 170 197: Advanced Encryption Standard (AES), 26 November 2001. 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 176 Algorithms", RFC 3370, August 2002. 178 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 179 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 181 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 182 Algorithm in Cryptographic Message Syntax (CMS)", 183 RFC 3560, July 2003. 185 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 186 Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. 188 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 189 Authenticated-Enveloped-Data Content Type", RFC 5083, 190 November 2007. 192 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 193 Encryption in the Cryptographic Message Syntax (CMS)", 194 RFC 5084, November 2007. 196 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 197 Housley, R., and W. Polk, "Internet X.509 Public Key 198 Infrastructure Certificate and Certificate Revocation List 199 (CRL) Profile", RFC 5280, May 2008. 201 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 202 RFC 5652, September 2009. 204 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 205 Cryptography (ECC) Algorithms in Cryptographic Message 206 Syntax (CMS)", RFC 5753, January 2010. 208 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 209 Message Syntax", RFC 5754, January 2010. 211 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 212 Curve Cryptography Algorithms", RFC 6090, February 2011. 214 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 215 Message Syntax (CMS) Key Package Receipt and Error Content 216 Types", draft-housley-ct-keypackage-receipt-n-error, May 217 2013. 219 10.2. Informative References 221 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 222 Type", RFC 5959, August 2010. 224 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 225 (CMS) Encrypted Key Package Content Type", RFC 6033, 226 December 2010. 228 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 229 (CMS) Protection of Symmetric Key Package Content Types", 230 RFC 6160, April 2011. 232 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 233 Message Syntax (CMS) Encrypted Key Package Content Type", 234 RFC 6161, April 2011. 236 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 237 Message Syntax (CMS) Asymmetric Key Package Content Type", 238 RFC 6162, April 2011. 240 [SP800-57] National Institute of Standards and Technology (NIST), 241 Special Publication 800-57: Recommendation for Key 242 Management - Part 1 (Revised), March 2007. 244 Author's Address 246 Sean Turner 247 IECA, Inc. 248 3057 Nutley Street, Suite 106 249 Fairfax, VA 22031 250 USA 252 Email: turners@ieca.com