idnits 2.17.00 (12 Aug 2021) /tmp/idnits61696/draft-turner-ct-keypackage-receipt-n-error-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 date (May 9, 2013) is 3298 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) == Unused Reference: 'RFC6083' is defined on line 212, but no explicit reference was found in the text -- 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 (~~), 3 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 May 9, 2013 5 Expires: November 10, 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-01.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]. If an implementation supports 91 SignedData, then it MAY support Elliptic Curve Digital Signature 92 Algorithm (ECDSA) [RFC5753] and [RFC6090]. 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 [RFC3394]. If the content-encryption algorithm is 115 AES-256 in CBC mode, then the key-wrap algorithm MUST be AES-256 Key 116 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 [SP800-57] provides comparable bits of security for some algorithms 157 and key sizes. [SP800-57] also provides time frames during which 158 certain numbers of bits of security are appropriate, and some 159 environments may find these time frames useful. 161 8. Acknowledgements 163 I'd like to thank Russ Housley for his early feedback on this 164 document. 166 9. References 168 9.1. Normative References 170 [AES] National Institute of Standards and Technology, FIPS Pub 171 197: Advanced Encryption Standard (AES), 26 November 2001. 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 177 Algorithms", RFC 3370, August 2002. 179 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 180 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 182 [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport 183 Algorithm in Cryptographic Message Syntax (CMS)", 184 RFC 3560, July 2003. 186 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 187 Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. 189 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 190 Authenticated-Enveloped-Data Content Type", RFC 5083, 191 November 2007. 193 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 194 Encryption in the Cryptographic Message Syntax (CMS)", 195 RFC 5084, November 2007. 197 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 198 Housley, R., and W. Polk, "Internet X.509 Public Key 199 Infrastructure Certificate and Certificate Revocation List 200 (CRL) Profile", RFC 5280, May 2008. 202 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 203 RFC 5652, September 2009. 205 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 206 Cryptography (ECC) Algorithms in Cryptographic Message 207 Syntax (CMS)", RFC 5753, January 2010. 209 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 210 Message Syntax", RFC 5754, January 2010. 212 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 213 Transport Layer Security (DTLS) for Stream Control 214 Transmission Protocol (SCTP)", RFC 6083, January 2011. 216 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 217 Curve Cryptography Algorithms", RFC 6090, February 2011. 219 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 220 Message Syntax (CMS) Key Package Receipt and Error Content 221 Types", draft-housley-ct-keypackage-receipt-n-error, May 222 2013. 224 9.2. Informative References 226 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 227 Type", RFC 5959, August 2010. 229 [RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax 230 (CMS) Encrypted Key Package Content Type", RFC 6033, 231 December 2010. 233 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 234 (CMS) Protection of Symmetric Key Package Content Types", 235 RFC 6160, April 2011. 237 [RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic 238 Message Syntax (CMS) Encrypted Key Package Content Type", 239 RFC 6161, April 2011. 241 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 242 Message Syntax (CMS) Asymmetric Key Package Content Type", 243 RFC 6162, April 2011. 245 [SP800-57] National Institute of Standards and Technology (NIST), 246 Special Publication 800-57: Recommendation for Key 247 Management - Part 1 (Revised), March 2007. 249 Author's Address 251 Sean Turner 252 IECA, Inc. 253 3057 Nutley Street, Suite 106 254 Fairfax, VA 22031 255 USA 257 Email: turners@ieca.com