idnits 2.17.1 draft-jones-cose-rsa-05.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 (June 22, 2017) is 2494 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. 'Boneh99' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Downref: Normative reference to an Informational RFC: RFC 8017 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 June 22, 2017 5 Expires: December 24, 2017 7 Using RSA Algorithms with COSE Messages 8 draft-jones-cose-rsa-05 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. Encodings for the use of RSASSA-PSS signatures, 17 RSAES-OAEP encryption, and RSA keys are specified. 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 This Internet-Draft will expire on December 24, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Notation and Conventions . . . . . . . . . . 2 55 2. RSASSA-PSS Signature Algorithm . . . . . . . . . . . . . . . 2 56 3. RSAES-OAEP Key Encryption Algorithm . . . . . . . . . . . . . 3 57 4. RSA Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. COSE Algorithms Registrations . . . . . . . . . . . . . . 5 60 5.2. COSE Key Type Registrations . . . . . . . . . . . . . . . 6 61 5.3. COSE Key Type Parameters Registrations . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6.1. Key Size Security Considerations . . . . . . . . . . . . 8 64 6.2. RSASSA-PSS Security Considerations . . . . . . . . . . . 9 65 6.3. RSAES-OAEP Security Considerations . . . . . . . . . . . 9 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 7.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 70 Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The CBOR Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] 76 specification defines cryptographic message encodings using Concise 77 Binary Object Representation (CBOR) [RFC7049]. This specification 78 defines algorithm encodings and representations enabling RSA 79 algorithms to be used for COSE messages. 81 1.1. Requirements Notation and Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in RFC 86 2119 [RFC2119]. 88 2. RSASSA-PSS Signature Algorithm 90 The RSASSA-PSS signature algorithm is defined in [RFC8017]. 92 The RSASSA-PSS signature algorithm is parameterized with a hash 93 function (h), a mask generation function (mgf) and a salt length 94 (sLen). For this specification, the mask generation function is 95 fixed to be MGF1 as defined in [RFC8017]. It has been recommended 96 that the same hash function be used for hashing the data as well as 97 in the mask generation function. This specification follows this 98 recommendation. The salt length is the same length as the hash 99 function output. 101 Implementations need to check that the key type is 'RSA' when 102 creating or verifying a signature. 104 The RSASSA-PSS algorithms specified in this document are in the 105 following table. 107 +-------+-------+---------+-------------+-----------------------+ 108 | Name | Value | Hash | Salt Length | Description | 109 +-------+-------+---------+-------------+-----------------------+ 110 | PS256 | -37 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 | 111 | PS384 | -38 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 | 112 | PS512 | -39 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 | 113 +-------+-------+---------+-------------+-----------------------+ 115 Table 1: RSASSA-PSS Algorithm Values 117 3. RSAES-OAEP Key Encryption Algorithm 119 RSAES-OAEP is an asymmetric key encryption algorithm. The definition 120 of RSAEA-OAEP can be found in Section 7.1 of [RFC8017]. The 121 algorithm is parameterized using a masking generation function (mgf), 122 a hash function (h) and encoding parameters (P). For the algorithm 123 identifiers defined in this section: 125 o mgf is always set to MGF1 from [RFC8017] and uses the same hash 126 function as h. 128 o P is always set to the empty octet string. 130 The following table summarizes the rest of the values. 132 +-------------------------------+-------+---------+-----------------+ 133 | Name | Value | Hash | Description | 134 +-------------------------------+-------+---------+-----------------+ 135 | RSAES-OAEP w/ RFC 8017 | -40 | SHA-1 | RSAES-OAEP w/ | 136 | default parameters | | | SHA-1 | 137 | RSAES-OAEP w/ SHA-256 | -41 | SHA-256 | RSAES-OAEP w/ | 138 | | | | SHA-256 | 139 | RSAES-OAEP w/ SHA-512 | -42 | SHA-512 | RSAES-OAEP w/ | 140 | | | | SHA-512 | 141 +-------------------------------+-------+---------+-----------------+ 143 Table 2: RSAES-OAEP Algorithm Values 145 The key type MUST be 'RSA'. 147 4. RSA Keys 149 Key types are identified by the 'kty' member of the COSE_Key object. 150 This specification defines one value for this member in the following 151 table. 153 +------+-------+-------------+ 154 | Name | Value | Description | 155 +------+-------+-------------+ 156 | RSA | 3 | RSA Key | 157 +------+-------+-------------+ 159 Table 3: Key Type Values 161 This document defines a key structure for both the public and private 162 parts of RSA keys. Together, an RSA public key and an RSA private 163 key form an RSA key pair. 165 The document also provides support for the so-called "multi-prime" 166 RSA keys, in which the modulus may have more than two prime factors. 167 The benefit of multi-prime RSA is lower computational cost for the 168 decryption and signature primitives. For a discussion on how multi- 169 prime affects the security of RSA crypto-systems, the reader is 170 referred to [MultiPrimeRSA]. 172 This document follows the naming convention of [RFC8017] for the 173 naming of the fields of an RSA public or private key and the 174 corresponding fields have identical semantics. The requirements for 175 fields for RSA keys are as follows: 177 o For all keys, 'kty' MUST be present and MUST have a value of 3. 179 o For public keys, the fields 'n' and 'e' MUST be present. All 180 other fields defined in the following table below MUST be absent. 182 o For private keys with two primes, the fields 'other', 'r_i', 'd_i' 183 and 't_i' MUST be absent; all other fields MUST be present. 185 o For private keys with more than two primes, all fields MUST be 186 present. For the third to nth primes, each of the primes is 187 represented as a map containing the fields 'r_i', 'd_i' and 't_i'. 188 The field 'other' is an array of those maps. 190 o All numeric key parameters are encoded in an unsigned big-endian 191 representation as an octet sequence using the CBOR byte string 192 type (major type 2). The octet sequence MUST utilize the minimum 193 number of octets needed to represent the value. For instance, the 194 value 32,768 is represented as the CBOR byte sequence 0b010_00010, 195 0x80 0x00 (major type 2, additional information 2 for the length). 197 The following table provides a summary of the label values and the 198 types associated with each of those labels. 200 +-------+-------+-------+-------+-----------------------------------+ 201 | Key | Name | Label | CBOR | Description | 202 | Type | | | Type | | 203 +-------+-------+-------+-------+-----------------------------------+ 204 | 3 | n | -1 | bstr | the RSA modulus n | 205 | 3 | e | -2 | bstr | the RSA public exponent e | 206 | 3 | d | -3 | bstr | the RSA private exponent d | 207 | 3 | p | -4 | bstr | the prime factor p of n | 208 | 3 | q | -5 | bstr | the prime factor q of n | 209 | 3 | dP | -6 | bstr | dP is d mod (p - 1) | 210 | 3 | dQ | -7 | bstr | dQ is d mod (q - 1) | 211 | 3 | qInv | -8 | bstr | qInv is the CRT coefficient | 212 | | | | | q^(-1) mod p | 213 | 3 | other | -9 | array | other prime infos, an array | 214 | 3 | r_i | -10 | bstr | a prime factor r_i of n, where i | 215 | | | | | >= 3 | 216 | 3 | d_i | -11 | bstr | d_i = d mod (r_i - 1) | 217 | 3 | t_i | -12 | bstr | the CRT coefficient t_i = (r_1 * | 218 | | | | | r_2 * ... * r_(i-1))^(-1) mod r_i | 219 +-------+-------+-------+-------+-----------------------------------+ 221 Table 4: RSA Key Parameters 223 5. IANA Considerations 225 5.1. COSE Algorithms Registrations 227 This section registers the following values in the IANA "COSE 228 Algorithms" registry [IANA.COSE]. 230 o Name: PS256 231 o Value: -37 232 o Description: RSASSA-PSS w/ SHA-256 233 o Reference: Section 2 of [[ this specification ]] 234 o Recommended: Yes 236 o Name: PS384 237 o Value: -38 238 o Description: RSASSA-PSS w/ SHA-384 239 o Reference: Section 2 of [[ this specification ]] 240 o Recommended: Yes 241 o Name: PS512 242 o Value: -39 243 o Description: RSASSA-PSS w/ SHA-512 244 o Reference: Section 2 of [[ this specification ]] 245 o Recommended: Yes 247 o Name: RSAES-OAEP w/ RFC 8017 default parameters 248 o Value: -40 249 o Description: RSAES-OAEP w/ SHA-1 250 o Reference: Section 3 of [[ this specification ]] 251 o Recommended: Yes 253 o Name: RSAES-OAEP w/ SHA-256 254 o Value: -41 255 o Description: RSAES-OAEP w/ SHA-256 256 o Reference: Section 3 of [[ this specification ]] 257 o Recommended: Yes 259 o Name: RSAES-OAEP w/ SHA-512 260 o Value: -42 261 o Description: RSAES-OAEP w/ SHA-512 262 o Reference: Section 3 of [[ this specification ]] 263 o Recommended: Yes 265 5.2. COSE Key Type Registrations 267 This section registers the following values in the IANA "COSE Key 268 Type" registry [IANA.COSE]. 270 o Name: RSA 271 o Value: 3 272 o Description: RSA Key 273 o Reference: Section 4 of [[ this specification ]] 275 5.3. COSE Key Type Parameters Registrations 277 This section registers the following values in the IANA "COSE Key 278 Type Parameters" registry [IANA.COSE]. 280 o Key Type: 3 281 o Name: n 282 o Label: -1 283 o CBOR Type: bstr 284 o Description: the RSA modulus n 285 o Reference: Section 4 of [[ this specification ]] 287 o Key Type: 3 288 o Name: e 289 o Label: -2 290 o CBOR Type: bstr 291 o Description: the RSA public exponent e 292 o Reference: Section 4 of [[ this specification ]] 294 o Key Type: 3 295 o Name: d 296 o Label: -3 297 o CBOR Type: bstr 298 o Description: the RSA private exponent d 299 o Reference: Section 4 of [[ this specification ]] 301 o Key Type: 3 302 o Name: p 303 o Label: -4 304 o CBOR Type: bstr 305 o Description: the prime factor p of n 306 o Reference: Section 4 of [[ this specification ]] 308 o Key Type: 3 309 o Name: q 310 o Label: -5 311 o CBOR Type: bstr 312 o Description: the prime factor q of n 313 o Reference: Section 4 of [[ this specification ]] 315 o Key Type: 3 316 o Name: dP 317 o Label: -6 318 o CBOR Type: bstr 319 o Description: dP is d mod (p - 1) 320 o Reference: Section 4 of [[ this specification ]] 322 o Key Type: 3 323 o Name: dQ 324 o Label: -7 325 o CBOR Type: bstr 326 o Description: dQ is d mod (q - 1) 327 o Reference: Section 4 of [[ this specification ]] 329 o Key Type: 3 330 o Name: qInv 331 o Label: -8 332 o CBOR Type: bstr 333 o Description: qInv is the CRT coefficient q^(-1) mod p 334 o Reference: Section 4 of [[ this specification ]] 336 o Key Type: 3 337 o Name: other 338 o Label: -9 339 o CBOR Type: array 340 o Description: other prime infos, an array 341 o Reference: Section 4 of [[ this specification ]] 343 o Key Type: 3 344 o Name: r_i 345 o Label: -10 346 o CBOR Type: bstr 347 o Description: a prime factor r_i of n, where i >= 3 348 o Reference: Section 4 of [[ this specification ]] 350 o Key Type: 3 351 o Name: d_i 352 o Label: -11 353 o CBOR Type: bstr 354 o Description: d_i = d mod (r_i - 1) 355 o Reference: Section 4 of [[ this specification ]] 357 o Key Type: 3 358 o Name: t_i 359 o Label: -12 360 o CBOR Type: bstr 361 o Description: the CRT coefficient t_i = (r_1 * r_2 * ... * 362 r_(i-1))^(-1) mod r_i 363 o Reference: Section 4 of [[ this specification ]] 365 6. Security Considerations 367 6.1. Key Size Security Considerations 369 A key size of 2048 bits or larger MUST be used with these algorithms. 370 This key size corresponds roughly to the same strength as provided by 371 a 128-bit symmetric encryption algorithm. Implementations SHOULD be 372 able to encrypt and decrypt with modulus between 2048 and 16K bits in 373 length. Applications can impose additional restrictions on the 374 length of the modulus. 376 In addition to needing to worry about keys that are too small to 377 provide the required security, there are issues with keys that are 378 too large. Denial of service attacks have been mounted with overly 379 large keys or oddly sized keys. This has the potential to consume 380 resources with these keys. It is highly recommended that checks on 381 the key length be done before starting a cryptographic operation. 383 There are two reasonable ways to address this attack. First, a key 384 should not be used for a cryptographic operation until it has been 385 verified that it is controlled by a party trusted by the recipient. 386 This approach means that no cryptography will be done until a trust 387 decision about the key has been made, a process described in 388 Appendix D, Item 4 of [RFC7515]. Second, applications can impose 389 maximum as well as minimum length requirements on keys. This limits 390 the resources that would otherwise be consumed by the use of overly 391 large keys. 393 6.2. RSASSA-PSS Security Considerations 395 There is a theoretical hash substitution attack that can be mounted 396 against RSASSA-PSS [HASHID]. However, the requirement that the same 397 hash function be used consistently for all operations is an effective 398 mitigation against it. Unlike ECDSA, hash function outputs are not 399 truncated so that the full hash value is always signed. The internal 400 padding structure of RSASSA-PSS means that one needs to have multiple 401 collisions between the two hash functions to be successful in 402 producing a forgery based on changing the hash function. This is 403 highly unlikely. 405 6.3. RSAES-OAEP Security Considerations 407 A version of RSAES-OAEP using the default parameters specified in 408 Appendix A.2.1 of RFC 8017 is included because this is the most 409 widely implemented set of OAEP parameter choices. (Those default 410 parameters are the SHA-1 hash function and the MGF1 with SHA-1 mask 411 generation function.) 413 Keys used with RSAES-OAEP MUST follow the constraints in Section 7.1 414 of RFC 8017. Also, keys with a low private key exponent value, as 415 described in Section 3 of "Twenty Years of Attacks on the RSA 416 Cryptosystem" [Boneh99], MUST NOT be used. 418 7. References 420 7.1. Normative References 422 [Boneh99] Boneh, D., "Twenty Years of Attacks on the RSA 423 Cryptosystem", Notices of the American Mathematical 424 Society (AMS), Vol. 46, No. 2, pp. 203-213, 1999, 425 . 428 [I-D.ietf-cose-msg] 429 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 430 draft-ietf-cose-msg-24 (work in progress), November 2016. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 438 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 439 October 2013, . 441 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 442 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 443 2015, . 445 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 446 "PKCS #1: RSA Cryptography Specifications Version 2.2", 447 RFC 8017, DOI 10.17487/RFC8017, November 2016, 448 . 450 7.2. Informative References 452 [HASHID] Kaliski, B., "On Hash Function Firewalls in Signature 453 Schemes", Lecture Notes in Computer Science, Volume 454 2271, pp. 1-16, DOI 10.1007/3-540-45760-7_1, February 455 2002, . 458 [IANA.COSE] 459 IANA, "CBOR Object Signing and Encryption (COSE)", 460 . 462 [MultiPrimeRSA] 463 Hinek, M. and D. Cheriton, "On the Security of Multi-prime 464 RSA", June 2006. 466 Appendix A. Acknowledgements 468 This specification incorporates text from draft-ietf-cose-msg-05 by 469 Jim Schaad. Thanks are due to Ben Campbell, Roni Even, Steve Kent, 470 Kathleen Moriarty, Eric Rescorla, Adam Roach, Rich Salz, and Jim 471 Schaad for their reviews of the specification. 473 Appendix B. Document History 475 [[ to be removed by the RFC Editor before publication as an RFC ]] 477 -05 479 o Addressed IESG review comments. 481 o Updated the RFC 3447 reference to RFC 8017. 483 o Updated the field descriptions to use the wording from 484 Section A.1.2 of RFC 8017. 486 o Corrected an error in the RSAES-OAEP security considerations. 488 -04 490 o Addressed SecDir review comments by Steve Kent and Gen-ART review 491 comments by Roni Even. 493 -03 495 o Clarified the Security Considerations in ways suggested by 496 Kathleen Moriarty. 498 o Acknowledged reviewers. 500 -02 502 o Reorganized the security considerations. 504 o Flattened the section structure. 506 o Applied wording improvements suggested by Jim Schaad. 508 -01 510 o Completed the sets of IANA registration requests. 512 o Revised the algorithm assignments based on those in draft-ietf- 513 cose-msg-24. 515 -00 517 o This specification addresses COSE issue #21: Restore RSA-PSS and 518 the "RSA" key type. The initial version of this specification 519 incorporates text from draft-ietf-cose-msg-05 -- the last COSE 520 message specification version before the RSA algorithms were 521 removed. 523 Author's Address 524 Michael B. Jones 525 Microsoft 527 Email: mbj@microsoft.com 528 URI: http://self-issued.info/