idnits 2.17.00 (12 Aug 2021) /tmp/idnits34178/draft-ietf-cose-rfc8152bis-algs-12.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC8152, but the abstract doesn't seem to directly say this. It does mention RFC8152 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 September 2020) is 597 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8126' is defined on line 2273, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-13 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-14) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: draft-ietf-cose-hash-sig has been published as RFC 8778 == Outdated reference: A later version (-04) exists of draft-mattsson-cfrg-det-sigs-with-noise-02 == Outdated reference: draft-ietf-quic-tls has been published as RFC 9001 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COSE Working Group J. Schaad 3 Internet-Draft August Cellars 4 Obsoletes: 8152 (if approved) 24 September 2020 5 Intended status: Informational 6 Expires: 28 March 2021 8 CBOR Object Signing and Encryption (COSE): Initial Algorithms 9 draft-ietf-cose-rfc8152bis-algs-12 11 Abstract 13 Concise Binary Object Representation (CBOR) is a data format designed 14 for small code size and small message size. There is a need for the 15 ability to have basic security services defined for this data format. 16 THis document defines a set of algorithms that can be used with the 17 CBOR Object Signing and Encryption (COSE) protocol RFC XXXX. 19 Contributing to this document 21 This note is to be removed before publishing as an RFC. 23 The source for this draft is being maintained in GitHub. Suggested 24 changes should be submitted as pull requests at https://github.com/ 25 cose-wg/cose-rfc8152bis. Instructions are on that page as well. 26 Editorial changes can be managed in GitHub, but any substantial 27 issues need to be discussed on the COSE mailing list. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 28 March 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 64 1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 4 65 1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 66 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 5 67 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 69 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1.1. Security Considerations for ECDSA . . . . . . . . . . 7 71 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 8 72 2.2.1. Security Considerations for EdDSA . . . . . . . . . . 9 73 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9 74 3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9 75 3.1.1. Security Considerations for HMAC . . . . . . . . . . 11 76 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11 77 3.2.1. Security Considerations AES-CBC_MAC . . . . . . . . . 12 78 4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 79 4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1.1. Security Considerations for AES-GCM . . . . . . . . . 13 81 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.2.1. Security Considerations for AES-CCM . . . . . . . . . 17 83 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 18 84 4.3.1. Security Considerations for ChaCha20/Poly1305 . . . . 19 85 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 19 86 5.1. HMAC-Based Extract-and-Expand Key Derivation Function 87 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 5.2. Context Information Structure . . . . . . . . . . . . . . 21 89 6. Content Key Distribution Methods . . . . . . . . . . . . . . 26 90 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 27 91 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 27 92 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 28 93 6.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 29 94 6.2.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 30 95 6.3. Direct Key Agreement . . . . . . . . . . . . . . . . . . 31 96 6.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 31 97 6.4. Key Agreement with Key Wrap . . . . . . . . . . . . . . . 34 98 6.4.1. ECDH with Key Wrap . . . . . . . . . . . . . . . . . 35 99 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 37 100 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 37 101 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 38 102 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 39 103 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 40 104 8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 41 105 8.1. Assignments for Existing Algorithms . . . . . . . . . . . 42 106 8.2. Assignments for Existing Key Types . . . . . . . . . . . 42 107 8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 42 108 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 45 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 110 10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 45 111 10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 46 112 10.3. Changes to the "COSE Key Type Parameters" registry . . . 46 113 10.4. Expert Review Instructions . . . . . . . . . . . . . . . 46 114 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 116 12.1. Normative References . . . . . . . . . . . . . . . . . . 49 117 12.2. Informative References . . . . . . . . . . . . . . . . . 51 118 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 54 121 1. Introduction 123 There has been an increased focus on small, constrained devices that 124 make up the Internet of Things (IoT). One of the standards that has 125 come out of this process is "Concise Binary Object Representation 126 (CBOR)" [RFC7049]. CBOR extended the data model of JavaScript Object 127 Notation (JSON) [STD90] by allowing for binary data, among other 128 changes. CBOR is being adopted by several of the IETF working groups 129 dealing with the IoT world as their encoding of data structures. 130 CBOR was designed specifically to be both small in terms of messages 131 transported and implementation size and be a schema-free decoder. A 132 need exists to provide message security services for IoT, and using 133 CBOR as the message-encoding format makes sense. 135 The core COSE specification consists of two documents. 136 [I-D.ietf-cose-rfc8152bis-struct] contains the serialization 137 structures and the procedures for using the different cryptographic 138 algorithms. This document provides an initial set of algorithms for 139 use with those structures. 141 1.1. Requirements Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 1.2. Changes from RFC8152 151 * Extract the sections dealing with specific algorithms into this 152 document. The sections dealing with structure and general 153 processing rules are placed in [I-D.ietf-cose-rfc8152bis-struct]. 155 * Text clarifications and changes in terminology. 157 1.3. Document Terminology 159 In this document, we use the following terminology: 161 Byte is a synonym for octet. 163 Constrained Application Protocol (CoAP) is a specialized web transfer 164 protocol for use in constrained systems. It is defined in [RFC7252]. 166 Authenticated Encryption (AE) [RFC5116] algorithms are encryption 167 algorithms that provide an authentication check of the contents with 168 the encryption service. An example of an AE algorithm used in COSE 169 is AES Key Wrap [RFC3394]. These algorithms are used for key 170 encryption algorithms, but AEAD algorithms would be preferred. 172 Authenticated Encryption with Associated Data (AEAD) [RFC5116] 173 algorithms provide the same authentication service of the content as 174 AE algorithms do. They also allow for associated data to be included 175 in the authentication service, but which is not part of the encrypted 176 body. An example of an AEAD algorithm used in COSE is AES-GCM 177 [RFC5116]. These algorithms are used for content encryption and can 178 be used for key encryption as well. 180 The term 'byte string' is used for sequences of bytes, while the term 181 'text string' is used for sequences of characters. 183 The tables for algorithms contain the following columns: 185 * A name for use in documents for the algorithms. 187 * The value used on the wire for the algorithm. One place this is 188 used is the algorithm header parameter of a message. 190 * A short description so that the algorithm can be easily identified 191 when scanning the IANA registry. 193 Additional columns may be present in the table depending on the 194 algorithms. 196 1.4. CBOR Grammar 198 At the time that [RFC8152] was initially published, the CBOR Data 199 Definition Language (CDDL) [RFC8610] had not yet been published. 200 This document uses a variant of CDDL which is described in 201 [I-D.ietf-cose-rfc8152bis-struct]. 203 1.5. Examples 205 A GitHub project has been created at [GitHub-Examples] that contains 206 a set of testing examples as well. Each example is found in a JSON 207 file that contains the inputs used to create the example, some of the 208 intermediate values that can be used for debugging, and the output of 209 the example. The results are encoded using both hexadecimal and CBOR 210 diagnostic notation format. 212 Some of the examples are designed to test failure case; these are 213 clearly marked as such in the JSON file. If errors in the examples 214 in this document are found, the examples on GitHub will be updated, 215 and a note to that effect will be placed in the JSON file. 217 2. Signature Algorithms 219 Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic 220 description of signature algorithms. The document defines signature 221 algorithm identifiers for two signature algorithms. 223 2.1. ECDSA 225 ECDSA [DSS] defines a signature algorithm using ECC. Implementations 226 SHOULD use a deterministic version of ECDSA such as the one defined 227 in [RFC6979]. The use of a deterministic signature algorithm allows 228 for systems to avoid relying on random number generators in order to 229 avoid generating the same value of 'k' (the per-message random 230 value). Biased generation of the value 'k' can be attacked, and 231 collisions of this value leads to leaked keys. It additionally 232 allows for doing deterministic tests for the signature algorithm. 233 The use of deterministic ECDSA does not lessen the need to have good 234 random number generation when creating the private key. 236 The ECDSA signature algorithm is parameterized with a hash function 237 (h). In the event that the length of the hash function output is 238 greater than the group of the key, the leftmost bytes of the hash 239 output are used. 241 The algorithms defined in this document can be found in Table 1. 243 +=======+=======+=========+==================+ 244 | Name | Value | Hash | Description | 245 +=======+=======+=========+==================+ 246 | ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 | 247 +-------+-------+---------+------------------+ 248 | ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 | 249 +-------+-------+---------+------------------+ 250 | ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 | 251 +-------+-------+---------+------------------+ 253 Table 1: ECDSA Algorithm Values 255 This document defines ECDSA to work only with the curves P-256, 256 P-384, and P-521. This document requires that the curves be encoded 257 using the 'EC2' (two coordinate elliptic curve) key type. 258 Implementations need to check that the key type and curve are correct 259 when creating and verifying a signature. Future documents may define 260 it to work with other curves and points in the future. 262 In order to promote interoperability, it is suggested that SHA-256 be 263 used only with curve P-256, SHA-384 be used only with curve P-384, 264 and SHA-512 be used with curve P-521. This is aligned with the 265 recommendation in Section 4 of [RFC5480]. 267 The signature algorithm results in a pair of integers (R, S). These 268 integers will be the same length as the length of the key used for 269 the signature process. The signature is encoded by converting the 270 integers into byte strings of the same length as the key size. The 271 length is rounded up to the nearest byte and is left padded with zero 272 bits to get to the correct length. The two integers are then 273 concatenated together to form a byte string that is the resulting 274 signature. 276 Using the function defined in [RFC8017], the signature is: 278 Signature = I2OSP(R, n) | I2OSP(S, n) 280 where n = ceiling(key_length / 8) 282 When using a COSE key for this algorithm, the following checks are 283 made: 285 * The 'kty' field MUST be present, and it MUST be 'EC2'. 287 * If the 'alg' field is present, it MUST match the ECDSA signature 288 algorithm being used. 290 * If the 'key_ops' field is present, it MUST include 'sign' when 291 creating an ECDSA signature. 293 * If the 'key_ops' field is present, it MUST include 'verify' when 294 verifying an ECDSA signature. 296 2.1.1. Security Considerations for ECDSA 298 The security strength of the signature is no greater than the minimum 299 of the security strength associated with the bit length of the key 300 and the security strength of the hash function. 302 Note: Use of a deterministic signature technique is a good idea even 303 when good random number generation exists. Doing so both reduces the 304 possibility of having the same value of 'k' in two signature 305 operations and allows for reproducible signature values, which helps 306 testing. There have been recent attacks involving faulting the 307 device in order to extract the key. This can be addressed by 308 combining both randomness and determinism 309 [I-D.mattsson-cfrg-det-sigs-with-noise]. 311 There are two substitution attacks that can theoretically be mounted 312 against the ECDSA signature algorithm. 314 * Changing the curve used to validate the signature: If one changes 315 the curve used to validate the signature, then potentially one 316 could have two messages with the same signature, each computed 317 under a different curve. The only requirement on the new curve is 318 that its order be the same as the old one and it be acceptable to 319 the client. An example would be to change from using the curve 320 secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit 321 curves.) We currently do not have any way to deal with this 322 version of the attack except to restrict the overall set of curves 323 that can be used. 325 * Change the hash function used to validate the signature: If one 326 either has two different hash functions of the same length or can 327 truncate a hash function, then one could potentially find 328 collisions between the hash functions rather than within a single 329 hash function (for example, truncating SHA-512 to 256 bits might 330 collide with a SHA-256 bit hash value). As the hash algorithm is 331 part of the signature algorithm identifier, this attack is 332 mitigated by including a signature algorithm identifier in the 333 protected header bucket. 335 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) 337 [RFC8032] describes the elliptic curve signature scheme Edwards-curve 338 Digital Signature Algorithm (EdDSA). In that document, the signature 339 algorithm is instantiated using parameters for edwards25519 and 340 edwards448 curves. The document additionally describes two variants 341 of the EdDSA algorithm: Pure EdDSA, where no hash function is applied 342 to the content before signing, and HashEdDSA, where a hash function 343 is applied to the content before signing and the result of that hash 344 function is signed. For EdDSA, the content to be signed (either the 345 message or the pre-hash value) is processed twice inside of the 346 signature algorithm. For use with COSE, only the pure EdDSA version 347 is used. This is because it is not expected that extremely large 348 contents are going to be needed and, based on the arrangement of the 349 message structure, the entire message is going to need to be held in 350 memory in order to create or verify a signature. This means that 351 there does not appear to be a need to be able to do block updates of 352 the hash, followed by eliminating the message from memory. 353 Applications can provide the same features by defining the content of 354 the message as a hash value and transporting the COSE object (with 355 the hash value) and the content as separate items. 357 The algorithms defined in this document can be found in Table 2. A 358 single signature algorithm is defined, which can be used for multiple 359 curves. 361 +=======+=======+=============+ 362 | Name | Value | Description | 363 +=======+=======+=============+ 364 | EdDSA | -8 | EdDSA | 365 +-------+-------+-------------+ 367 Table 2: EdDSA Algorithm Values 369 [RFC8032] describes the method of encoding the signature value. 371 When using a COSE key for this algorithm, the following checks are 372 made: 374 * The 'kty' field MUST be present, and it MUST be 'OKP' (Octet Key 375 Pair). 377 * The 'crv' field MUST be present, and it MUST be a curve defined 378 for this signature algorithm. 380 * If the 'alg' field is present, it MUST match 'EdDSA'. 382 * If the 'key_ops' field is present, it MUST include 'sign' when 383 creating an EdDSA signature. 385 * If the 'key_ops' field is present, it MUST include 'verify' when 386 verifying an EdDSA signature. 388 2.2.1. Security Considerations for EdDSA 390 How public values are computed is not the same when looking at EdDSA 391 and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public 392 key should not be used with the other algorithm. 394 If batch signature verification is performed, a well-seeded 395 cryptographic random number generator is REQUIRED (Section 8.2 of 396 [RFC8032]). Signing and non-batch signature verification are 397 deterministic operations and do not need random numbers of any kind. 399 3. Message Authentication Code (MAC) Algorithms 401 Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic 402 description of MAC algorithms. This section defines the conventions 403 for two MAC algorithms. 405 3.1. Hash-Based Message Authentication Codes (HMACs) 407 HMAC [RFC2104] [RFC4231] was designed to deal with length extension 408 attacks. The algorithm was also designed to allow for new hash 409 algorithms to be directly plugged in without changes to the hash 410 function. The HMAC design process has been shown as solid since, 411 while the security of hash algorithms such as MD5 has decreased over 412 time; the security of HMAC combined with MD5 has not yet been shown 413 to be compromised [RFC6151]. 415 The HMAC algorithm is parameterized by an inner and outer padding, a 416 hash function (h), and an authentication tag value length. For this 417 specification, the inner and outer padding are fixed to the values 418 set in [RFC2104]. The length of the authentication tag corresponds 419 to the difficulty of producing a forgery. For use in constrained 420 environments, we define one HMAC algorithm that is truncated. There 421 are currently no known issues with truncation; however, the security 422 strength of the message tag is correspondingly reduced in strength. 423 When truncating, the leftmost tag length bits are kept and 424 transmitted. 426 The algorithms defined in this document can be found in Table 3. 428 +=============+=======+=========+============+======================+ 429 | Name | Value | Hash | Tag Length | Description | 430 +=============+=======+=========+============+======================+ 431 | HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 | 432 | 256/64 | | | | truncated to 64 bits | 433 +-------------+-------+---------+------------+----------------------+ 434 | HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 | 435 | 256/256 | | | | | 436 +-------------+-------+---------+------------+----------------------+ 437 | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 | 438 | 384/384 | | | | | 439 +-------------+-------+---------+------------+----------------------+ 440 | HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 | 441 | 512/512 | | | | | 442 +-------------+-------+---------+------------+----------------------+ 444 Table 3: HMAC Algorithm Values 446 Some recipient algorithms transport the key, while others derive a 447 key from secret data. For those algorithms that transport the key 448 (such as AES Key Wrap), the size of the HMAC key SHOULD be the same 449 size as the output of the underlying hash function. For those 450 algorithms that derive the key (such as ECDH), the derived key MUST 451 be the same size as the underlying hash function. 453 When using a COSE key for this algorithm, the following checks are 454 made: 456 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 458 * If the 'alg' field is present, it MUST match the HMAC algorithm 459 being used. 461 * If the 'key_ops' field is present, it MUST include 'MAC create' 462 when creating an HMAC authentication tag. 464 * If the 'key_ops' field is present, it MUST include 'MAC verify' 465 when verifying an HMAC authentication tag. 467 Implementations creating and validating MAC values MUST validate that 468 the key type, key length, and algorithm are correct and appropriate 469 for the entities involved. 471 3.1.1. Security Considerations for HMAC 473 HMAC has proved to be resistant to attack even when used with 474 weakened hash algorithms. The current best known attack is to brute 475 force the key. This means that key size is going to be directly 476 related to the security of an HMAC operation. 478 3.2. AES Message Authentication Code (AES-CBC-MAC) 480 AES-CBC-MAC is defined in [MAC]. (Note that this is not the same 481 algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) 482 [RFC4493].) 484 AES-CBC-MAC is parameterized by the key length, the authentication 485 tag length, and the Initialization Vector (IV) used. For all of 486 these algorithms, the IV is fixed to all zeros. We provide an array 487 of algorithms for various key lengths and tag lengths. The 488 algorithms defined in this document are found in Table 4. 490 +=========+=======+============+============+==================+ 491 | Name | Value | Key Length | Tag Length | Description | 492 +=========+=======+============+============+==================+ 493 | AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit | 494 | 128/64 | | | | key, 64-bit tag | 495 +---------+-------+------------+------------+------------------+ 496 | AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit | 497 | 256/64 | | | | key, 64-bit tag | 498 +---------+-------+------------+------------+------------------+ 499 | AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit | 500 | 128/128 | | | | key, 128-bit tag | 501 +---------+-------+------------+------------+------------------+ 502 | AES-MAC | 26 | 256 | 128 | AES-MAC 256-bit | 503 | 256/128 | | | | key, 128-bit tag | 504 +---------+-------+------------+------------+------------------+ 506 Table 4: AES-MAC Algorithm Values 508 Keys may be obtained either from a key structure or from a recipient 509 structure. Implementations creating and validating MAC values MUST 510 validate that the key type, key length, and algorithm are correct and 511 appropriate for the entities involved. 513 When using a COSE key for this algorithm, the following checks are 514 made: 516 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 518 * If the 'alg' field is present, it MUST match the AES-MAC algorithm 519 being used. 521 * If the 'key_ops' field is present, it MUST include 'MAC create' 522 when creating an AES-MAC authentication tag. 524 * If the 'key_ops' field is present, it MUST include 'MAC verify' 525 when verifying an AES-MAC authentication tag. 527 3.2.1. Security Considerations AES-CBC_MAC 529 A number of attacks exist against Cipher Block Chaining Message 530 Authentication Code (CBC-MAC) that need to be considered. 532 * A single key must only be used for messages of a fixed or known 533 length. If this is not the case, an attacker will be able to 534 generate a message with a valid tag given two message and tag 535 pairs. This can be addressed by using different keys for messages 536 of different lengths. The current structure mitigates this 537 problem, as a specific encoding structure that includes lengths is 538 built and signed. (CMAC also addresses this issue.) 540 * In cipher Block Chaining (CBC) mode, if the same key is used for 541 both encryption and authentication operations, an attacker can 542 produce messages with a valid authentication code. 544 * If the IV can be modified, then messages can be forged. This is 545 addressed by fixing the IV to all zeros. 547 4. Content Encryption Algorithms 549 Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic 550 description of Content Encryption algorithms. This document defines 551 the identifier and usages for three content encryption algorithms. 553 4.1. AES GCM 555 The Galois/Counter Mode (GCM) mode is a generic AEAD block cipher 556 mode defined in [AES-GCM]. The GCM mode is combined with the AES 557 block encryption algorithm to define an AEAD cipher. 559 The GCM mode is parameterized by the size of the authentication tag 560 and the size of the nonce. This document fixes the size of the nonce 561 at 96 bits. The size of the authentication tag is limited to a small 562 set of values. For this document however, the size of the 563 authentication tag is fixed at 128 bits. 565 The set of algorithms defined in this document are in Table 5. 567 +=========+=======+==========================================+ 568 | Name | Value | Description | 569 +=========+=======+==========================================+ 570 | A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag | 571 +---------+-------+------------------------------------------+ 572 | A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag | 573 +---------+-------+------------------------------------------+ 574 | A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag | 575 +---------+-------+------------------------------------------+ 577 Table 5: Algorithm Value for AES-GCM 579 Keys may be obtained either from a key structure or from a recipient 580 structure. Implementations encrypting and decrypting MUST validate 581 that the key type, key length, and algorithm are correct and 582 appropriate for the entities involved. 584 When using a COSE key for this algorithm, the following checks are 585 made: 587 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 589 * If the 'alg' field is present, it MUST match the AES-GCM algorithm 590 being used. 592 * If the 'key_ops' field is present, it MUST include 'encrypt' or 593 'wrap key' when encrypting. 595 * If the 'key_ops' field is present, it MUST include 'decrypt' or 596 'unwrap key' when decrypting. 598 4.1.1. Security Considerations for AES-GCM 600 When using AES-GCM, the following restrictions MUST be enforced: 602 * The key and nonce pair MUST be unique for every message encrypted. 604 * The total number of messages encrypted for a single key MUST NOT 605 exceed 2^32 [SP800-38d]. An explicit check is required only in 606 environments where it is expected that it might be exceeded. 608 * A more recent analysis in [ROBUST] indicates that the the number 609 of failed decryptions needs to be taken into account as part 610 determining when a key roll-over is to be done. Following the 611 recommendation of for DTLS, the number of failed message 612 decryptions should be limited to 2^36. 614 Consideration was given to supporting smaller tag values; the 615 constrained community would desire tag sizes in the 64-bit range. 616 Doing so drastically changes both the maximum messages size 617 (generally not an issue) and the number of times that a key can be 618 used. Given that Counter with CBC-MAC (CCM) is the usual mode for 619 constrained environments, restricted modes are not supported. 621 4.2. AES CCM 623 CCM is a generic authentication encryption block cipher mode defined 624 in [RFC3610]. The CCM mode is combined with the AES block encryption 625 algorithm to define a commonly used content encryption algorithm used 626 in constrained devices. 628 The CCM mode has two parameter choices. The first choice is M, the 629 size of the authentication field. The choice of the value for M 630 involves a trade-off between message growth (from the tag) and the 631 probability that an attacker can undetectably modify a message. The 632 second choice is L, the size of the length field. This value 633 requires a trade-off between the maximum message size and the size of 634 the Nonce. 636 It is unfortunate that the specification for CCM specified L and M as 637 a count of bytes rather than a count of bits. This leads to possible 638 misunderstandings where AES-CCM-8 is frequently used to refer to a 639 version of CCM mode where the size of the authentication is 64 bits 640 and not 8 bits. These values have traditionally been specified as 641 bit counts rather than byte counts. This document will follow the 642 convention of using bit counts so that it is easier to compare the 643 different algorithms presented in this document. 645 We define a matrix of algorithms in this document over the values of 646 L and M. Constrained devices are usually operating in situations 647 where they use short messages and want to avoid doing recipient- 648 specific cryptographic operations. This favors smaller values of 649 both L and M. Less-constrained devices will want to be able to use 650 larger messages and are more willing to generate new keys for every 651 operation. This favors larger values of L and M. 653 The following values are used for L: 655 16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. 656 This is sufficiently long for messages in the constrained world. 657 The nonce length is 13 bytes allowing for 2^104 possible values of 658 the nonce without repeating. 660 64 bits (8): This limits messages to 2^64 bytes in length. The 661 nonce length is 7 bytes allowing for 2^56 possible values of the 662 nonce without repeating. 664 The following values are used for M: 666 64 bits (8): This produces a 64-bit authentication tag. This 667 implies that there is a 1 in 2^64 chance that a modified message 668 will authenticate. 670 128 bits (16): This produces a 128-bit authentication tag. This 671 implies that there is a 1 in 2^128 chance that a modified message 672 will authenticate. 674 +====================+=======+====+=====+========+===============+ 675 | Name | Value | L | M | Key | Description | 676 | | | | | Length | | 677 +====================+=======+====+=====+========+===============+ 678 | AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode | 679 | | | | | | 128-bit key, | 680 | | | | | | 64-bit tag, | 681 | | | | | | 13-byte nonce | 682 +--------------------+-------+----+-----+--------+---------------+ 683 | AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode | 684 | | | | | | 256-bit key, | 685 | | | | | | 64-bit tag, | 686 | | | | | | 13-byte nonce | 687 +--------------------+-------+----+-----+--------+---------------+ 688 | AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode | 689 | | | | | | 128-bit key, | 690 | | | | | | 64-bit tag, | 691 | | | | | | 7-byte nonce | 692 +--------------------+-------+----+-----+--------+---------------+ 693 | AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode | 694 | | | | | | 256-bit key, | 695 | | | | | | 64-bit tag, | 696 | | | | | | 7-byte nonce | 697 +--------------------+-------+----+-----+--------+---------------+ 698 | AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode | 699 | | | | | | 128-bit key, | 700 | | | | | | 128-bit tag, | 701 | | | | | | 13-byte nonce | 702 +--------------------+-------+----+-----+--------+---------------+ 703 | AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode | 704 | | | | | | 256-bit key, | 705 | | | | | | 128-bit tag, | 706 | | | | | | 13-byte nonce | 707 +--------------------+-------+----+-----+--------+---------------+ 708 | AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode | 709 | | | | | | 128-bit key, | 710 | | | | | | 128-bit tag, | 711 | | | | | | 7-byte nonce | 712 +--------------------+-------+----+-----+--------+---------------+ 713 | AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode | 714 | | | | | | 256-bit key, | 715 | | | | | | 128-bit tag, | 716 | | | | | | 7-byte nonce | 717 +--------------------+-------+----+-----+--------+---------------+ 719 Table 6: Algorithm Values for AES-CCM 721 Keys may be obtained either from a key structure or from a recipient 722 structure. Implementations encrypting and decrypting MUST validate 723 that the key type, key length, and algorithm are correct and 724 appropriate for the entities involved. 726 When using a COSE key for this algorithm, the following checks are 727 made: 729 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 731 * If the 'alg' field is present, it MUST match the AES-CCM algorithm 732 being used. 734 * If the 'key_ops' field is present, it MUST include 'encrypt' or 735 'wrap key' when encrypting. 737 * If the 'key_ops' field is present, it MUST include 'decrypt' or 738 'unwrap key' when decrypting. 740 4.2.1. Security Considerations for AES-CCM 742 When using AES-CCM, the following restrictions MUST be enforced: 744 * The key and nonce pair MUST be unique for every message encrypted. 745 Note that the value of L influences the number of unique nonces. 747 * The total number of times the AES block cipher is used MUST NOT 748 exceed 2^61 operations. This limitation is the sum of times the 749 block cipher is used in computing the MAC value and in performing 750 stream encryption operations. An explicit check is required only 751 in environments where it is expected that it might be exceeded. 753 * [I-D.ietf-quic-tls] contains an analysis on the use of AES-CCM in 754 that environment. Based on that reommendation, one should 755 restrict the number of messages encrypted to 2^23. If one is 756 using the 64-bit tag, then the limits are signficantly smaller if 757 one wants to keep the same integrity limits. A protocol 758 recommending this needs to analysis what level of integrity is 759 acceptable for the smaller tag size. It may be that to keep the 760 desired integrity one needs to re-key as often as every 2^7 761 messages. 763 * In addition to the number of messages successfully decrypted, the 764 number of failed decryptions needs to be kept as well. If the 765 number of failed decryptions exceeds 2^23 then a rekeying 766 operation should occur. 768 [RFC3610] additionally calls out one other consideration of note. It 769 is possible to do a pre-computation attack against the algorithm in 770 cases where portions of the plaintext are highly predictable. This 771 reduces the security of the key size by half. Ways to deal with this 772 attack include adding a random portion to the nonce value and/or 773 increasing the key size used. Using a portion of the nonce for a 774 random value will decrease the number of messages that a single key 775 can be used for. Increasing the key size may require more resources 776 in the constrained device. See Sections 5 and 10 of [RFC3610] for 777 more information. 779 4.3. ChaCha20 and Poly1305 781 ChaCha20 and Poly1305 combined together is an AEAD mode that is 782 defined in [RFC8439]. This is an algorithm defined to be a cipher 783 that is not AES and thus would not suffer from any future weaknesses 784 found in AES. These cryptographic functions are designed to be fast 785 in software-only implementations. 787 The ChaCha20/Poly1305 AEAD construction defined in [RFC8439] has no 788 parameterization. It takes a 256-bit key and a 96-bit nonce, as well 789 as the plaintext and additional data as inputs and produces the 790 ciphertext as an option. We define one algorithm identifier for this 791 algorithm in Table 7. 793 +===================+=======+==========================+ 794 | Name | Value | Description | 795 +===================+=======+==========================+ 796 | ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ | 797 | | | 256-bit key, 128-bit tag | 798 +-------------------+-------+--------------------------+ 800 Table 7: Algorithm Value for ChaCha20/Poly1305 802 Keys may be obtained either from a key structure or from a recipient 803 structure. Implementations encrypting and decrypting MUST validate 804 that the key type, key length, and algorithm are correct and 805 appropriate for the entities involved. 807 When using a COSE key for this algorithm, the following checks are 808 made: 810 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 812 * If the 'alg' field is present, it MUST match the ChaCha20/Poly1305 813 algorithm being used. 815 * If the 'key_ops' field is present, it MUST include 'encrypt' or 816 'wrap key' when encrypting. 818 * If the 'key_ops' field is present, it MUST include 'decrypt' or 819 'unwrap key' when decrypting. 821 4.3.1. Security Considerations for ChaCha20/Poly1305 823 The key and nonce values MUST be a unique pair for every invocation 824 of the algorithm. Nonce counters are considered to be an acceptable 825 way of ensuring that they are unique. 827 A more recent analysis in [ROBUST] indicates that the the number of 828 failed decryptions needs to be taken into account as part determining 829 when a key roll-over is to be done. Following the recommendation of 830 for DTLS, the number of failed message decryptions should be limited 831 to 2^36. 833 [I-D.ietf-quic-tls] recommends that no more than 2^24.5 messages be 834 encrypted under a single key. 836 5. Key Derivation Functions (KDFs) 838 Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic 839 description of Key Derivation Functions. This document defines a 840 single context structure and a single KDF. These elements are used 841 for all of the recipient algorithms defined in this document that 842 require a KDF process. These algorithms are defined in Sections 843 6.1.2, 6.3.1, and 6.4.1. 845 5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) 847 The HKDF key derivation algorithm is defined in [RFC5869][HKDF]. 849 The HKDF algorithm takes these inputs: 851 secret -- a shared value that is secret. Secrets may be either 852 previously shared or derived from operations like a Diffie-Hellman 853 (DH) key agreement. 855 salt -- an optional value that is used to change the generation 856 process. The salt value can be either public or private. If the 857 salt is public and carried in the message, then the 'salt' 858 algorithm header parameter defined in Table 9 is used. While 859 [RFC5869] suggests that the length of the salt be the same as the 860 length of the underlying hash value, any positive salt length will 861 improve the security as different key values will be generated. 862 This parameter is protected by being included in the key 863 computation and does not need to be separately authenticated. The 864 salt value does not need to be unique for every message sent. 866 length -- the number of bytes of output that need to be generated. 868 context information -- Information that describes the context in 869 which the resulting value will be used. Making this information 870 specific to the context in which the material is going to be used 871 ensures that the resulting material will always be tied to that 872 usage. The context structure defined in Section 5.2 is used by 873 the KDFs in this document. 875 PRF -- The underlying pseudorandom function to be used in the HKDF 876 algorithm. The PRF is encoded into the HKDF algorithm selection. 878 HKDF is defined to use HMAC as the underlying PRF. However, it is 879 possible to use other functions in the same construct to provide a 880 different KDF that is more appropriate in the constrained world. 881 Specifically, one can use AES-CBC-MAC as the PRF for the expand step, 882 but not for the extract step. When using a good random shared secret 883 of the correct length, the extract step can be skipped. For the AES 884 algorithm versions, the extract step is always skipped. 886 The extract step cannot be skipped if the secret is not uniformly 887 random, for example, if it is the result of an ECDH key agreement 888 step. This implies that the AES HKDF version cannot be used with 889 ECDH. If the extract step is skipped, the 'salt' value is not used 890 as part of the HKDF functionality. 892 The algorithms defined in this document are found in Table 8. 894 +==============+===================+========================+ 895 | Name | PRF | Description | 896 +==============+===================+========================+ 897 | HKDF SHA-256 | HMAC with SHA-256 | HKDF using HMAC | 898 | | | SHA-256 as the PRF | 899 +--------------+-------------------+------------------------+ 900 | HKDF SHA-512 | HMAC with SHA-512 | HKDF using HMAC | 901 | | | SHA-512 as the PRF | 902 +--------------+-------------------+------------------------+ 903 | HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as | 904 | MAC-128 | | the PRF w/ 128-bit key | 905 +--------------+-------------------+------------------------+ 906 | HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as | 907 | MAC-256 | | the PRF w/ 256-bit key | 908 +--------------+-------------------+------------------------+ 910 Table 8: HKDF Algorithms 912 +======+=======+======+============================+=============+ 913 | Name | Label | Type | Algorithm | Description | 914 +======+=======+======+============================+=============+ 915 | salt | -20 | bstr | direct+HKDF-SHA-256, | Random salt | 916 | | | | direct+HKDF-SHA-512, | | 917 | | | | direct+HKDF-AES-128, | | 918 | | | | direct+HKDF-AES-256, ECDH- | | 919 | | | | ES+HKDF-256, ECDH-ES+HKDF- | | 920 | | | | 512, ECDH-SS+HKDF-256, | | 921 | | | | ECDH-SS+HKDF-512, ECDH- | | 922 | | | | ES+A128KW, ECDH-ES+A192KW, | | 923 | | | | ECDH-ES+A256KW, ECDH- | | 924 | | | | SS+A128KW, ECDH-SS+A192KW, | | 925 | | | | ECDH-SS+A256KW | | 926 +------+-------+------+----------------------------+-------------+ 928 Table 9: HKDF Algorithm Parameters 930 5.2. Context Information Structure 932 The context information structure is used to ensure that the derived 933 keying material is "bound" to the context of the transaction. The 934 context information structure used here is based on that defined in 935 [SP800-56A]. By using CBOR for the encoding of the context 936 information structure, we automatically get the same type and length 937 separation of fields that is obtained by the use of ASN.1. This 938 means that there is no need to encode the lengths for the base 939 elements, as it is done by the encoding used in JOSE (Section 4.6.2 940 of [RFC7518]). 942 The context information structure refers to PartyU and PartyV as the 943 two parties that are doing the key derivation. Unless the 944 application protocol defines differently, we assign PartyU to the 945 entity that is creating the message and PartyV to the entity that is 946 receiving the message. By doing this association, different keys 947 will be derived for each direction as the context information is 948 different in each direction. 950 The context structure is built from information that is known to both 951 entities. This information can be obtained from a variety of 952 sources: 954 * Fields can be defined by the application. This is commonly used 955 to assign fixed names to parties, but it can be used for other 956 items such as nonces. 958 * Fields can be defined by usage of the output. Examples of this 959 are the algorithm and key size that are being generated. 961 * Fields can be defined by parameters from the message. We define a 962 set of header parameters in Table 10 that can be used to carry the 963 values associated with the context structure. Examples of this 964 are identities and nonce values. These header parameters are 965 designed to be placed in the unprotected bucket of the recipient 966 structure; they do not need to be in the protected bucket since 967 they already are included in the cryptographic computation by 968 virtue of being included in the context structure. 970 +==========+=======+======+===========================+=============+ 971 | Name | Label | Type | Algorithm | Description | 972 +==========+=======+======+===========================+=============+ 973 | PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U | 974 | identity | | | direct+HKDF-SHA-512, | identity | 975 | | | | direct+HKDF-AES-128, | information | 976 | | | | direct+HKDF-AES-256, | | 977 | | | | ECDH-ES+HKDF-256, | | 978 | | | | ECDH-ES+HKDF-512, | | 979 | | | | ECDH-SS+HKDF-256, | | 980 | | | | ECDH-SS+HKDF-512, | | 981 | | | | ECDH-ES+A128KW, | | 982 | | | | ECDH-ES+A192KW, | | 983 | | | | ECDH-ES+A256KW, | | 984 | | | | ECDH-SS+A128KW, | | 985 | | | | ECDH-SS+A192KW, | | 986 | | | | ECDH-SS+A256KW | | 987 +----------+-------+------+---------------------------+-------------+ 988 | PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U | 989 | nonce | | / | direct+HKDF-SHA-512, | provided | 990 | | | int | direct+HKDF-AES-128, | nonce | 991 | | | | direct+HKDF-AES-256, | | 992 | | | | ECDH-ES+HKDF-256, | | 993 | | | | ECDH-ES+HKDF-512, | | 994 | | | | ECDH-SS+HKDF-256, | | 995 | | | | ECDH-SS+HKDF-512, | | 996 | | | | ECDH-ES+A128KW, | | 997 | | | | ECDH-ES+A192KW, | | 998 | | | | ECDH-ES+A256KW, | | 999 | | | | ECDH-SS+A128KW, | | 1000 | | | | ECDH-SS+A192KW, | | 1001 | | | | ECDH-SS+A256KW | | 1002 +----------+-------+------+---------------------------+-------------+ 1003 | PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U | 1004 | other | | | direct+HKDF-SHA-512, | other | 1005 | | | | direct+HKDF-AES-128, | provided | 1006 | | | | direct+HKDF-AES-256, | information | 1007 | | | | ECDH-ES+HKDF-256, | | 1008 | | | | ECDH-ES+HKDF-512, | | 1009 | | | | ECDH-SS+HKDF-256, | | 1010 | | | | ECDH-SS+HKDF-512, | | 1011 | | | | ECDH-ES+A128KW, | | 1012 | | | | ECDH-ES+A192KW, | | 1013 | | | | ECDH-ES+A256KW, | | 1014 | | | | ECDH-SS+A128KW, | | 1015 | | | | ECDH-SS+A192KW, | | 1016 | | | | ECDH-SS+A256KW | | 1017 +----------+-------+------+---------------------------+-------------+ 1018 | PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V | 1019 | identity | | | direct+HKDF-SHA-512, | identity | 1020 | | | | direct+HKDF-AES-128, | information | 1021 | | | | direct+HKDF-AES-256, | | 1022 | | | | ECDH-ES+HKDF-256, | | 1023 | | | | ECDH-ES+HKDF-512, | | 1024 | | | | ECDH-SS+HKDF-256, | | 1025 | | | | ECDH-SS+HKDF-512, | | 1026 | | | | ECDH-ES+A128KW, | | 1027 | | | | ECDH-ES+A192KW, | | 1028 | | | | ECDH-ES+A256KW, | | 1029 | | | | ECDH-SS+A128KW, | | 1030 | | | | ECDH-SS+A192KW, | | 1031 | | | | ECDH-SS+A256KW | | 1032 +----------+-------+------+---------------------------+-------------+ 1033 | PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V | 1034 | nonce | | / | direct+HKDF-SHA-512, | provided | 1035 | | | int | direct+HKDF-AES-128, | nonce | 1036 | | | | direct+HKDF-AES-256, | | 1037 | | | | ECDH-ES+HKDF-256, | | 1038 | | | | ECDH-ES+HKDF-512, | | 1039 | | | | ECDH-SS+HKDF-256, | | 1040 | | | | ECDH-SS+HKDF-512, | | 1041 | | | | ECDH-ES+A128KW, | | 1042 | | | | ECDH-ES+A192KW, | | 1043 | | | | ECDH-ES+A256KW, | | 1044 | | | | ECDH-SS+A128KW, | | 1045 | | | | ECDH-SS+A192KW, | | 1046 | | | | ECDH-SS+A256KW | | 1047 +----------+-------+------+---------------------------+-------------+ 1048 | PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V | 1049 | other | | | direct+HKDF-SHA-512, | other | 1050 | | | | direct+HKDF-AES-128, | provided | 1051 | | | | direct+HKDF-AES-256, | information | 1052 | | | | ECDH-ES+HKDF-256, | | 1053 | | | | ECDH-ES+HKDF-512, | | 1054 | | | | ECDH-SS+HKDF-256, | | 1055 | | | | ECDH-SS+HKDF-512, | | 1056 | | | | ECDH-ES+A128KW, | | 1057 | | | | ECDH-ES+A192KW, | | 1058 | | | | ECDH-ES+A256KW, | | 1059 | | | | ECDH-SS+A128KW, | | 1060 | | | | ECDH-SS+A192KW, | | 1061 | | | | ECDH-SS+A256KW | | 1062 +----------+-------+------+---------------------------+-------------+ 1064 Table 10: Context Algorithm Parameters 1066 We define a CBOR object to hold the context information. This object 1067 is referred to as COSE_KDF_Context. The object is based on a CBOR 1068 array type. The fields in the array are: 1070 AlgorithmID: This field indicates the algorithm for which the key 1071 material will be used. This normally is either a key wrap 1072 algorithm identifier or a content encryption algorithm identifier. 1073 The values are from the "COSE Algorithms" registry. This field is 1074 required to be present. The field exists in the context 1075 information so that a different key is generated for each 1076 algorithm even of all of the other context information is the 1077 same. In practice, this means if algorithm A is broken and thus 1078 finding the key is relatively easy, the key derived for algorithm 1079 B will not be the same as the key derived for algorithm A. 1081 PartyUInfo: This field holds information about party U. The 1082 PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo 1083 are encoded in the order presented below. The elements of the 1084 PartyUInfo array are: 1086 identity: This contains the identity information for party U. 1087 The identities can be assigned in one of two manners. First, a 1088 protocol can assign identities based on roles. For example, 1089 the roles of "client" and "server" may be assigned to different 1090 entities in the protocol. Each entity would then use the 1091 correct label for the data they send or receive. The second 1092 way for a protocol to assign identities is to use a name based 1093 on a naming system (i.e., DNS, X.509 names). 1095 We define an algorithm parameter 'PartyU identity' that can be 1096 used to carry identity information in the message. However, 1097 identity information is often known as part of the protocol and 1098 can thus be inferred rather than made explicit. If identity 1099 information is carried in the message, applications SHOULD have 1100 a way of validating the supplied identity information. The 1101 identity information does not need to be specified and is set 1102 to nil in that case. 1104 nonce: This contains a nonce value. The nonce can either be 1105 implicit from the protocol or be carried as a value in the 1106 unprotected header bucket. 1108 We define an algorithm parameter 'PartyU nonce' that can be 1109 used to carry this value in the message; however, the nonce 1110 value could be determined by the application and the value 1111 determined from elsewhere. 1113 This option does not need to be specified and is set to nil in 1114 that case. 1116 other: This contains other information that is defined by the 1117 protocol. This option does not need to be specified and is set 1118 to nil in that case. 1120 PartyVInfo: This field holds information about party V. The content 1121 of the structure is the same as for the PartyUInfo but for party 1122 V. 1124 SuppPubInfo: This field contains public information that is mutually 1125 known to both parties. 1127 keyDataLength: This is set to the number of bits of the desired 1128 output value. This practice means if algorithm A can use two 1129 different key lengths, the key derived for longer key size will 1130 not contain the key for shorter key size as a prefix. 1132 protected: This field contains the protected parameter field. If 1133 there are no elements in the protected field, then use a zero- 1134 length bstr. 1136 other: This field is for free form data defined by the 1137 application. An example is that an application could define 1138 two different byte strings to be placed here to generate 1139 different keys for a data stream versus a control stream. This 1140 field is optional and will only be present if the application 1141 defines a structure for this information. Applications that 1142 define this SHOULD use CBOR to encode the data so that types 1143 and lengths are correctly included. 1145 SuppPrivInfo: This field contains private information that is 1146 mutually known private information. An example of this 1147 information would be a preexisting shared secret. (This could, 1148 for example, be used in combination with an ECDH key agreement to 1149 provide a secondary proof of identity.) The field is optional and 1150 will only be present if the application defines a structure for 1151 this information. Applications that define this SHOULD use CBOR 1152 to encode the data so that types and lengths are correctly 1153 included. 1155 The following CDDL fragment corresponds to the text above. 1157 PartyInfo = ( 1158 identity : bstr / nil, 1159 nonce : bstr / int / nil, 1160 other : bstr / nil 1161 ) 1163 COSE_KDF_Context = [ 1164 AlgorithmID : int / tstr, 1165 PartyUInfo : [ PartyInfo ], 1166 PartyVInfo : [ PartyInfo ], 1167 SuppPubInfo : [ 1168 keyDataLength : uint, 1169 protected : empty_or_serialized_map, 1170 ? other : bstr 1171 ], 1172 ? SuppPrivInfo : bstr 1173 ] 1175 6. Content Key Distribution Methods 1177 Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic 1178 description of content key distribution methods. This document 1179 defines the identifiers and usage for a number of content key 1180 distribution methods. 1182 6.1. Direct Encryption 1184 Direct encryption algorithm is defined in Section 9.5.1 of 1185 [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in 1186 the COSE_Recipient structure are detailed there. 1188 6.1.1. Direct Key 1190 This recipient algorithm is the simplest; the identified key is 1191 directly used as the key for the next layer down in the message. 1192 There are no algorithm parameters defined for this algorithm. The 1193 algorithm identifier value is assigned in Table 11. 1195 When this algorithm is used, the protected field MUST be zero length. 1196 The key type MUST be 'Symmetric'. 1198 +========+=======+===================+ 1199 | Name | Value | Description | 1200 +========+=======+===================+ 1201 | direct | -6 | Direct use of CEK | 1202 +--------+-------+-------------------+ 1204 Table 11: Direct Key 1206 6.1.1.1. Security Considerations for Direct Key 1208 This recipient algorithm has several potential problems that need to 1209 be considered: 1211 * These keys need to have some method to be regularly updated over 1212 time. All of the content encryption algorithms specified in this 1213 document have limits on how many times a key can be used without 1214 significant loss of security. 1216 * These keys need to be dedicated to a single algorithm. There have 1217 been a number of attacks developed over time when a single key is 1218 used for multiple different algorithms. One example of this is 1219 the use of a single key for both the CBC encryption mode and the 1220 CBC-MAC authentication mode. 1222 * Breaking one message means all messages are broken. If an 1223 adversary succeeds in determining the key for a single message, 1224 then the key for all messages is also determined. 1226 6.1.2. Direct Key with KDF 1228 These recipient algorithms take a common shared secret between the 1229 two parties and applies the HKDF function (Section 5.1), using the 1230 context structure defined in Section 5.2 to transform the shared 1231 secret into the CEK. The 'protected' field can be of non-zero 1232 length. Either the 'salt' parameter of HKDF or the 'PartyU nonce' 1233 parameter of the context structure MUST be present. The salt/nonce 1234 parameter can be generated either randomly or deterministically. The 1235 requirement is that it be a unique value for the shared secret in 1236 question. 1238 If the salt/nonce value is generated randomly, then it is suggested 1239 that the length of the random value be the same length as the output 1240 of the hash function underlying HKDF. While there is no way to 1241 guarantee that it will be unique, there is a high probability that it 1242 will be unique. If the salt/nonce value is generated 1243 deterministically, it can be guaranteed to be unique, and thus there 1244 is no length requirement. 1246 A new IV must be used for each message if the same key is used. The 1247 IV can be modified in a predictable manner, a random manner, or an 1248 unpredictable manner (i.e., encrypting a counter). 1250 The IV used for a key can also be generated from the same HKDF 1251 functionality as the key is generated. If HKDF is used for 1252 generating the IV, the algorithm identifier is set to "IV- 1253 GENERATION". 1255 The set of algorithms defined in this document can be found in 1256 Table 12. 1258 +=====================+=======+==============+=====================+ 1259 | Name | Value | KDF | Description | 1260 +=====================+=======+==============+=====================+ 1261 | direct+HKDF-SHA-256 | -10 | HKDF SHA-256 | Shared secret w/ | 1262 | | | | HKDF and SHA-256 | 1263 +---------------------+-------+--------------+---------------------+ 1264 | direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ | 1265 | | | | HKDF and SHA-512 | 1266 +---------------------+-------+--------------+---------------------+ 1267 | direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ | 1268 | | | MAC-128 | AES-MAC 128-bit key | 1269 +---------------------+-------+--------------+---------------------+ 1270 | direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ | 1271 | | | MAC-256 | AES-MAC 256-bit key | 1272 +---------------------+-------+--------------+---------------------+ 1274 Table 12: Direct Key with KDF 1276 When using a COSE key for this algorithm, the following checks are 1277 made: 1279 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 1281 * If the 'alg' field is present, it MUST match the algorithm being 1282 used. 1284 * If the 'key_ops' field is present, it MUST include 'deriveKey' or 1285 'deriveBits'. 1287 6.1.2.1. Security Considerations for Direct Key with KDF 1289 The shared secret needs to have some method to be regularly updated 1290 over time. The shared secret forms the basis of trust. Although not 1291 used directly, it should still be subject to scheduled rotation. 1293 While these methods do not provide for perfect forward secrecy, as 1294 the same shared secret is used for all of the keys generated, if the 1295 key for any single message is discovered, only the message (or series 1296 of messages) using that derived key are compromised. A new key 1297 derivation step will generate a new key that requires the same amount 1298 of work to get the key. 1300 6.2. Key Wrap 1302 Key wrap is defined in Section 9.5.1 of 1303 [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in 1304 the COSE_Recipient structure is detailed there. 1306 6.2.1. AES Key Wrap 1308 The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm 1309 uses an AES key to wrap a value that is a multiple of 64 bits. As 1310 such, it can be used to wrap a key for any of the content encryption 1311 algorithms defined in this document. The algorithm requires a single 1312 fixed parameter, the initial value. This is fixed to the value 1313 specified in Section 2.2.3.1 of [RFC3394]. There are no public key 1314 parameters that vary on a per-invocation basis. The protected header 1315 bucket MUST be empty. 1317 Keys may be obtained either from a key structure or from a recipient 1318 structure. Implementations encrypting and decrypting MUST validate 1319 that the key type, key length, and algorithm are correct and 1320 appropriate for the entities involved. 1322 When using a COSE key for this algorithm, the following checks are 1323 made: 1325 * The 'kty' field MUST be present, and it MUST be 'Symmetric'. 1327 * If the 'alg' field is present, it MUST match the AES Key Wrap 1328 algorithm being used. 1330 * If the 'key_ops' field is present, it MUST include 'encrypt' or 1331 'wrap key' when encrypting. 1333 * If the 'key_ops' field is present, it MUST include 'decrypt' or 1334 'unwrap key' when decrypting. 1336 +========+=======+==========+=============================+ 1337 | Name | Value | Key Size | Description | 1338 +========+=======+==========+=============================+ 1339 | A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key | 1340 +--------+-------+----------+-----------------------------+ 1341 | A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key | 1342 +--------+-------+----------+-----------------------------+ 1343 | A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key | 1344 +--------+-------+----------+-----------------------------+ 1346 Table 13: AES Key Wrap Algorithm Values 1348 6.2.1.1. Security Considerations for AES-KW 1350 The shared secret needs to have some method to be regularly updated 1351 over time. The shared secret is the basis of trust. 1353 6.3. Direct Key Agreement 1355 Key Transport is defined in Section 9.5.4 of 1356 [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in 1357 the COSE_Recipient structure is detailed there. 1359 6.3.1. Direct ECDH 1361 The mathematics for ECDH can be found in [RFC6090]. In this 1362 document, the algorithm is extended to be used with the two curves 1363 defined in [RFC7748]. 1365 ECDH is parameterized by the following: 1367 * Curve Type/Curve: The curve selected controls not only the size of 1368 the shared secret, but the mathematics for computing the shared 1369 secret. The curve selected also controls how a point in the curve 1370 is represented and what happens for the identity points on the 1371 curve. In this specification, we allow for a number of different 1372 curves to be used. A set of curves are defined in Table 18. 1374 The math used to obtain the computed secret is based on the curve 1375 selected and not on the ECDH algorithm. For this reason, a new 1376 algorithm does not need to be defined for each of the curves. 1378 * Computed Secret to Shared Secret: Once the computed secret is 1379 known, the resulting value needs to be converted to a byte string 1380 to run the KDF. The x-coordinate is used for all of the curves 1381 defined in this document. For curves X25519 and X448, the 1382 resulting value is used directly as it is a byte string of a known 1383 length. For the P-256, P-384, and P-521 curves, the x-coordinate 1384 is run through the I2OSP function defined in [RFC8017], using the 1385 same computation for n as is defined in Section 2.1. 1387 * Ephemeral-Static or Static-Static: The key agreement process may 1388 be done using either a static or an ephemeral key for the sender's 1389 side. When using ephemeral keys, the sender MUST generate a new 1390 ephemeral key for every key agreement operation. The ephemeral 1391 key is placed in the 'ephemeral key' parameter and MUST be present 1392 for all algorithm identifiers that use ephemeral keys. When using 1393 static keys, the sender MUST either generate a new random value or 1394 create a unique value. For the KDFs used, this means either the 1395 'salt' parameter for HKDF (Table 9) or the 'PartyU nonce' 1396 parameter for the context structure (Table 10) MUST be present 1397 (both can be present if desired). The value in the parameter MUST 1398 be unique for the pair of keys being used. It is acceptable to 1399 use a global counter that is incremented for every static-static 1400 operation and use the resulting value. Care must be taken that 1401 the counter is saved to permanent storage in a way to avoid reuse 1402 of that counter value. When using static keys, the static key 1403 should be identified to the recipient. The static key can be 1404 identified either by providing the key ('static key') or by 1405 providing a key identifier for the static key ('static key id'). 1406 Both of these header parameters are defined in Table 15. 1408 * Key Derivation Algorithm: The result of an ECDH key agreement 1409 process does not provide a uniformly random secret. As such, it 1410 needs to be run through a KDF in order to produce a usable key. 1411 Processing the secret through a KDF also allows for the 1412 introduction of context material: how the key is going to be used 1413 and one-time material for static-static key agreement. All of the 1414 algorithms defined in this document use one of the HKDF algorithms 1415 defined in Section 5.1 with the context structure defined in 1416 Section 5.2. 1418 * Key Wrap Algorithm: No key wrap algorithm is used. This is 1419 represented in Table 14 as 'none'. The key size for the context 1420 structure is the content layer encryption algorithm size. 1422 COSE does not have an Ephemeral-Ephemeral version defined. The 1423 reason for this is that COSE is not an online protocol by itself and 1424 thus does not have a method to establish ephemeral secrets on both 1425 sides. The expectation is that a protocol would establish the 1426 secrets for both sides, and then they would be used as static-static 1427 for the purposes of COSE, or that the protocol would generate a 1428 shared secret and a direct encryption would be used. 1430 The set of direct ECDH algorithms defined in this document are found 1431 in Table 14. 1433 +===========+=======+=========+============+======+=================+ 1434 | Name | Value | KDF | Ephemeral- | Key | Description | 1435 | | | | Static | Wrap | | 1436 +===========+=======+=========+============+======+=================+ 1437 | ECDH-ES | -25 | HKDF - | yes | none | ECDH ES w/ HKDF | 1438 | + | | SHA-256 | | | - generate key | 1439 | HKDF-256 | | | | | directly | 1440 +-----------+-------+---------+------------+------+-----------------+ 1441 | ECDH-ES | -26 | HKDF - | yes | none | ECDH ES w/ HKDF | 1442 | + | | SHA-512 | | | - generate key | 1443 | HKDF-512 | | | | | directly | 1444 +-----------+-------+---------+------------+------+-----------------+ 1445 | ECDH-SS | -27 | HKDF - | no | none | ECDH SS w/ HKDF | 1446 | + | | SHA-256 | | | - generate key | 1447 | HKDF-256 | | | | | directly | 1448 +-----------+-------+---------+------------+------+-----------------+ 1449 | ECDH-SS | -28 | HKDF - | no | none | ECDH SS w/ HKDF | 1450 | + | | SHA-512 | | | - generate key | 1451 | HKDF-512 | | | | | directly | 1452 +-----------+-------+---------+------------+------+-----------------+ 1454 Table 14: ECDH Algorithm Values 1456 +===========+=======+==========+===================+=============+ 1457 | Name | Label | Type | Algorithm | Description | 1458 +===========+=======+==========+===================+=============+ 1459 | ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral | 1460 | key | | | ECDH-ES+HKDF-512, | public key | 1461 | | | | ECDH-ES+A128KW, | for the | 1462 | | | | ECDH-ES+A192KW, | sender | 1463 | | | | ECDH-ES+A256KW | | 1464 +-----------+-------+----------+-------------------+-------------+ 1465 | static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static | 1466 | key | | | ECDH-SS+HKDF-512, | public key | 1467 | | | | ECDH-SS+A128KW, | for the | 1468 | | | | ECDH-SS+A192KW, | sender | 1469 | | | | ECDH-SS+A256KW | | 1470 +-----------+-------+----------+-------------------+-------------+ 1471 | static | -3 | bstr | ECDH-SS+HKDF-256, | Static | 1472 | key id | | | ECDH-SS+HKDF-512, | public key | 1473 | | | | ECDH-SS+A128KW, | identifier | 1474 | | | | ECDH-SS+A192KW, | for the | 1475 | | | | ECDH-SS+A256KW | sender | 1476 +-----------+-------+----------+-------------------+-------------+ 1478 Table 15: ECDH Algorithm Parameters 1480 This document defines these algorithms to be used with the curves 1481 P-256, P-384, P-521, X25519, and X448. Implementations MUST verify 1482 that the key type and curve are correct. Different curves are 1483 restricted to different key types. Implementations MUST verify that 1484 the curve and algorithm are appropriate for the entities involved. 1486 When using a COSE key for this algorithm, the following checks are 1487 made: 1489 * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. 1491 * If the 'alg' field is present, it MUST match the key agreement 1492 algorithm being used. 1494 * If the 'key_ops' field is present, it MUST include 'derive key' or 1495 'derive bits' for the private key. 1497 * If the 'key_ops' field is present, it MUST be empty for the public 1498 key. 1500 6.3.1.1. Security Considerations for ECDH 1502 There is a method of checking that points provided from external 1503 entities are valid. For the 'EC2' key format, this can be done by 1504 checking that the x and y values form a point on the curve. For the 1505 'OKP' format, there is no simple way to do point validation. 1507 Consideration was given to requiring that the public keys of both 1508 entities be provided as part of the key derivation process (as 1509 recommended in Section 6.4 of [RFC7748]). This was not done as COSE 1510 is used in a store and forward format rather than in online key 1511 exchange. In order for this to be a problem, either the receiver 1512 public key has to be chosen maliciously or the sender has to be 1513 malicious. In either case, all security evaporates anyway. 1515 A proof of possession of the private key associated with the public 1516 key is recommended when a key is moved from untrusted to trusted 1517 (either by the end user or by the entity that is responsible for 1518 making trust statements on keys). 1520 6.4. Key Agreement with Key Wrap 1522 Key Agreement with Key Wrap is defined in Section 9.5.5 of 1523 [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in 1524 the COSE_Recipient structure are detailed there. 1526 6.4.1. ECDH with Key Wrap 1528 These algorithms are defined in Table 16. 1530 ECDH with Key Agreement is parameterized by the same header 1531 parameters as for ECDH; see Section 6.3.1, with the following 1532 modifications: 1534 * Key Wrap Algorithm: Any of the key wrap algorithms defined in 1535 Section 6.2 are supported. The size of the key used for the key 1536 wrap algorithm is fed into the KDF. The set of identifiers are 1537 found in Table 16. 1539 +=========+=======+=========+============+========+================+ 1540 | Name | Value | KDF | Ephemeral- | Key | Description | 1541 | | | | Static | Wrap | | 1542 +=========+=======+=========+============+========+================+ 1543 | ECDH-ES | -29 | HKDF - | yes | A128KW | ECDH ES w/ | 1544 | + | | SHA-256 | | | Concat KDF and | 1545 | A128KW | | | | | AES Key Wrap | 1546 | | | | | | w/ 128-bit key | 1547 +---------+-------+---------+------------+--------+----------------+ 1548 | ECDH-ES | -30 | HKDF - | yes | A192KW | ECDH ES w/ | 1549 | + | | SHA-256 | | | Concat KDF and | 1550 | A192KW | | | | | AES Key Wrap | 1551 | | | | | | w/ 192-bit key | 1552 +---------+-------+---------+------------+--------+----------------+ 1553 | ECDH-ES | -31 | HKDF - | yes | A256KW | ECDH ES w/ | 1554 | + | | SHA-256 | | | Concat KDF and | 1555 | A256KW | | | | | AES Key Wrap | 1556 | | | | | | w/ 256-bit key | 1557 +---------+-------+---------+------------+--------+----------------+ 1558 | ECDH-SS | -32 | HKDF - | no | A128KW | ECDH SS w/ | 1559 | + | | SHA-256 | | | Concat KDF and | 1560 | A128KW | | | | | AES Key Wrap | 1561 | | | | | | w/ 128-bit key | 1562 +---------+-------+---------+------------+--------+----------------+ 1563 | ECDH-SS | -33 | HKDF - | no | A192KW | ECDH SS w/ | 1564 | + | | SHA-256 | | | Concat KDF and | 1565 | A192KW | | | | | AES Key Wrap | 1566 | | | | | | w/ 192-bit key | 1567 +---------+-------+---------+------------+--------+----------------+ 1568 | ECDH-SS | -34 | HKDF - | no | A256KW | ECDH SS w/ | 1569 | + | | SHA-256 | | | Concat KDF and | 1570 | A256KW | | | | | AES Key Wrap | 1571 | | | | | | w/ 256-bit key | 1572 +---------+-------+---------+------------+--------+----------------+ 1574 Table 16: ECDH Algorithm Values with Key Wrap 1576 When using a COSE key for this algorithm, the following checks are 1577 made: 1579 * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. 1581 * If the 'alg' field is present, it MUST match the key agreement 1582 algorithm being used. 1584 * If the 'key_ops' field is present, it MUST include 'derive key' or 1585 'derive bits' for the private key. 1587 * If the 'key_ops' field is present, it MUST be empty for the public 1588 key. 1590 7. Key Object Parameters 1592 The COSE_Key object defines a way to hold a single key object. It is 1593 still required that the members of individual key types be defined. 1594 This section of the document is where we define an initial set of 1595 members for specific key types. 1597 For each of the key types, we define both public and private members. 1598 The public members are what is transmitted to others for their usage. 1599 Private members allow for the archival of keys by individuals. 1600 However, there are some circumstances in which private keys may be 1601 distributed to entities in a protocol. Examples include: entities 1602 that have poor random number generation, centralized key creation for 1603 multi-cast type operations, and protocols in which a shared secret is 1604 used as a bearer token for authorization purposes. 1606 Key types are identified by the 'kty' member of the COSE_Key object. 1607 In this document, we define four values for the member: 1609 +===========+=======+==========================+ 1610 | Name | Value | Description | 1611 +===========+=======+==========================+ 1612 | OKP | 1 | Octet Key Pair | 1613 +-----------+-------+--------------------------+ 1614 | EC2 | 2 | Elliptic Curve Keys w/ | 1615 | | | x- and y-coordinate pair | 1616 +-----------+-------+--------------------------+ 1617 | Symmetric | 4 | Symmetric Keys | 1618 +-----------+-------+--------------------------+ 1619 | Reserved | 0 | This value is reserved | 1620 +-----------+-------+--------------------------+ 1622 Table 17: Key Type Values 1624 7.1. Elliptic Curve Keys 1626 Two different key structures are defined for elliptic curve keys. 1627 One version uses both an x-coordinate and a y-coordinate, potentially 1628 with point compression ('EC2'). This is the traditional EC point 1629 representation that is used in [RFC5480]. The other version uses 1630 only the x-coordinate as the y-coordinate is either to be recomputed 1631 or not needed for the key agreement operation ('OKP'). 1633 Applications MUST check that the curve and the key type are 1634 consistent and reject a key if they are not. 1636 +=========+=======+==========+====================================+ 1637 | Name | Value | Key Type | Description | 1638 +=========+=======+==========+====================================+ 1639 | P-256 | 1 | EC2 | NIST P-256 also known as secp256r1 | 1640 +---------+-------+----------+------------------------------------+ 1641 | P-384 | 2 | EC2 | NIST P-384 also known as secp384r1 | 1642 +---------+-------+----------+------------------------------------+ 1643 | P-521 | 3 | EC2 | NIST P-521 also known as secp521r1 | 1644 +---------+-------+----------+------------------------------------+ 1645 | X25519 | 4 | OKP | X25519 for use w/ ECDH only | 1646 +---------+-------+----------+------------------------------------+ 1647 | X448 | 5 | OKP | X448 for use w/ ECDH only | 1648 +---------+-------+----------+------------------------------------+ 1649 | Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only | 1650 +---------+-------+----------+------------------------------------+ 1651 | Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only | 1652 +---------+-------+----------+------------------------------------+ 1654 Table 18: Elliptic Curves 1656 7.1.1. Double Coordinate Curves 1658 The traditional way of sending ECs has been to send either both the 1659 x-coordinate and y-coordinate or the x-coordinate and a sign bit for 1660 the y-coordinate. The latter encoding has not been recommended in 1661 the IETF due to potential IPR issues. However, for operations in 1662 constrained environments, the ability to shrink a message by not 1663 sending the y-coordinate is potentially useful. 1665 For EC keys with both coordinates, the 'kty' member is set to 2 1666 (EC2). The key parameters defined in this section are summarized in 1667 Table 19. The members that are defined for this key type are: 1669 crv: This contains an identifier of the curve to be used with the 1670 key. The curves defined in this document for this key type can 1671 be found in Table 18. Other curves may be registered in the 1672 future, and private curves can be used as well. 1674 x: This contains the x-coordinate for the EC point. The integer is 1675 converted to a byte string as defined in [SEC1]. Leading zero 1676 octets MUST be preserved. 1678 y: This contains either the sign bit or the value of the 1679 y-coordinate for the EC point. When encoding the value y, the 1680 integer is converted to an byte string (as defined in [SEC1]) 1681 and encoded as a CBOR bstr. Leading zero octets MUST be 1682 preserved. The compressed point encoding is also supported. 1683 Compute the sign bit as laid out in the Elliptic-Curve-Point-to- 1684 Octet-String Conversion function of [SEC1]. If the sign bit is 1685 zero, then encode y as a CBOR false value; otherwise, encode y 1686 as a CBOR true value. The encoding of the infinity point is not 1687 supported. 1689 d: This contains the private key. 1691 For public keys, it is REQUIRED that 'crv', 'x', and 'y' be present 1692 in the structure. For private keys, it is REQUIRED that 'crv' and 1693 'd' be present in the structure. For private keys, it is RECOMMENDED 1694 that 'x' and 'y' also be present, but they can be recomputed from the 1695 required elements and omitting them saves on space. 1697 +======+======+=======+========+=================================+ 1698 | Key | Name | Label | CBOR | Description | 1699 | Type | | | Type | | 1700 +======+======+=======+========+=================================+ 1701 | 2 | crv | -1 | int / | EC identifier - Taken from the | 1702 | | | | tstr | "COSE Elliptic Curves" registry | 1703 +------+------+-------+--------+---------------------------------+ 1704 | 2 | x | -2 | bstr | x-coordinate | 1705 +------+------+-------+--------+---------------------------------+ 1706 | 2 | y | -3 | bstr / | y-coordinate | 1707 | | | | bool | | 1708 +------+------+-------+--------+---------------------------------+ 1709 | 2 | d | -4 | bstr | Private key | 1710 +------+------+-------+--------+---------------------------------+ 1712 Table 19: EC Key Parameters 1714 7.2. Octet Key Pair 1716 A new key type is defined for Octet Key Pairs (OKP). Do not assume 1717 that keys using this type are elliptic curves. This key type could 1718 be used for other curve types (for example, mathematics based on 1719 hyper-elliptic surfaces). 1721 The key parameters defined in this section are summarized in 1722 Table 20. The members that are defined for this key type are: 1724 crv: This contains an identifier of the curve to be used with the 1725 key. The curves defined in this document for this key type can 1726 be found in Table 18. Other curves may be registered in the 1727 future and private curves can be used as well. 1729 x: This contains the public key. The byte string contains the 1730 public key as defined by the algorithm. (For X25519, internally 1731 it is a little-endian integer.) 1733 d: This contains the private key. 1735 For public keys, it is REQUIRED that 'crv' and 'x' be present in the 1736 structure. For private keys, it is REQUIRED that 'crv' and 'd' be 1737 present in the structure. For private keys, it is RECOMMENDED that 1738 'x' also be present, but it can be recomputed from the required 1739 elements and omitting it saves on space. 1741 +======+==========+=======+=======+=================================+ 1742 | Name | Key | Label | Type | Description | 1743 | | Type | | | | 1744 +======+==========+=======+=======+=================================+ 1745 | crv | 1 | -1 | int / | EC identifier - Taken from the | 1746 | | | | tstr | "COSE Elliptic Curves" registry | 1747 +------+----------+-------+-------+---------------------------------+ 1748 | x | 1 | -2 | bstr | Public Key | 1749 +------+----------+-------+-------+---------------------------------+ 1750 | d | 1 | -4 | bstr | Private key | 1751 +------+----------+-------+-------+---------------------------------+ 1753 Table 20: Octet Key Pair Parameters 1755 7.3. Symmetric Keys 1757 Occasionally it is required that a symmetric key be transported 1758 between entities. This key structure allows for that to happen. 1760 For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The 1761 member that is defined for this key type is: 1763 k: This contains the value of the key. 1765 This key structure does not have a form that contains only public 1766 members. As it is expected that this key structure is going to be 1767 transmitted, care must be taken that it is never transmitted 1768 accidentally or insecurely. For symmetric keys, it is REQUIRED that 1769 'k' be present in the structure. 1771 +======+==========+=======+======+=============+ 1772 | Name | Key Type | Label | Type | Description | 1773 +======+==========+=======+======+=============+ 1774 | k | 4 | -1 | bstr | Key Value | 1775 +------+----------+-------+------+-------------+ 1777 Table 21: Symmetric Key Parameters 1779 8. COSE Capabilities 1781 There are some situations that have been identified where 1782 identification of capabilities of an algorithm or a key type need to 1783 be specified. One example of this is in 1784 [I-D.ietf-core-oscore-groupcomm] where the capabilities of the 1785 counter signature algorithm are mixed into the traffic key derivation 1786 process. This has a counterpart in the S/MIME specifications where 1787 SMIMECapabilities is defined in Section 2.5a.2 of [RFC8551]. This 1788 document defines the same concept for COSE. 1790 The algorithm identifier is not included in the capabilities data as 1791 it should be encoded elsewhere in the message. The key type 1792 identifier is included in the capabilities data as it is not expected 1793 to be encoded elsewhere. 1795 Two different types of capabilities are defined: capabilities for 1796 algorithms and capabilities for key type. Once defined by 1797 registration with IANA, the list of capabilities for an algorithm or 1798 key type is immutable. If it is later found that a new capability is 1799 needed for a key type or an algorithm, it will require that a new 1800 code point be assigned to deal with that. As a general rule, the 1801 capabilities are going to map to algorithm-specific header parameters 1802 or key parameters, but they do not need to do so. An example of this 1803 is the HSS-LMS key capabilities defined below where the hash 1804 algorithm used is included. 1806 The capability structure is an array of values, the values included 1807 in the structure are dependent on a specific algorithm or key type. 1808 For algorithm capabilities, the first element should always be a key 1809 type value if applicable, but the items that are specific to a key 1810 (for example a curve) should not be included in the algorithm 1811 capabilities. This means that if one wishes to enumerate all of the 1812 capabilities for a device which implements ECDH, it requires that all 1813 of the combinations of algorithms and key pairs to be specified. The 1814 last example of Section 8.3 provides a case where this is done by 1815 allowing for a cross product to be specified between an array of 1816 algorithm capabilities and key type capabilities (see ECDH-ES+A25KW 1817 element). For a key, the first element should be the key type value. 1818 While this means that the key type value will be duplicated if both 1819 an algorithm and key capability are used, the key type is needed in 1820 order to understand the rest of the values. 1822 8.1. Assignments for Existing Algorithms 1824 For the current set of algorithms in the registry, those in this 1825 document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig], 1826 the capabilities list is an array with one element, the key type 1827 (from the "COSE Key Types" Registry). It is expected that future 1828 registered algorithms could have zero, one, or multiple elements. 1830 8.2. Assignments for Existing Key Types 1832 There are a number of pre-existing key types, the following deals 1833 with creating the capability definition for those structures: 1835 * OKP, EC2: The list of capabilities is: 1837 - The key type value. (1 for OKP or 2 for EC2.) 1839 - One curve for that key type from the "COSE Elliptic Curve" 1840 registry. 1842 * RSA: The list of capabilities is: 1844 - The key type value (3). 1846 * Symmetric: The list of capabilities is: 1848 - The key type value (4). 1850 * HSS-LMS: The list of capabilities is: 1852 - The key type value (5), 1854 - Algorithm identifier for the underlying hash function from the 1855 "COSE Algorithms" registry. 1857 8.3. Examples 1859 Capabilities can be use in a key derivation process to make sure that 1860 both sides are using the same parameters. This is the approach that 1861 is being used by the group communication KDF in 1862 [I-D.ietf-core-oscore-groupcomm]. The three examples below show 1863 different ways that one might include things: 1865 * Just an algorithm capability: This is useful if the protocol wants 1866 to require a specific algorithm such as ECDSA, but it is agnostic 1867 about which curve is being used. This does require that the 1868 algorithm identifier be specified in the protocol. See the first 1869 example. 1871 * Just a key type capability: This is useful if the protccol wants 1872 to require a specific a specific key type and curve, such as 1873 P-256, but will accept any algorithm using that curve (e.g. both 1874 ECDSA and ECDH). See the second example. 1876 * Both an algorithm and a key type capability: This is used if the 1877 protocol needs to nail down all of the options surrounding an 1878 algorithm E.g. EdDSA with the curve X25519. As with the first 1879 example, the algorithm identifier needs to be specified in the 1880 protocol. See the third example which just concatenates the two 1881 capabilities together. 1883 Algorithm ECDSA 1885 0x8102 / [2 \ EC2 \ ] / 1887 Key type EC2 with P-256 curve: 1889 0x820201 / [2 \ EC2 \, 1 \ P-256 \] / 1891 ECDH-ES + A256KW with an X25519 curve: 1893 0x8101820104 / [1 \ OKP \],[1 \ OKP \, 4 \ X25519 \] / 1895 The capabilities can also be used by and entity to advertise what it 1896 is capabable of doing. The decoded example below is one of many 1897 encoding that could be used for that purpose. Each array element 1898 includes three fields: the algorithm identifier, one or more 1899 algorithm capabilities, and one or more key type capabilities. 1901 [ 1902 [-8 / EdDSA /, 1903 [1 / OKP key type /], 1904 [ 1905 [1 / OKP /, 6 / Ed25519 / ], 1906 [1 /OKP/, 7 /Ed448 /] 1907 ] 1908 ], 1909 [-7 / ECDSA with SHA-256/, 1910 [2 /EC2 key type/], 1911 [ 1912 [2 /EC2/, 1 /P-256/], 1913 [2 /EC2/, 3 /P-521/] 1914 ] 1915 ], 1916 [ -31 / ECDH-ES+A256KW/, 1917 [ 1918 [ 2 /EC2/], 1919 [1 /OKP/ ] 1920 ], 1921 [ 1922 [2 /EC2/, 1 /P-256/], 1923 [1 /OKP/, 4 / X25519/ ] 1924 ] 1925 ], 1926 [ 1 / A128GCM /, 1927 [ 4 / Symmetric / ], 1928 [ 4 / Symmetric /] 1929 ] 1930 ] 1932 Examining the above: 1934 * The first element indicates that the entity supports EdDSA with 1935 curves Ed25519 and Ed448. 1937 * The second element indicates that the entity supports ECDSA with 1938 curves P-256 and P-521. 1940 * The third element indicates that the entity support ephemeral- 1941 static ECDH using AES256 key wrap. The entity can support the 1942 P-256 curve with an EC2 key type and the X25519 curve with an OKP 1943 key type. 1945 * The last element indicates that the entity supports AES-GCM of 128 1946 bits for content encryption. 1948 The entity does not advertise that it supports any MAC algorithms. 1950 9. CBOR Encoding Restrictions 1952 This document limits the restrictions it imposes on how the CBOR 1953 Encoder needs to work. It has been narrowed down to the following 1954 restrictions: 1956 * The restriction applies to the encoding of the COSE_KDF_Context. 1958 * Encoding MUST be done using definite lengths and the length of the 1959 MUST be the minimum possible length. This means that the integer 1960 1 is encoded as "0x01" and not "0x1801". 1962 * Applications MUST NOT generate messages with the same label used 1963 twice as a key in a single map. Applications MUST NOT parse and 1964 process messages with the same label used twice as a key in a 1965 single map. Applications can enforce the parse and process 1966 requirement by using parsers that will fail the parse step or by 1967 using parsers that will pass all keys to the application, and the 1968 application can perform the check for duplicate keys. 1970 10. IANA Considerations 1972 IANA is requested to updte ll COSE registeries except for "COSE 1973 Header Parmeters" and "COSE Key Common Parameters" from [RFC8152] to 1974 [[This document]]. 1976 10.1. Changes to "COSE Key Types" registry. 1978 IANA is requested to create a new column in the "COSE Key Types" 1979 registry. The new column is to be labeled "Capabilities". The new 1980 column is to be populated according the entries in Table 22. 1982 +=======+===========+==========================+ 1983 | Value | Name | Capabilities | 1984 +=======+===========+==========================+ 1985 | 1 | OKP | [kty(1), crv] | 1986 +-------+-----------+--------------------------+ 1987 | 2 | EC2 | [kty(2), crv] | 1988 +-------+-----------+--------------------------+ 1989 | 3 | RSA | [kty(3)] | 1990 +-------+-----------+--------------------------+ 1991 | 4 | Symmetric | [kty(4)] | 1992 +-------+-----------+--------------------------+ 1993 | 5 | HSS-LMS | [kty(5), hash algorithm] | 1994 +-------+-----------+--------------------------+ 1996 Table 22: Key Type Capabilities 1998 10.2. Changes to "COSE Algorithms" registry 2000 IANA is requested to create a new column in the "COSE Algorithms" 2001 registry. The new column is to be labeled "Capabilities". The new 2002 column is populated with "[kty]" for all current, non-provisional, 2003 registrations. It is expected that the documents which define those 2004 algorithms will be expanded to include this registration. If this is 2005 not done then the Designated Expert should be consulted before final 2006 registration for this document is done. 2008 IANA is requested to update the reference column in the "COSE 2009 Algorithms" registry to include [[This Document]] as a reference for 2010 all rows where it is not already present. 2012 IANA is requested to add a new row to the "COSE Algorithms" registry. 2014 +==========+===============+=============+============+=============+ 2015 |Name | Value |Description | Reference | Recommended | 2016 +==========+===============+=============+============+=============+ 2017 |IV | IV-GENERATION |For doing IV | [[THIS | No | 2018 |Generation| |generation | DOCUMENT]] | | 2019 | | |for symmetric| | | 2020 | | |algorithms. | | | 2021 +----------+---------------+-------------+------------+-------------+ 2023 Table 23 2025 The capabilities column for this registration is to be empty. 2027 10.3. Changes to the "COSE Key Type Parameters" registry 2029 IANA is requested to modify the description to "Public Key" for the 2030 line with "Key Type" of 2 and the "Name" of "x". See Table 20 which 2031 has been modified with this change. 2033 10.4. Expert Review Instructions 2035 All of the IANA registries established by [RFC8152] are, at least in 2036 part, defined as expert review. This section gives some general 2037 guidelines for what the experts should be looking for, but they are 2038 being designated as experts for a reason, so they should be given 2039 substantial latitude. 2041 Expert reviewers should take into consideration the following points: 2043 * Point squatting should be discouraged. Reviewers are encouraged 2044 to get sufficient information for registration requests to ensure 2045 that the usage is not going to duplicate one that is already 2046 registered, and that the point is likely to be used in 2047 deployments. The zones tagged as private use are intended for 2048 testing purposes and closed environments; code points in other 2049 ranges should not be assigned for testing. 2051 * Specifications are required for the standards track range of point 2052 assignment. Specifications should exist for specification 2053 required ranges, but early assignment before a specification is 2054 available is considered to be permissible. Specifications are 2055 needed for the first-come, first-serve range if they are expected 2056 to be used outside of closed environments in an interoperable way. 2057 When specifications are not provided, the description provided 2058 needs to have sufficient information to identify what the point is 2059 being used for. 2061 * Experts should take into account the expected usage of fields when 2062 approving point assignment. The fact that there is a range for 2063 standards track documents does not mean that a standards track 2064 document cannot have points assigned outside of that range. The 2065 length of the encoded value should be weighed against how many 2066 code points of that length are left, the size of device it will be 2067 used on, and the number of code points left that encode to that 2068 size. 2070 * When algorithms are registered, vanity registrations should be 2071 discouraged. One way to do this is to require registrations to 2072 provide additional documentation on security analysis of the 2073 algorithm. Another thing that should be considered is requesting 2074 an opinion on the algorithm from the Crypto Forum Research Group 2075 (CFRG). Algorithms that do not meet the security requirements of 2076 the community and the messages structures should not be 2077 registered. 2079 11. Security Considerations 2081 There are a number of security considerations that need to be taken 2082 into account by implementers of this specification. The security 2083 considerations that are specific to an individual algorithm are 2084 placed next to the description of the algorithm. While some 2085 considerations have been highlighted here, additional considerations 2086 may be found in the documents listed in the references. 2088 Implementations need to protect the private key material for any 2089 individuals. There are some cases in this document that need to be 2090 highlighted on this issue. 2092 * Using the same key for two different algorithms can leak 2093 information about the key. It is therefore recommended that keys 2094 be restricted to a single algorithm. 2096 * Use of 'direct' as a recipient algorithm combined with a second 2097 recipient algorithm exposes the direct key to the second 2098 recipient. 2100 * Several of the algorithms in this document have limits on the 2101 number of times that a key can be used without leaking information 2102 about the key. 2104 The use of ECDH and direct plus KDF (with no key wrap) will not 2105 directly lead to the private key being leaked; the one way function 2106 of the KDF will prevent that. There is, however, a different issue 2107 that needs to be addressed. Having two recipients requires that the 2108 CEK be shared between two recipients. The second recipient therefore 2109 has a CEK that was derived from material that can be used for the 2110 weak proof of origin. The second recipient could create a message 2111 using the same CEK and send it to the first recipient; the first 2112 recipient would, for either static-static ECDH or direct plus KDF, 2113 make an assumption that the CEK could be used for proof of origin 2114 even though it is from the wrong entity. If the key wrap step is 2115 added, then no proof of origin is implied and this is not an issue. 2117 Although it has been mentioned before, the use of a single key for 2118 multiple algorithms has been demonstrated in some cases to leak 2119 information about a key, provide the opportunity for attackers to 2120 forge integrity tags, or gain information about encrypted content. 2121 Binding a key to a single algorithm prevents these problems. Key 2122 creators and key consumers are strongly encouraged not only to create 2123 new keys for each different algorithm, but to include that selection 2124 of algorithm in any distribution of key material and strictly enforce 2125 the matching of algorithms in the key structure to algorithms in the 2126 message structure. In addition to checking that algorithms are 2127 correct, the key form needs to be checked as well. Do not use an 2128 'EC2' key where an 'OKP' key is expected. 2130 Before using a key for transmission, or before acting on information 2131 received, a trust decision on a key needs to be made. Is the data or 2132 action something that the entity associated with the key has a right 2133 to see or a right to request? A number of factors are associated 2134 with this trust decision. Some of the ones that are highlighted here 2135 are: 2137 * What are the permissions associated with the key owner? 2139 * Is the cryptographic algorithm acceptable in the current context? 2140 * Have the restrictions associated with the key, such as algorithm 2141 or freshness, been checked and are they correct? 2143 * Is the request something that is reasonable, given the current 2144 state of the application? 2146 * Have any security considerations that are part of the message been 2147 enforced (as specified by the application or 'crit' parameter)? 2149 There are a large number of algorithms presented in this document 2150 that use nonce values. For all of the nonces defined in this 2151 document, there is some type of restriction on the nonce being a 2152 unique value either for a key or for some other conditions. In all 2153 of these cases, there is no known requirement on the nonce being both 2154 unique and unpredictable; under these circumstances, it's reasonable 2155 to use a counter for creation of the nonce. In cases where one wants 2156 the pattern of the nonce to be unpredictable as well as unique, one 2157 can use a key created for that purpose and encrypt the counter to 2158 produce the nonce value. 2160 One area that has been getting exposure is traffic analysis of 2161 encrypted messages based on the length of the message. This 2162 specification does not provide for a uniform method of providing 2163 padding as part of the message structure. An observer can 2164 distinguish between two different messages (for example, 'YES' and 2165 'NO') based on the length for all of the content encryption 2166 algorithms that are defined in this document. This means that it is 2167 up to the applications to document how content padding is to be done 2168 in order to prevent or discourage such analysis. (For example, the 2169 text strings could be defined as 'YES' and 'NO '.) 2171 The analsys done in [I-D.ietf-quic-tls] is based on the number of 2172 records/packets that are sent. This should map well to the number of 2173 messages sent when use COSE so that analysis should hold here as 2174 well. It needs to be noted that the limits are based on the number 2175 of messages, but QUIC and DTLS are always pair-wise based endpoints, 2176 [I-D.ietf-core-oscore-groupcomm] use COSE in a group communication. 2177 Under these circumstances it may be that no one single entity will 2178 see all of the messages that are encrypted an therefore no single 2179 entity can trigger the rekey operation. 2181 12. References 2183 12.1. Normative References 2185 [I-D.ietf-cose-rfc8152bis-struct] 2186 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2187 Structures and Process", Work in Progress, Internet-Draft, 2188 draft-ietf-cose-rfc8152bis-struct-13, 4 September 2020, 2189 . 2192 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2193 Hashing for Message Authentication", RFC 2104, 2194 DOI 10.17487/RFC2104, February 1997, 2195 . 2197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2198 Requirement Levels", BCP 14, RFC 2119, 2199 DOI 10.17487/RFC2119, March 1997, 2200 . 2202 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 2203 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 2204 September 2002, . 2206 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 2207 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2208 2003, . 2210 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2211 Key Derivation Function (HKDF)", RFC 5869, 2212 DOI 10.17487/RFC5869, May 2010, 2213 . 2215 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2216 Curve Cryptography Algorithms", RFC 6090, 2217 DOI 10.17487/RFC6090, February 2011, 2218 . 2220 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 2221 Algorithm (DSA) and Elliptic Curve Digital Signature 2222 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2223 2013, . 2225 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 2226 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2227 October 2013, . 2229 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 2230 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 2231 . 2233 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2234 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2235 2016, . 2237 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2238 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2239 May 2017, . 2241 [AES-GCM] National Institute of Standards and Technology, 2242 "Recommendation for Block Cipher Modes of Operation: 2243 Galois/Counter Mode (GCM) and GMAC", 2244 DOI 10.6028/NIST.SP.800-38D, NIST Special 2245 Publication 800-38D, November 2007, 2246 . 2249 [DSS] National Institute of Standards and Technology, "Digital 2250 Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, 2251 FIPS PUB 186-4, July 2013, 2252 . 2255 [MAC] Menees, A., van Oorschot, P., and S. Vanstone, "Handbook 2256 of Applied Cryptography", 1996. 2258 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 2259 May 2009, . 2261 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2262 Signature Algorithm (EdDSA)", RFC 8032, 2263 DOI 10.17487/RFC8032, January 2017, 2264 . 2266 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 2267 "PKCS #1: RSA Cryptography Specifications Version 2.2", 2268 RFC 8017, DOI 10.17487/RFC8017, November 2016, 2269 . 2271 12.2. Informative References 2273 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2274 Writing an IANA Considerations Section in RFCs", BCP 26, 2275 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2276 . 2278 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2279 Definition Language (CDDL): A Notational Convention to 2280 Express Concise Binary Object Representation (CBOR) and 2281 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2282 June 2019, . 2284 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 2285 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 2286 RFC 4231, DOI 10.17487/RFC4231, December 2005, 2287 . 2289 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 2290 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2291 2006, . 2293 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 2294 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 2295 . 2297 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 2298 "Elliptic Curve Cryptography Subject Public Key 2299 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 2300 . 2302 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 2303 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 2304 RFC 6151, DOI 10.17487/RFC6151, March 2011, 2305 . 2307 [STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2308 Interchange Format", STD 90, RFC 8259, December 2017. 2310 2312 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2313 Application Protocol (CoAP)", RFC 7252, 2314 DOI 10.17487/RFC7252, June 2014, 2315 . 2317 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 2318 DOI 10.17487/RFC7518, May 2015, 2319 . 2321 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2322 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2323 . 2325 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 2326 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 2327 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 2328 April 2019, . 2330 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing 2331 and Encryption (COSE) Messages", RFC 8230, 2332 DOI 10.17487/RFC8230, September 2017, 2333 . 2335 [I-D.ietf-core-oscore-groupcomm] 2336 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2337 "Group OSCORE - Secure Group Communication for CoAP", Work 2338 in Progress, Internet-Draft, draft-ietf-core-oscore- 2339 groupcomm-09, 23 June 2020, . 2342 [I-D.ietf-cose-hash-sig] 2343 Housley, R., "Use of the HSS/LMS Hash-based Signature 2344 Algorithm with CBOR Object Signing and Encryption (COSE)", 2345 Work in Progress, Internet-Draft, draft-ietf-cose-hash- 2346 sig-09, 11 December 2019, 2347 . 2349 [SP800-38d] 2350 Dworkin, M., "Recommendation for Block Cipher Modes of 2351 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 2352 Special Publication 800-38D , November 2007, 2353 . 2356 [SP800-56A] 2357 Barker, E., Chen, L., Roginsky, A., and M. Smid, 2358 "Recommendation for Pair-Wise Key Establishment Schemes 2359 Using Discrete Logarithm Cryptography", 2360 DOI 10.6028/NIST.SP.800-56Ar2, NIST Special Publication 2361 800-56A, Revision 2, May 2013, 2362 . 2365 [GitHub-Examples] 2366 "GitHub Examples of COSE", 2367 . 2369 [I-D.mattsson-cfrg-det-sigs-with-noise] 2370 Mattsson, J., Thormarker, E., and S. Ruohomaa, 2371 "Deterministic ECDSA and EdDSA Signatures with Additional 2372 Randomness", Work in Progress, Internet-Draft, draft- 2373 mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020, 2374 . 2377 [HKDF] Krawczyk, H., "Cryptographic Extraction and Key 2378 Derivation: The HKDF Scheme", 2010, 2379 . 2381 [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust 2382 Channels: Handling Unreliable Networks in the Record 2383 Layers of QUIC and DTLS", February 2020, 2384 . 2387 [I-D.ietf-quic-tls] 2388 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 2389 Work in Progress, Internet-Draft, draft-ietf-quic-tls-30, 2390 9 September 2020, 2391 . 2393 Acknowledgments 2395 This document is a product of the COSE working group of the IETF. 2397 The following individuals are to blame for getting me started on this 2398 project in the first place: Richard Barnes, Matt Miller, and Martin 2399 Thomson. 2401 The initial version of the specification was based to some degree on 2402 the outputs of the JOSE and S/MIME working groups. 2404 The following individuals provided input into the final form of the 2405 document: Carsten Bormann, John Bradley, Brain Campbell, Michael B. 2406 Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and 2407 Göran Selander. 2409 Author's Address 2411 Jim Schaad 2412 August Cellars 2414 Email: ietf@augustcellars.com