idnits 2.17.1 draft-jones-cose-rsa-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 (December 31, 2016) is 2666 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) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COSE Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track December 31, 2016 5 Expires: July 4, 2017 7 Using RSA Algorithms with COSE Messages 8 draft-jones-cose-rsa-01 10 Abstract 12 The CBOR Object Signing and Encryption (COSE) specification defines 13 cryptographic message encodings using Concise Binary Object 14 Representation (CBOR). This specification defines algorithm 15 encodings and representations enabling RSA algorithms to be used for 16 COSE messages. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 4, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Notation and Conventions . . . . . . . . . . 2 54 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 2 55 2.1. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.1.1. Security Considerations . . . . . . . . . . . . . . . 3 57 3. Recipient Algorithm Classes . . . . . . . . . . . . . . . . . 4 58 3.1. Key Encryption . . . . . . . . . . . . . . . . . . . . . 4 59 3.1.1. RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1.1. Security Considerations for RSAES-OAEP . . . . . 5 61 4. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. RSA Keys . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. COSE Algorithms Registry . . . . . . . . . . . . . . . . 7 65 5.2. COSE Key Types Registry . . . . . . . . . . . . . . . . . 7 66 5.3. COSE Key Type Parameters Registry . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 72 Appendix B. Document History . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The CBOR Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] 78 specification defines cryptographic message encodings using Concise 79 Binary Object Representation (CBOR) [RFC7049]. This specification 80 defines algorithm encodings and representations enabling RSA 81 algorithms to be used for COSE messages. 83 1.1. Requirements Notation and Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in RFC 88 2119 [RFC2119]. 90 2. Signature Algorithms 92 2.1. RSASSA-PSS 94 The RSASSA-PSS signature algorithm is defined in [RFC3447]. 96 The RSASSA-PSS signature algorithm is parameterized with a hash 97 function (h), a mask generation function (mgf) and a salt length 98 (sLen). For this specification, the mask generation function is 99 fixed to be MGF1 as defined in [RFC3447]. It has been recommended 100 that the same hash function be used for hashing the data as well as 101 in the mask generation function. This specification follows this 102 recommendation. The salt length is the same length as the hash 103 function output. 105 Implementations need to check that the key type is 'RSA' when 106 creating or verifying a signature. 108 The algorithms defined in this document can be found in Table 1. 110 +-------+-------+---------+-------------+-----------------------+ 111 | Name | Value | Hash | Salt Length | Description | 112 +-------+-------+---------+-------------+-----------------------+ 113 | PS256 | -37 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 | 114 | PS384 | -38 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 | 115 | PS512 | -39 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 | 116 +-------+-------+---------+-------------+-----------------------+ 118 Table 1: RSASSA-PSS Algorithm Values 120 2.1.1. Security Considerations 122 In addition to needing to worry about keys that are too small to 123 provide the required security, there are issues with keys that are 124 too large. Denial of service attacks have been mounted with overly 125 large keys. This has the potential to consume resources with 126 potentially bad keys. There are two reasonable ways to address this 127 attack. First, a key should not be used for a cryptographic 128 operation until it has been matched back to an authorized user. This 129 approach means that no cryptography would be done except for 130 authorized users. Second, applications can impose maximum as well as 131 minimum length requirements on keys. This limits the resources 132 consumed even if the matching is not performed until the cryptography 133 has been done. 135 There is a theoretical hash substitution attack that can be mounted 136 against RSASSA-PSS. However, the requirement that the same hash 137 function be used consistently for all operations is an effective 138 mitigation against it. Unlike ECDSA, hash functions are not 139 truncated so that the full hash value is always signed. The internal 140 padding structure of RSASSA-PSS means that one needs to have multiple 141 collisions between the two hash functions to be successful in 142 producing a forgery based on changing the hash function. This is 143 highly unlikely. 145 3. Recipient Algorithm Classes 147 3.1. Key Encryption 149 Key Encryption mode is also called key transport mode in some 150 standards. Key Encryption mode differs from Key Wrap mode in that it 151 uses an asymmetric encryption algorithm rather than a symmetric 152 encryption algorithm to protect the key. This document defines one 153 Key Encryption mode algorithm. 155 When using a key encryption algorithm, the COSE_encrypt structure for 156 the recipient is organized as follows: 158 o The 'protected' field MUST be absent. 160 o The plain text to be encrypted is the key from next layer down 161 (usually the content layer). 163 o At a minimum, the 'unprotected' field MUST contain the 'alg' 164 parameter and SHOULD contain a parameter identifying the 165 asymmetric key. 167 3.1.1. RSAES-OAEP 169 RSAES-OAEP is an asymmetric key encryption algorithm. The definition 170 of RSAEA-OAEP can be find in Section 7.1 of [RFC3447]. The algorithm 171 is parameterized using a masking generation function (mgf), a hash 172 function (h) and encoding parameters (P). For the algorithm 173 identifiers defined in this section: 175 o mgf is always set to MFG1 from [RFC3447] and uses the same hash 176 function as h. 178 o P is always set to the empty octet string. 180 Table 2 summarizes the rest of the values. 182 +----------------------------+-------+---------+--------------------+ 183 | Name | Value | Hash | Description | 184 +----------------------------+-------+---------+--------------------+ 185 | RSAES-OAEP w/ default | -40 | SHA-1 | RSAES OAEP w/ | 186 | parameters | | | SHA-1 | 187 | RSAES-OAEP w/ SHA-256 | -41 | SHA-256 | RSAES OAEP w/ | 188 | | | | SHA-256 | 189 | RSAES-OAEP w/ SHA-512 | -42 | SHA-512 | RSAES OAEP w/ | 190 | | | | SHA-512 | 191 +----------------------------+-------+---------+--------------------+ 193 Table 2: RSAES-OAEP Algorithm Values 195 The key type MUST be 'RSA'. 197 3.1.1.1. Security Considerations for RSAES-OAEP 199 A key size of 2048 bits or larger MUST be used with these algorithms. 200 This key size corresponds roughly to the same strength as provided by 201 a 128-bit symmetric encryption algorithm. 203 It is highly recommended that checks on the key length be done before 204 starting a decryption operation. One potential denial of service 205 operation is to provide encrypted objects using either abnormally 206 long or oddly sized RSA modulus values. Implementations SHOULD be 207 able to encrypt and decrypt with modulus between 2048 and 16K bits in 208 length. Applications can impose additional restrictions on the 209 length of the modulus. 211 A version of RSAES-OAEP using the default parameters specified in 212 Appendix A.2.1 of RFC 3447 is included because this is the most 213 widely implemented set of OAEP parameter choices. (Those default 214 parameters are the SHA-1 hash function and the MGF1 with SHA-1 mask 215 generation function.) While SHA-1 is deprecated as a general-purpose 216 hash function, no known practical attacks are enabled by its use in 217 this context. 219 4. Keys 221 Key types are identified by the 'kty' member of the COSE_Key object. 222 This specification defines one value for this member. 224 +------+-------+-------------+ 225 | Name | Value | Description | 226 +------+-------+-------------+ 227 | RSA | 3 | RSA Key | 228 +------+-------+-------------+ 230 Table 3: Key Type Values 232 4.1. RSA Keys 234 This document defines a key structure for both the public and private 235 parts of RSA keys. Together, an RSA public key and an RSA private 236 key form an RSA key pair. 238 The document also provides support for the so-called "multi-prime" 239 RSA keys, in which the modulus may have more than two prime factors. 240 The benefit of multi-prime RSA is lower computational cost for the 241 decryption and signature primitives. For a discussion on how multi- 242 prime affects the security of RSA crypto-systems, the reader is 243 referred to [MultiPrimeRSA]. 245 This document follows the naming convention of [RFC3447] for the 246 naming of the fields of an RSA public or private key. Table 4 247 provides a summary of the label values and the types associated with 248 each of those labels. The requirements for fields for RSA keys are 249 as follows: 251 o For all keys, 'kty' MUST be present and MUST have a value of 3. 253 o For public keys, the fields 'n' and 'e' MUST be present. All 254 other fields defined in Table 4 MUST be absent. 256 o For private keys with two primes, the fields 'other', 'r_i', 'd_i' 257 and 't_i' MUST be absent; all other fields MUST be present. 259 o For private keys with more than two primes, all fields MUST be 260 present. For the third to nth primes, each of the primes is 261 represented as a map containing the fields 'r_i', 'd_i' and 't_i'. 262 The field 'other' is an array of those maps. 264 o All numeric key parameters are encoded in an unsigned big-endian 265 representation as an octet sequence using the CBOR byte string 266 type (major type 2). The octet sequence MUST utilize the minimum 267 number of octets needed to represent the value. For instance, the 268 value 32,768 is represented as the CBOR byte sequence 0b010_00010 269 (major type 2, additional information 2 for the length), 0x80 270 0x00. 272 +-------+----------+-------+-------+--------------------------------+ 273 | Name | Key Type | Value | Type | Description | 274 +-------+----------+-------+-------+--------------------------------+ 275 | n | 3 | -1 | bstr | Modulus Parameter | 276 | e | 3 | -2 | bstr | Exponent Parameter | 277 | d | 3 | -3 | bstr | Private Exponent Parameter | 278 | p | 3 | -4 | bstr | First Prime Factor | 279 | q | 3 | -5 | bstr | Second Prime Factor | 280 | dP | 3 | -6 | bstr | First Factor CRT Exponent | 281 | dQ | 3 | -7 | bstr | Second Factor CRT Exponent | 282 | qInv | 3 | -8 | bstr | First CRT Coefficient | 283 | other | 3 | -9 | array | Other Primes Info | 284 | r_i | 3 | -10 | bstr | i-th factor, Prime Factor | 285 | d_i | 3 | -11 | bstr | i-th factor, Factor CRT | 286 | | | | | Exponent | 287 | t_i | 3 | -12 | bstr | i-th factor, Factor CRT | 288 | | | | | Coefficient | 289 +-------+----------+-------+-------+--------------------------------+ 291 Table 4: RSA Key Parameters 293 5. IANA Considerations 295 5.1. COSE Algorithms Registry 297 This section registers values in the IANA "COSE Algorithms" registry. 299 The values in Table 1 and Table 2 are to be added to the registry. 301 5.2. COSE Key Types Registry 303 This section registers values in the IANA "COSE Key Types" registry. 305 The values in Table 3 are to be added to the registry. 307 5.3. COSE Key Type Parameters Registry 309 This section registers values in the IANA "COSE Key Type Parameters" 310 registry. 312 The values in Table 4 are to be added to the registry. 314 6. Security Considerations 316 See the per-algorithm security considerations described in 317 Section 2.1.1 and Section 3.1.1.1. 319 7. References 321 7.1. Normative References 323 [I-D.ietf-cose-msg] 324 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 325 draft-ietf-cose-msg-24 (work in progress), November 2016. 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, 329 DOI 10.17487/RFC2119, March 1997, 330 . 332 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 333 Standards (PKCS) #1: RSA Cryptography Specifications 334 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 335 2003, . 337 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 338 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 339 October 2013, . 341 7.2. Informative References 343 [MultiPrimeRSA] 344 Hinek, M. and D. Cheriton, "On the Security of Multi-prime 345 RSA", June 2006. 347 Appendix A. Acknowledgements 349 This specification incorporates text from draft-ietf-cose-msg-05 by 350 Jim Schaad. 352 Appendix B. Document History 354 [[ to be removed by the RFC Editor before publication as an RFC ]] 356 -01 358 o Completed the sets of IANA registration requests. 360 o Revised the algorithm assignments based on those in draft-ietf- 361 cose-msg-24. 363 -00 365 o This specification addresses COSE issue #21: Restore RSA-PSS and 366 the "RSA" key type. The initial version of this specification 367 incorporates text from draft-ietf-cose-msg-05 -- the last COSE 368 message specification version before the RSA algorithms were 369 removed. 371 Author's Address 373 Michael B. Jones 374 Microsoft 376 Email: mbj@microsoft.com 377 URI: http://self-issued.info/