idnits 2.17.1 draft-jones-cose-rsa-02.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 (March 9, 2017) is 2602 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 March 9, 2017 5 Expires: September 10, 2017 7 Using RSA Algorithms with COSE Messages 8 draft-jones-cose-rsa-02 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 September 10, 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 Registry . . . . . . . . . . . . . . . . 5 60 5.2. COSE Key Types Registry . . . . . . . . . . . . . . . . . 5 61 5.3. COSE Key Type Parameters Registry . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6.1. Key Size Security Considerations . . . . . . . . . . . . 6 64 6.2. RSASSA-PSS Security Considerations . . . . . . . . . . . 6 65 6.3. RSAES-OAEP Security Considerations . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 70 Appendix B. Document History . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 [RFC3447]. 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 [RFC3447]. 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 algorithms defined in this document can be found in Table 1. 106 +-------+-------+---------+-------------+-----------------------+ 107 | Name | Value | Hash | Salt Length | Description | 108 +-------+-------+---------+-------------+-----------------------+ 109 | PS256 | -37 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 | 110 | PS384 | -38 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 | 111 | PS512 | -39 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 | 112 +-------+-------+---------+-------------+-----------------------+ 114 Table 1: RSASSA-PSS Algorithm Values 116 3. RSAES-OAEP Key Encryption Algorithm 118 RSAES-OAEP is an asymmetric key encryption algorithm. The definition 119 of RSAEA-OAEP can be find in Section 7.1 of [RFC3447]. The algorithm 120 is parameterized using a masking generation function (mgf), a hash 121 function (h) and encoding parameters (P). For the algorithm 122 identifiers defined in this section: 124 o mgf is always set to MFG1 from [RFC3447] and uses the same hash 125 function as h. 127 o P is always set to the empty octet string. 129 Table 2 summarizes the rest of the values. 131 +-------------------------------+-------+---------+-----------------+ 132 | Name | Value | Hash | Description | 133 +-------------------------------+-------+---------+-----------------+ 134 | RSAES-OAEP w/ RFC 3447 | -40 | SHA-1 | RSAES OAEP w/ | 135 | default parameters | | | SHA-1 | 136 | RSAES-OAEP w/ SHA-256 | -41 | SHA-256 | RSAES OAEP w/ | 137 | | | | SHA-256 | 138 | RSAES-OAEP w/ SHA-512 | -42 | SHA-512 | RSAES OAEP w/ | 139 | | | | SHA-512 | 140 +-------------------------------+-------+---------+-----------------+ 142 Table 2: RSAES-OAEP Algorithm Values 144 The key type MUST be 'RSA'. 146 4. RSA Keys 148 Key types are identified by the 'kty' member of the COSE_Key object. 149 This specification defines one value for this member. 151 +------+-------+-------------+ 152 | Name | Value | Description | 153 +------+-------+-------------+ 154 | RSA | 3 | RSA Key | 155 +------+-------+-------------+ 157 Table 3: Key Type Values 159 This document defines a key structure for both the public and private 160 parts of RSA keys. Together, an RSA public key and an RSA private 161 key form an RSA key pair. 163 The document also provides support for the so-called "multi-prime" 164 RSA keys, in which the modulus may have more than two prime factors. 165 The benefit of multi-prime RSA is lower computational cost for the 166 decryption and signature primitives. For a discussion on how multi- 167 prime affects the security of RSA crypto-systems, the reader is 168 referred to [MultiPrimeRSA]. 170 This document follows the naming convention of [RFC3447] for the 171 naming of the fields of an RSA public or private key. Table 4 172 provides a summary of the label values and the types associated with 173 each of those labels. The requirements for fields for RSA keys are 174 as follows: 176 o For all keys, 'kty' MUST be present and MUST have a value of 3. 178 o For public keys, the fields 'n' and 'e' MUST be present. All 179 other fields defined in Table 4 MUST be absent. 181 o For private keys with two primes, the fields 'other', 'r_i', 'd_i' 182 and 't_i' MUST be absent; all other fields MUST be present. 184 o For private keys with more than two primes, all fields MUST be 185 present. For the third to nth primes, each of the primes is 186 represented as a map containing the fields 'r_i', 'd_i' and 't_i'. 187 The field 'other' is an array of those maps. 189 o All numeric key parameters are encoded in an unsigned big-endian 190 representation as an octet sequence using the CBOR byte string 191 type (major type 2). The octet sequence MUST utilize the minimum 192 number of octets needed to represent the value. For instance, the 193 value 32,768 is represented as the CBOR byte sequence 0b010_00010 194 (major type 2, additional information 2 for the length), 0x80 195 0x00. 197 +-------+----------+-------+-------+--------------------------------+ 198 | Name | Key Type | Value | Type | Description | 199 +-------+----------+-------+-------+--------------------------------+ 200 | n | 3 | -1 | bstr | Modulus Parameter | 201 | e | 3 | -2 | bstr | Exponent Parameter | 202 | d | 3 | -3 | bstr | Private Exponent Parameter | 203 | p | 3 | -4 | bstr | First Prime Factor | 204 | q | 3 | -5 | bstr | Second Prime Factor | 205 | dP | 3 | -6 | bstr | First Factor CRT Exponent | 206 | dQ | 3 | -7 | bstr | Second Factor CRT Exponent | 207 | qInv | 3 | -8 | bstr | First CRT Coefficient | 208 | other | 3 | -9 | array | Other Primes Info | 209 | r_i | 3 | -10 | bstr | i-th factor, Prime Factor | 210 | d_i | 3 | -11 | bstr | i-th factor, Factor CRT | 211 | | | | | Exponent | 212 | t_i | 3 | -12 | bstr | i-th factor, Factor CRT | 213 | | | | | Coefficient | 214 +-------+----------+-------+-------+--------------------------------+ 216 Table 4: RSA Key Parameters 218 5. IANA Considerations 220 5.1. COSE Algorithms Registry 222 This section registers values in the IANA "COSE Algorithms" registry. 224 The values in Table 1 and Table 2 are to be added to the registry. 226 5.2. COSE Key Types Registry 228 This section registers values in the IANA "COSE Key Types" registry. 230 The values in Table 3 are to be added to the registry. 232 5.3. COSE Key Type Parameters Registry 234 This section registers values in the IANA "COSE Key Type Parameters" 235 registry. 237 The values in Table 4 are to be added to the registry. 239 6. Security Considerations 241 6.1. Key Size Security Considerations 243 A key size of 2048 bits or larger MUST be used with these algorithms. 244 This key size corresponds roughly to the same strength as provided by 245 a 128-bit symmetric encryption algorithm. Implementations SHOULD be 246 able to encrypt and decrypt with modulus between 2048 and 16K bits in 247 length. Applications can impose additional restrictions on the 248 length of the modulus. 250 In addition to needing to worry about keys that are too small to 251 provide the required security, there are issues with keys that are 252 too large. Denial of service attacks have been mounted with overly 253 large keys or oddly sized keys. This has the potential to consume 254 resources with these keys. It is highly recommended that checks on 255 the key length be done before starting a cryptographic operation. 257 There are two reasonable ways to address this attack. First, a key 258 should not be used for a cryptographic operation until it has been 259 matched back to an authorized user. This approach means that no 260 cryptography would be done except for authorized users. Second, 261 applications can impose maximum as well as minimum length 262 requirements on keys. This limits the resources consumed even if the 263 matching is not performed until the cryptography has been done. 265 6.2. RSASSA-PSS Security Considerations 267 There is a theoretical hash substitution attack that can be mounted 268 against RSASSA-PSS. However, the requirement that the same hash 269 function be used consistently for all operations is an effective 270 mitigation against it. Unlike ECDSA, hash function outputs are not 271 truncated so that the full hash value is always signed. The internal 272 padding structure of RSASSA-PSS means that one needs to have multiple 273 collisions between the two hash functions to be successful in 274 producing a forgery based on changing the hash function. This is 275 highly unlikely. 277 6.3. RSAES-OAEP Security Considerations 279 A version of RSAES-OAEP using the default parameters specified in 280 Appendix A.2.1 of RFC 3447 is included because this is the most 281 widely implemented set of OAEP parameter choices. (Those default 282 parameters are the SHA-1 hash function and the MGF1 with SHA-1 mask 283 generation function.) While SHA-1 is deprecated as a general-purpose 284 hash function, no known practical attacks are enabled by its use in 285 this context. 287 7. References 289 7.1. Normative References 291 [I-D.ietf-cose-msg] 292 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 293 draft-ietf-cose-msg-24 (work in progress), November 2016. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 301 Standards (PKCS) #1: RSA Cryptography Specifications 302 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 303 2003, . 305 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 306 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 307 October 2013, . 309 7.2. Informative References 311 [MultiPrimeRSA] 312 Hinek, M. and D. Cheriton, "On the Security of Multi-prime 313 RSA", June 2006. 315 Appendix A. Acknowledgements 317 This specification incorporates text from draft-ietf-cose-msg-05 by 318 Jim Schaad. 320 Appendix B. Document History 322 [[ to be removed by the RFC Editor before publication as an RFC ]] 324 -02 326 o Reorganized the security considerations. 328 o Flattened the section structure. 330 o Applied wording improvements suggested by Jim Schaad. 332 -01 334 o Completed the sets of IANA registration requests. 336 o Revised the algorithm assignments based on those in draft-ietf- 337 cose-msg-24. 339 -00 341 o This specification addresses COSE issue #21: Restore RSA-PSS and 342 the "RSA" key type. The initial version of this specification 343 incorporates text from draft-ietf-cose-msg-05 -- the last COSE 344 message specification version before the RSA algorithms were 345 removed. 347 Author's Address 349 Michael B. Jones 350 Microsoft 352 Email: mbj@microsoft.com 353 URI: http://self-issued.info/