idnits 2.17.1 draft-jones-cose-rsa-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 4, 2016) is 2941 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) == Outdated reference: A later version (-24) exists of draft-ietf-cose-msg-11 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 April 4, 2016 5 Expires: October 6, 2016 7 Using RSA Algorithms with COSE Messages 8 draft-jones-cose-rsa-00 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 October 6, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. COSE Algorithm Registry . . . . . . . . . . . . . . . . . 6 65 5.2. COSE Key Type Parameter Registry . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 71 Appendix B. Document History . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The CBOR Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] 77 specification defines cryptographic message encodings using Concise 78 Binary Object Representation (CBOR) [RFC7049]. This specification 79 defines algorithm encodings and representations enabling RSA 80 algorithms to be used for COSE messages. 82 1.1. Requirements Notation and Conventions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in RFC 87 2119 [RFC2119]. 89 2. Signature Algorithms 91 2.1. RSASSA-PSS 93 The RSASSA-PSS signature algorithm is defined in [RFC3447]. 95 The RSASSA-PSS signature algorithm is parameterized with a hash 96 function (h), a mask generation function (mgf) and a salt length 97 (sLen). For this specification, the mask generation function is 98 fixed to be MGF1 as defined in [RFC3447]. It has been recommended 99 that the same hash function be used for hashing the data as well as 100 in the mask generation function, for this specification we following 101 this recommendation. The salt length is the same length as the hash 102 function output. 104 Implementations need to check that the key type is 'RSA' when 105 creating or verifying a signature. 107 The algorithms defined in this document can be found in Table 1. 109 +-------+-------+---------+-------------+-----------------------+ 110 | name | value | hash | salt length | description | 111 +-------+-------+---------+-------------+-----------------------+ 112 | PS256 | -26 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 | 113 | PS384 | -27 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 | 114 | PS512 | -28 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 | 115 +-------+-------+---------+-------------+-----------------------+ 117 Table 1: RSASSA-PSS Algorithm Values 119 2.1.1. Security Considerations 121 In addition to needing to worry about keys that are too small to 122 provide the required security, there are issues with keys that are 123 too large. Denial of service attacks have been mounted with overly 124 large keys. This has the potential to consume resources with 125 potentially bad keys. There are two reasonable ways to address this 126 attack. First, a key should not be used for a cryptographic 127 operation until it has been matched back to an authorized user. This 128 approach means that no cryptography would be done except for 129 authorized users. Second, applications can impose maximum as well as 130 minimum length requirements on keys. This limits the resources 131 consumed even if the matching is not performed until the cryptography 132 has been done. 134 There is a theoretical hash substitution attack that can be mounted 135 against RSASSA-PSS. However, the requirement that the same hash 136 function be used consistently for all operations is an effective 137 mitigation against it. Unlike ECDSA, hash functions are not 138 truncated so that the full hash value is always signed. The internal 139 padding structure of RSASSA-PSS means that one needs to have multiple 140 collisions between the two hash functions in order to be successful 141 in producing a forgery based on changing the hash function. This is 142 highly unlikely. 144 3. Recipient Algorithm Classes 146 3.1. Key Encryption 148 Key Encryption mode is also called key transport mode in some 149 standards. Key Encryption mode differs from Key Wrap mode in that it 150 uses an asymmetric encryption algorithm rather than a symmetric 151 encryption algorithm to protect the key. This document defines one 152 Key Encryption mode algorithm. 154 When using a key encryption algorithm, the COSE_encrypt structure for 155 the recipient is organized as follows: 157 o The 'protected' field MUST be absent. 159 o The plain text to be encrypted is the key from next layer down 160 (usually the content layer). 162 o At a minimum, the 'unprotected' field MUST contain the 'alg' 163 parameter and SHOULD contain a parameter identifying the 164 asymmetric key. 166 3.1.1. RSAES-OAEP 168 RSAES-OAEP is an asymmetric key encryption algorithm. The definition 169 of RSAEA-OAEP can be find in Section 7.1 of [RFC3447]. The algorithm 170 is parameterized using a masking generation function (mgf), a hash 171 function (h) and encoding parameters (P). For the algorithm 172 identifiers defined in this section: 174 o mgf is always set to MFG1 from [RFC3447] and uses the same hash 175 function as h. 177 o P is always set to the empty octet string. 179 Table 2 summarizes the rest of the values. 181 +----------------------+-------+---------+-----------------------+ 182 | name | value | hash | description | 183 +----------------------+-------+---------+-----------------------+ 184 | RSAES-OAEP w/SHA-256 | -25 | SHA-256 | RSAES OAEP w/ SHA-256 | 185 | RSAES-OAEP w/SHA-512 | -26 | SHA-512 | RSAES OAEP w/ SHA-512 | 186 +----------------------+-------+---------+-----------------------+ 188 Table 2: RSAES-OAEP Algorithm Values 190 The key type MUST be 'RSA'. 192 3.1.1.1. Security Considerations for RSAES-OAEP 194 A key size of 2048 bits or larger MUST be used with these algorithms. 195 This key size corresponds roughly to the same strength as provided by 196 a 128-bit symmetric encryption algorithm. 198 It is highly recommended that checks on the key length be done before 199 starting a decryption operation. One potential denial of service 200 operation is to provide encrypted objects using either abnormally 201 long or oddly sized RSA modulus values. Implementations SHOULD be 202 able to encrypt and decrypt with modulus between 2048 and 16K bits in 203 length. Applications can impose additional restrictions on the 204 length of the modulus. 206 4. Keys 208 Key types are identified by the 'kty' member of the COSE_Key object. 209 In this document we define one value for the member. 211 +------+-------+-------------+ 212 | name | value | description | 213 +------+-------+-------------+ 214 | RSA | 3 | RSA Keys | 215 +------+-------+-------------+ 217 Table 3: Key Type Values 219 4.1. RSA Keys 221 This document defines a key structure for both the public and private 222 halves of RSA keys. Together, an RSA public key and an RSA private 223 key form an RSA key pair. [[CREF1: Looking at the CBOR 224 specification, the bstr that we are looking in our table below should 225 most likely be specified as big numbers rather than as binary 226 strings. This means that we would use the tag 6.2 instead. From my 227 reading of the specification, there is no difference in the encoded 228 size of the resulting output. The specification of bignum does 229 explicitly allow for integers encoded with leading zeros. --JLS]] 231 The document also provides support for the so-called "multi-prime" 232 RSA where the modulus may have more than two prime factors. The 233 benefit of multi-prime RSA is lower computational cost for the 234 decryption and signature primitives. For a discussion on how multi- 235 prime affects the security of RSA crypto-systems, the reader is 236 referred to [MultiPrimeRSA]. 238 This document follows the naming convention of [RFC3447] for the 239 naming of the fields of an RSA public or private key. The table 240 Table 4 provides a summary of the label values and the types 241 associated with each of those labels. The requirements for fields 242 for RSA keys are as follows: 244 o For all keys, 'kty' MUST be present and MUST have a value of 3. 246 o For public keys, the fields 'n' and 'e' MUST be present. All 247 other fields defined in Table 4 MUST be absent. 249 o For private keys with two primes, the fields 'other', 'r_i', 'd_i' 250 and 't_i' MUST be absent, all other fields MUST be present. 252 o For private keys with more than two primes, all fields MUST be 253 present. For the third to nth primes, each of the primes is 254 represented as a map containing the fields 'r_i', 'd_i' and 't_i'. 255 The field 'other' is an array of those maps. 257 +-------+----------+-------+-------+--------------------------------+ 258 | name | key type | value | type | description | 259 +-------+----------+-------+-------+--------------------------------+ 260 | n | 3 | -1 | bstr | Modulus Parameter | 261 | e | 3 | -2 | int | Exponent Parameter | 262 | d | 3 | -3 | bstr | Private Exponent Parameter | 263 | p | 3 | -4 | bstr | First Prime Factor | 264 | q | 3 | -5 | bstr | Second Prime Factor | 265 | dP | 3 | -6 | bstr | First Factor CRT Exponent | 266 | dQ | 3 | -7 | bstr | Second Factor CRT Exponent | 267 | qInv | 3 | -8 | bstr | First CRT Coefficient | 268 | other | 3 | -9 | array | Other Primes Info | 269 | r_i | 3 | -10 | bstr | i-th factor, Prime Factor | 270 | d_i | 3 | -11 | bstr | i-th factor, Factor CRT | 271 | | | | | Exponent | 272 | t_i | 3 | -12 | bstr | i-th factor, Factor CRT | 273 | | | | | Coefficient | 274 +-------+----------+-------+-------+--------------------------------+ 276 Table 4: RSA Key Parameters 278 5. IANA Considerations 280 5.1. COSE Algorithm Registry 282 This section registers values in the IANA "COSE Algorithm Registry" 283 registry. 285 The values in Table 1 are to be added to the registry. 287 5.2. COSE Key Type Parameter Registry 289 This section registers values in the IANA "COSE Key Type Parameters" 290 registry. 292 The values in Table 4 are to be added to the registry. 294 6. Security Considerations 296 See the per-algorithm security considerations described in 297 Section 2.1.1 and Section 3.1.1.1. 299 7. References 301 7.1. Normative References 303 [I-D.ietf-cose-msg] 304 Schaad, J., "CBOR Encoded Message Syntax", draft-ietf- 305 cose-msg-11 (work in progress), March 2016. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 313 Standards (PKCS) #1: RSA Cryptography Specifications 314 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 315 2003, . 317 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 318 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 319 October 2013, . 321 7.2. Informative References 323 [MultiPrimeRSA] 324 Hinek, M. and D. Cheriton, "On the Security of Multi-prime 325 RSA", June 2006. 327 Appendix A. Acknowledgements 329 The initial version of this specification incorporates text from 330 draft-ietf-cose-msg-05 by Jim Schaad. 332 Appendix B. Document History 334 [[ to be removed by the RFC Editor before publication as an RFC ]] 336 -00 338 o This specification addresses COSE issue #21: Restore RSA-PSS and 339 the "RSA" key type. The initial version of this specification 340 incorporates text from draft-ietf-cose-msg-05 -- the last COSE 341 message specification version before the RSA algorithms were 342 removed. 344 Author's Address 346 Michael B. Jones 347 Microsoft 349 Email: mbj@microsoft.com 350 URI: http://self-issued.info/