idnits 2.17.00 (12 Aug 2021) /tmp/idnits59843/draft-turner-ct-keypackage-receipt-n-error-algs-00.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 (April 18, 2013) is 3319 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 == Outdated reference: draft-housley-ct-keypackage-receipt-n-error has been published as RFC 7191 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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 April 18, 2013 5 Expires: October 20, 2013 7 Algorithms for Cryptographic Message Syntax (CMS) 8 Key Package Receipt and Error Content Types 9 draft-turner-ct-keypackage-receipt-n-error-algs-00.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 [RFC6083]. 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 61 [RFC5959][RFC6162], [RFC6033][RFC6161], and [RFC6160] with the 62 following exceptions: the content-encryption algorithm is AES in CBC 63 mode as opposed to AES Key Wrap with MLI and the key-wrap algorithm 64 is AES Key Wrap as opposed to AES Key Wrap with Message Length 65 Indicator (MLI). The rationale for the difference is that the receipt 66 and error content types are not keys therefore AES Key Wrap with MLI 67 is not appropriate for the content-encryption algorithm and if an 68 implementation isn't 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 he 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]. If an implementation supports 91 SignedData, then it MAY support Elliptic Curve Digital Signature 92 Algorithm (ECDSA) [RFC6090][RFC5753]. 94 3. EnvelopedData 95 If an implementation supports EnvelopedData, then it MUST implement 96 key transport, and it MAY implement key agreement. 98 When key transport is used, RSA encryption [RFC3370] MUST be 99 supported, and RSA Encryption Scheme - Optimal Asymmetric Encryption 100 Padding (RSAES-OAEP) [RFC3560] SHOULD be supported. 102 When key agreement is used, Diffie-Hellman (DH) ephemeral-static 103 [RFC3370] MUST be supported. When key agreement is used, Elliptic 104 Curve Diffie-Hellman (ECDH) [RFC6090][RFC5753] MAY be supported. 106 Regardless of the key management technique choice, implementations 107 MUST support AES-128 in CBC mode [AES] as the content-encryption 108 algorithm. Implementations SHOULD support AES-256 in CBC mode [AES] 109 as the content-encryption algorithm. 111 When key agreement is used, the same key-wrap algorithm MUST be used 112 for both key and content encryption. If the content-encryption 113 algorithm is AES-128 in CBC mode, then the key-wrap algorithm MUST be 114 AES-128 Key Wrap with Padding [RFC3394]. If the content-encryption 115 algorithm is AES-256 in CBC mode, then the key-wrap algorithm MUST be 116 AES-256 Key Wrap [RFC3394]. 118 3. 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 4. 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 5. 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 P-256 [RFC6090]. 146 6. IANA Considerations 148 None. 150 7. Security Considerations 152 The security considerations from [RFC3370], [RFC3394], [RFC3560], 153 [RFC4056], [RFC5083], [RFC5084], [RFC5652], [RFC5753], and [RFC5754] 154 apply. 156 Unfortunately, there is no AES-GCM or AES-CCM mode that provides the 157 same properties. If an AES-GCM and AES-CCM mode that provides the 158 same properties is defined, then this document will be updated to 159 adopt that algorithm. 161 [SP800-57] provides comparable bits of security for some algorithms 162 and key sizes. [SP800-57] also provides time frames during which 163 certain numbers of bits of security are appropriate, and some 164 environments may find these time frames useful. 166 8. Acknowledgements 168 I'd like to that Russ Housley for his early feedback on this 169 document. 171 9. References 173 9.1. Normative References 175 [AES] National Institute of Standards and Technology, FIPS Pub 176 197: Advanced Encryption Standard (AES), 26 November 2001. 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 182 Algorithms", RFC 3370, August 2002. 184 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 185 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 187 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 188 Algorithm in Cryptographic Message Syntax (CMS)", 189 RFC 3560, July 2003. 191 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 192 Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. 194 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 195 Authenticated-Enveloped-Data Content Type", RFC 5083, 196 November 2007. 198 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 199 Encryption in the Cryptographic Message Syntax (CMS)", 200 RFC 5084, November 2007. 202 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 203 Housley, R., and W. Polk, "Internet X.509 Public Key 204 Infrastructure Certificate and Certificate Revocation List 205 (CRL) Profile", RFC 5280, May 2008. 207 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 208 RFC 5652, September 2009. 210 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 211 Cryptography (ECC) Algorithms in Cryptographic Message 212 Syntax (CMS)", RFC 5753, January 2010. 214 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 215 Message Syntax", RFC 5754, January 2010. 217 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 218 Transport Layer Security (DTLS) for Stream Control 219 Transmission Protocol (SCTP)", RFC 6083, January 2011. 221 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 222 Curve Cryptography Algorithms", RFC 6090, February 2011. 224 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 225 Message Syntax (CMS) Key Package Receipt and Error Content 226 Types", draft-housley-ct-keypackage-receipt-n-error, April 227 2013. 229 9.2. Informative References 231 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 232 Type", RFC 5959, August 2010. 234 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 235 (CMS) Encrypted Key Package Content Type", RFC 6033, 236 December 2010. 238 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 239 (CMS) Protection of Symmetric Key Package Content Types", 240 RFC 6160, April 2011. 242 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 243 Message Syntax (CMS) Encrypted Key Package Content Type", 244 RFC 6161, April 2011. 246 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 247 Message Syntax (CMS) Asymmetric Key Package Content Type", 248 RFC 6162, April 2011. 250 [SP800-57] National Institute of Standards and Technology (NIST), 251 Special Publication 800-57: Recommendation for Key 252 Management - Part 1 (Revised), March 2007. 254 Author's Address 256 Sean Turner 257 IECA, Inc. 258 3057 Nutley Street, Suite 106 259 Fairfax, VA 22031 260 USA 262 Email: turners@ieca.com