draft-ietf-cose-rfc8152bis-algs-10.txt   draft-ietf-cose-rfc8152bis-algs-11.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 26 June 2020 Obsoletes: 8152 (if approved) 1 July 2020
Intended status: Informational Intended status: Informational
Expires: 28 December 2020 Expires: 2 January 2021
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-10 draft-ietf-cose-rfc8152bis-algs-11
Abstract Abstract
Concise Binary Object Representation (CBOR) is a data format designed Concise Binary Object Representation (CBOR) is a data format designed
for small code size and small message size. There is a need for the for small code size and small message size. There is a need for the
ability to have basic security services defined for this data format. ability to have basic security services defined for this data format.
THis document defines a set of algorithms that can be used with the THis document defines a set of algorithms that can be used with the
CBOR Object Signing and Encryption (COSE) protocol RFC XXXX. CBOR Object Signing and Encryption (COSE) protocol RFC XXXX.
Contributing to this document Contributing to this document
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 December 2020. This Internet-Draft will expire on 2 January 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4
1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 4 1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 4
1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4
1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 5 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5
2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Security Considerations . . . . . . . . . . . . . . . 7 2.1.1. Security Considerations for ECDSA . . . . . . . . . . 7
2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 8 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 8
2.2.1. Security Considerations . . . . . . . . . . . . . . . 9 2.2.1. Security Considerations for EdDSA . . . . . . . . . . 9
3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9
3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9 3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9
3.1.1. Security Considerations . . . . . . . . . . . . . . . 11 3.1.1. Security Considerations for HMAC . . . . . . . . . . 11
3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11
3.2.1. Security Considerations . . . . . . . . . . . . . . . 12 3.2.1. Security Considerations AES-CBC_MAC . . . . . . . . . 12
4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12
4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Security Considerations . . . . . . . . . . . . . . . 13 4.1.1. Security Considerations for AES-GCM . . . . . . . . . 13
4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Security Considerations . . . . . . . . . . . . . . . 17 4.2.1. Security Considerations for AES-CCM . . . . . . . . . 17
4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 18 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 18
4.3.1. Security Considerations . . . . . . . . . . . . . . . 19 4.3.1. Security Considerations for ChaCha20/Poly1305 . . . . 19
5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 19 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 19
5.1. HMAC-Based Extract-and-Expand Key Derivation Function 5.1. HMAC-Based Extract-and-Expand Key Derivation Function
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 19 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Context Information Structure . . . . . . . . . . . . . . 21 5.2. Context Information Structure . . . . . . . . . . . . . . 21
6. Content Key Distribution Methods . . . . . . . . . . . . . . 26 6. Content Key Distribution Methods . . . . . . . . . . . . . . 26
6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 27 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 27
6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 27 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 27
6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 28 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 28
6.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 30 6.2.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 6, line 12 skipping to change at page 6, line 12
The use of deterministic ECDSA does not lessen the need to have good The use of deterministic ECDSA does not lessen the need to have good
random number generation when creating the private key. random number generation when creating the private key.
The ECDSA signature algorithm is parameterized with a hash function The ECDSA signature algorithm is parameterized with a hash function
(h). In the event that the length of the hash function output is (h). In the event that the length of the hash function output is
greater than the group of the key, the leftmost bytes of the hash greater than the group of the key, the leftmost bytes of the hash
output are used. output are used.
The algorithms defined in this document can be found in Table 1. The algorithms defined in this document can be found in Table 1.
+-------+-------+---------+------------------+ +=======+=======+=========+==================+
| Name | Value | Hash | Description | | Name | Value | Hash | Description |
+=======+=======+=========+==================+ +=======+=======+=========+==================+
| ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 | | ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 |
+-------+-------+---------+------------------+ +-------+-------+---------+------------------+
| ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 | | ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 |
+-------+-------+---------+------------------+ +-------+-------+---------+------------------+
| ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 | | ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 |
+-------+-------+---------+------------------+ +-------+-------+---------+------------------+
Table 1: ECDSA Algorithm Values Table 1: ECDSA Algorithm Values
skipping to change at page 7, line 16 skipping to change at page 7, line 16
* If the 'alg' field is present, it MUST match the ECDSA signature * If the 'alg' field is present, it MUST match the ECDSA signature
algorithm being used. algorithm being used.
* If the 'key_ops' field is present, it MUST include 'sign' when * If the 'key_ops' field is present, it MUST include 'sign' when
creating an ECDSA signature. creating an ECDSA signature.
* If the 'key_ops' field is present, it MUST include 'verify' when * If the 'key_ops' field is present, it MUST include 'verify' when
verifying an ECDSA signature. verifying an ECDSA signature.
2.1.1. Security Considerations 2.1.1. Security Considerations for ECDSA
The security strength of the signature is no greater than the minimum The security strength of the signature is no greater than the minimum
of the security strength associated with the bit length of the key of the security strength associated with the bit length of the key
and the security strength of the hash function. and the security strength of the hash function.
Note: Use of a deterministic signature technique is a good idea even Note: Use of a deterministic signature technique is a good idea even
when good random number generation exists. Doing so both reduces the when good random number generation exists. Doing so both reduces the
possibility of having the same value of 'k' in two signature possibility of having the same value of 'k' in two signature
operations and allows for reproducible signature values, which helps operations and allows for reproducible signature values, which helps
testing. There have been recent attacks involving faulting the testing. There have been recent attacks involving faulting the
skipping to change at page 8, line 41 skipping to change at page 8, line 41
there does not appear to be a need to be able to do block updates of there does not appear to be a need to be able to do block updates of
the hash, followed by eliminating the message from memory. the hash, followed by eliminating the message from memory.
Applications can provide the same features by defining the content of Applications can provide the same features by defining the content of
the message as a hash value and transporting the COSE object (with the message as a hash value and transporting the COSE object (with
the hash value) and the content as separate items. the hash value) and the content as separate items.
The algorithms defined in this document can be found in Table 2. A The algorithms defined in this document can be found in Table 2. A
single signature algorithm is defined, which can be used for multiple single signature algorithm is defined, which can be used for multiple
curves. curves.
+-------+-------+-------------+ +=======+=======+=============+
| Name | Value | Description | | Name | Value | Description |
+=======+=======+=============+ +=======+=======+=============+
| EdDSA | -8 | EdDSA | | EdDSA | -8 | EdDSA |
+-------+-------+-------------+ +-------+-------+-------------+
Table 2: EdDSA Algorithm Values Table 2: EdDSA Algorithm Values
[RFC8032] describes the method of encoding the signature value. [RFC8032] describes the method of encoding the signature value.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
skipping to change at page 9, line 19 skipping to change at page 9, line 19
for this signature algorithm. for this signature algorithm.
* If the 'alg' field is present, it MUST match 'EdDSA'. * If the 'alg' field is present, it MUST match 'EdDSA'.
* If the 'key_ops' field is present, it MUST include 'sign' when * If the 'key_ops' field is present, it MUST include 'sign' when
creating an EdDSA signature. creating an EdDSA signature.
* If the 'key_ops' field is present, it MUST include 'verify' when * If the 'key_ops' field is present, it MUST include 'verify' when
verifying an EdDSA signature. verifying an EdDSA signature.
2.2.1. Security Considerations 2.2.1. Security Considerations for EdDSA
How public values are computed is not the same when looking at EdDSA How public values are computed is not the same when looking at EdDSA
and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public
key should not be used with the other algorithm. key should not be used with the other algorithm.
If batch signature verification is performed, a well-seeded If batch signature verification is performed, a well-seeded
cryptographic random number generator is REQUIRED (Section 8.2 of cryptographic random number generator is REQUIRED (Section 8.2 of
[RFC8032]). Signing and non-batch signature verification are [RFC8032]). Signing and non-batch signature verification are
deterministic operations and do not need random numbers of any kind. deterministic operations and do not need random numbers of any kind.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
set in [RFC2104]. The length of the authentication tag corresponds set in [RFC2104]. The length of the authentication tag corresponds
to the difficulty of producing a forgery. For use in constrained to the difficulty of producing a forgery. For use in constrained
environments, we define one HMAC algorithm that is truncated. There environments, we define one HMAC algorithm that is truncated. There
are currently no known issues with truncation; however, the security are currently no known issues with truncation; however, the security
strength of the message tag is correspondingly reduced in strength. strength of the message tag is correspondingly reduced in strength.
When truncating, the leftmost tag length bits are kept and When truncating, the leftmost tag length bits are kept and
transmitted. transmitted.
The algorithms defined in this document can be found in Table 3. The algorithms defined in this document can be found in Table 3.
+-------------+-------+---------+------------+----------------------+ +=============+=======+=========+============+======================+
| Name | Value | Hash | Tag Length | Description | | Name | Value | Hash | Tag Length | Description |
+=============+=======+=========+============+======================+ +=============+=======+=========+============+======================+
| HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 | | HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 |
| 256/64 | | | | truncated to 64 bits | | 256/64 | | | | truncated to 64 bits |
+-------------+-------+---------+------------+----------------------+ +-------------+-------+---------+------------+----------------------+
| HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 | | HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 |
| 256/256 | | | | | | 256/256 | | | | |
+-------------+-------+---------+------------+----------------------+ +-------------+-------+---------+------------+----------------------+
| HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 | | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 |
| 384/384 | | | | | | 384/384 | | | | |
skipping to change at page 11, line 5 skipping to change at page 11, line 5
* If the 'key_ops' field is present, it MUST include 'MAC create' * If the 'key_ops' field is present, it MUST include 'MAC create'
when creating an HMAC authentication tag. when creating an HMAC authentication tag.
* If the 'key_ops' field is present, it MUST include 'MAC verify' * If the 'key_ops' field is present, it MUST include 'MAC verify'
when verifying an HMAC authentication tag. when verifying an HMAC authentication tag.
Implementations creating and validating MAC values MUST validate that Implementations creating and validating MAC values MUST validate that
the key type, key length, and algorithm are correct and appropriate the key type, key length, and algorithm are correct and appropriate
for the entities involved. for the entities involved.
3.1.1. Security Considerations 3.1.1. Security Considerations for HMAC
HMAC has proved to be resistant to attack even when used with HMAC has proved to be resistant to attack even when used with
weakened hash algorithms. The current best known attack is to brute weakened hash algorithms. The current best known attack is to brute
force the key. This means that key size is going to be directly force the key. This means that key size is going to be directly
related to the security of an HMAC operation. related to the security of an HMAC operation.
3.2. AES Message Authentication Code (AES-CBC-MAC) 3.2. AES Message Authentication Code (AES-CBC-MAC)
AES-CBC-MAC is defined in [MAC]. (Note that this is not the same AES-CBC-MAC is defined in [MAC]. (Note that this is not the same
algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC)
[RFC4493].) [RFC4493].)
AES-CBC-MAC is parameterized by the key length, the authentication AES-CBC-MAC is parameterized by the key length, the authentication
tag length, and the Initialization Vector (IV) used. For all of tag length, and the Initialization Vector (IV) used. For all of
these algorithms, the IV is fixed to all zeros. We provide an array these algorithms, the IV is fixed to all zeros. We provide an array
of algorithms for various key lengths and tag lengths. The of algorithms for various key lengths and tag lengths. The
algorithms defined in this document are found in Table 4. algorithms defined in this document are found in Table 4.
+---------+-------+------------+------------+------------------+ +=========+=======+============+============+==================+
| Name | Value | Key Length | Tag Length | Description | | Name | Value | Key Length | Tag Length | Description |
+=========+=======+============+============+==================+ +=========+=======+============+============+==================+
| AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit | | AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit |
| 128/64 | | | | key, 64-bit tag | | 128/64 | | | | key, 64-bit tag |
+---------+-------+------------+------------+------------------+ +---------+-------+------------+------------+------------------+
| AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit | | AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit |
| 256/64 | | | | key, 64-bit tag | | 256/64 | | | | key, 64-bit tag |
+---------+-------+------------+------------+------------------+ +---------+-------+------------+------------+------------------+
| AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit | | AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit |
| 128/128 | | | | key, 128-bit tag | | 128/128 | | | | key, 128-bit tag |
skipping to change at page 12, line 14 skipping to change at page 12, line 14
* If the 'alg' field is present, it MUST match the AES-MAC algorithm * If the 'alg' field is present, it MUST match the AES-MAC algorithm
being used. being used.
* If the 'key_ops' field is present, it MUST include 'MAC create' * If the 'key_ops' field is present, it MUST include 'MAC create'
when creating an AES-MAC authentication tag. when creating an AES-MAC authentication tag.
* If the 'key_ops' field is present, it MUST include 'MAC verify' * If the 'key_ops' field is present, it MUST include 'MAC verify'
when verifying an AES-MAC authentication tag. when verifying an AES-MAC authentication tag.
3.2.1. Security Considerations 3.2.1. Security Considerations AES-CBC_MAC
A number of attacks exist against Cipher Block Chaining Message A number of attacks exist against Cipher Block Chaining Message
Authentication Code (CBC-MAC) that need to be considered. Authentication Code (CBC-MAC) that need to be considered.
* A single key must only be used for messages of a fixed or known * A single key must only be used for messages of a fixed or known
length. If this is not the case, an attacker will be able to length. If this is not the case, an attacker will be able to
generate a message with a valid tag given two message and tag generate a message with a valid tag given two message and tag
pairs. This can be addressed by using different keys for messages pairs. This can be addressed by using different keys for messages
of different lengths. The current structure mitigates this of different lengths. The current structure mitigates this
problem, as a specific encoding structure that includes lengths is problem, as a specific encoding structure that includes lengths is
skipping to change at page 13, line 5 skipping to change at page 13, line 5
block encryption algorithm to define an AEAD cipher. block encryption algorithm to define an AEAD cipher.
The GCM mode is parameterized by the size of the authentication tag The GCM mode is parameterized by the size of the authentication tag
and the size of the nonce. This document fixes the size of the nonce and the size of the nonce. This document fixes the size of the nonce
at 96 bits. The size of the authentication tag is limited to a small at 96 bits. The size of the authentication tag is limited to a small
set of values. For this document however, the size of the set of values. For this document however, the size of the
authentication tag is fixed at 128 bits. authentication tag is fixed at 128 bits.
The set of algorithms defined in this document are in Table 5. The set of algorithms defined in this document are in Table 5.
+---------+-------+------------------------------------------+ +=========+=======+==========================================+
| Name | Value | Description | | Name | Value | Description |
+=========+=======+==========================================+ +=========+=======+==========================================+
| A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag | | A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag |
+---------+-------+------------------------------------------+ +---------+-------+------------------------------------------+
| A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag | | A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag |
+---------+-------+------------------------------------------+ +---------+-------+------------------------------------------+
| A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag | | A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag |
+---------+-------+------------------------------------------+ +---------+-------+------------------------------------------+
Table 5: Algorithm Value for AES-GCM Table 5: Algorithm Value for AES-GCM
skipping to change at page 13, line 36 skipping to change at page 13, line 36
* If the 'alg' field is present, it MUST match the AES-GCM algorithm * If the 'alg' field is present, it MUST match the AES-GCM algorithm
being used. being used.
* If the 'key_ops' field is present, it MUST include 'encrypt' or * If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
* If the 'key_ops' field is present, it MUST include 'decrypt' or * If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
4.1.1. Security Considerations 4.1.1. Security Considerations for AES-GCM
When using AES-GCM, the following restrictions MUST be enforced: When using AES-GCM, the following restrictions MUST be enforced:
* The key and nonce pair MUST be unique for every message encrypted. * The key and nonce pair MUST be unique for every message encrypted.
* The total number of messages encrypted for a single key MUST NOT * The total number of messages encrypted for a single key MUST NOT
exceed 2^32 [SP800-38d]. An explicit check is required only in exceed 2^32 [SP800-38d]. An explicit check is required only in
environments where it is expected that it might be exceeded. environments where it is expected that it might be exceeded.
* A more recent analysis in [ROBUST] indicates that the the number * A more recent analysis in [ROBUST] indicates that the the number
skipping to change at page 16, line 5 skipping to change at page 16, line 5
The following values are used for M: The following values are used for M:
64 bits (8): This produces a 64-bit authentication tag. This 64 bits (8): This produces a 64-bit authentication tag. This
implies that there is a 1 in 2^64 chance that a modified message implies that there is a 1 in 2^64 chance that a modified message
will authenticate. will authenticate.
128 bits (16): This produces a 128-bit authentication tag. This 128 bits (16): This produces a 128-bit authentication tag. This
implies that there is a 1 in 2^128 chance that a modified message implies that there is a 1 in 2^128 chance that a modified message
will authenticate. will authenticate.
+--------------------+-------+----+-----+--------+---------------+ +====================+=======+====+=====+========+===============+
| Name | Value | L | M | Key | Description | | Name | Value | L | M | Key | Description |
| | | | | Length | | | | | | | Length | |
+====================+=======+====+=====+========+===============+ +====================+=======+====+=====+========+===============+
| AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode | | AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, | | | | | | | 128-bit key, |
| | | | | | 64-bit tag, | | | | | | | 64-bit tag, |
| | | | | | 13-byte nonce | | | | | | | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+ +--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode | | AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, | | | | | | | 256-bit key, |
skipping to change at page 17, line 24 skipping to change at page 17, line 24
* If the 'alg' field is present, it MUST match the AES-CCM algorithm * If the 'alg' field is present, it MUST match the AES-CCM algorithm
being used. being used.
* If the 'key_ops' field is present, it MUST include 'encrypt' or * If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
* If the 'key_ops' field is present, it MUST include 'decrypt' or * If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
4.2.1. Security Considerations 4.2.1. Security Considerations for AES-CCM
When using AES-CCM, the following restrictions MUST be enforced: When using AES-CCM, the following restrictions MUST be enforced:
* The key and nonce pair MUST be unique for every message encrypted. * The key and nonce pair MUST be unique for every message encrypted.
Note that the value of L influences the number of unique nonces. Note that the value of L influences the number of unique nonces.
* The total number of times the AES block cipher is used MUST NOT * The total number of times the AES block cipher is used MUST NOT
exceed 2^61 operations. This limitation is the sum of times the exceed 2^61 operations. This limitation is the sum of times the
block cipher is used in computing the MAC value and in performing block cipher is used in computing the MAC value and in performing
stream encryption operations. An explicit check is required only stream encryption operations. An explicit check is required only
skipping to change at page 18, line 30 skipping to change at page 18, line 30
that is not AES and thus would not suffer from any future weaknesses that is not AES and thus would not suffer from any future weaknesses
found in AES. These cryptographic functions are designed to be fast found in AES. These cryptographic functions are designed to be fast
in software-only implementations. in software-only implementations.
The ChaCha20/Poly1305 AEAD construction defined in [RFC8439] has no The ChaCha20/Poly1305 AEAD construction defined in [RFC8439] has no
parameterization. It takes a 256-bit key and a 96-bit nonce, as well parameterization. It takes a 256-bit key and a 96-bit nonce, as well
as the plaintext and additional data as inputs and produces the as the plaintext and additional data as inputs and produces the
ciphertext as an option. We define one algorithm identifier for this ciphertext as an option. We define one algorithm identifier for this
algorithm in Table 7. algorithm in Table 7.
+-------------------+-------+--------------------------+ +===================+=======+==========================+
| Name | Value | Description | | Name | Value | Description |
+===================+=======+==========================+ +===================+=======+==========================+
| ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ | | ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ |
| | | 256-bit key, 128-bit tag | | | | 256-bit key, 128-bit tag |
+-------------------+-------+--------------------------+ +-------------------+-------+--------------------------+
Table 7: Algorithm Value for ChaCha20/Poly1305 Table 7: Algorithm Value for ChaCha20/Poly1305
Keys may be obtained either from a key structure or from a recipient Keys may be obtained either from a key structure or from a recipient
structure. Implementations encrypting and decrypting MUST validate structure. Implementations encrypting and decrypting MUST validate
skipping to change at page 19, line 11 skipping to change at page 19, line 11
* If the 'alg' field is present, it MUST match the ChaCha20/Poly1305 * If the 'alg' field is present, it MUST match the ChaCha20/Poly1305
algorithm being used. algorithm being used.
* If the 'key_ops' field is present, it MUST include 'encrypt' or * If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
* If the 'key_ops' field is present, it MUST include 'decrypt' or * If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
4.3.1. Security Considerations 4.3.1. Security Considerations for ChaCha20/Poly1305
The key and nonce values MUST be a unique pair for every invocation The key and nonce values MUST be a unique pair for every invocation
of the algorithm. Nonce counters are considered to be an acceptable of the algorithm. Nonce counters are considered to be an acceptable
way of ensuring that they are unique. way of ensuring that they are unique.
A more recent analysis in [ROBUST] indicates that the the number of A more recent analysis in [ROBUST] indicates that the the number of
failed decryptions needs to be taken into account as part determining failed decryptions needs to be taken into account as part determining
when a key roll-over is to be done. Following the recommendation of when a key roll-over is to be done. Following the recommendation of
for DTLS, the number of failed message decryptions should be limited for DTLS, the number of failed message decryptions should be limited
to 2^36. to 2^36.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
algorithm versions, the extract step is always skipped. algorithm versions, the extract step is always skipped.
The extract step cannot be skipped if the secret is not uniformly The extract step cannot be skipped if the secret is not uniformly
random, for example, if it is the result of an ECDH key agreement random, for example, if it is the result of an ECDH key agreement
step. This implies that the AES HKDF version cannot be used with step. This implies that the AES HKDF version cannot be used with
ECDH. If the extract step is skipped, the 'salt' value is not used ECDH. If the extract step is skipped, the 'salt' value is not used
as part of the HKDF functionality. as part of the HKDF functionality.
The algorithms defined in this document are found in Table 8. The algorithms defined in this document are found in Table 8.
+--------------+-------------------+------------------------+ +==============+===================+========================+
| Name | PRF | Description | | Name | PRF | Description |
+==============+===================+========================+ +==============+===================+========================+
| HKDF SHA-256 | HMAC with SHA-256 | HKDF using HMAC | | HKDF SHA-256 | HMAC with SHA-256 | HKDF using HMAC |
| | | SHA-256 as the PRF | | | | SHA-256 as the PRF |
+--------------+-------------------+------------------------+ +--------------+-------------------+------------------------+
| HKDF SHA-512 | HMAC with SHA-512 | HKDF using HMAC | | HKDF SHA-512 | HMAC with SHA-512 | HKDF using HMAC |
| | | SHA-512 as the PRF | | | | SHA-512 as the PRF |
+--------------+-------------------+------------------------+ +--------------+-------------------+------------------------+
| HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as | | HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as |
| MAC-128 | | the PRF w/ 128-bit key | | MAC-128 | | the PRF w/ 128-bit key |
+--------------+-------------------+------------------------+ +--------------+-------------------+------------------------+
| HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as | | HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as |
| MAC-256 | | the PRF w/ 256-bit key | | MAC-256 | | the PRF w/ 256-bit key |
+--------------+-------------------+------------------------+ +--------------+-------------------+------------------------+
Table 8: HKDF Algorithms Table 8: HKDF Algorithms
+------+-------+------+----------------------------+-------------+ +======+=======+======+============================+=============+
| Name | Label | Type | Algorithm | Description | | Name | Label | Type | Algorithm | Description |
+======+=======+======+============================+=============+ +======+=======+======+============================+=============+
| salt | -20 | bstr | direct+HKDF-SHA-256, | Random salt | | salt | -20 | bstr | direct+HKDF-SHA-256, | Random salt |
| | | | direct+HKDF-SHA-512, | | | | | | direct+HKDF-SHA-512, | |
| | | | direct+HKDF-AES-128, | | | | | | direct+HKDF-AES-128, | |
| | | | direct+HKDF-AES-256, ECDH- | | | | | | direct+HKDF-AES-256, ECDH- | |
| | | | ES+HKDF-256, ECDH-ES+HKDF- | | | | | | ES+HKDF-256, ECDH-ES+HKDF- | |
| | | | 512, ECDH-SS+HKDF-256, | | | | | | 512, ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, ECDH- | | | | | | ECDH-SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH-ES+A192KW, | | | | | | ES+A128KW, ECDH-ES+A192KW, | |
skipping to change at page 22, line 33 skipping to change at page 22, line 33
* Fields can be defined by parameters from the message. We define a * Fields can be defined by parameters from the message. We define a
set of header parameters in Table 10 that can be used to carry the set of header parameters in Table 10 that can be used to carry the
values associated with the context structure. Examples of this values associated with the context structure. Examples of this
are identities and nonce values. These header parameters are are identities and nonce values. These header parameters are
designed to be placed in the unprotected bucket of the recipient designed to be placed in the unprotected bucket of the recipient
structure; they do not need to be in the protected bucket since structure; they do not need to be in the protected bucket since
they already are included in the cryptographic computation by they already are included in the cryptographic computation by
virtue of being included in the context structure. virtue of being included in the context structure.
+----------+-------+------+---------------------------+-------------+ +==========+=======+======+===========================+=============+
| Name | Label | Type | Algorithm | Description | | Name | Label | Type | Algorithm | Description |
+==========+=======+======+===========================+=============+ +==========+=======+======+===========================+=============+
| PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U | | PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U |
| identity | | | direct+HKDF-SHA-512, | identity | | identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information | | | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | | | | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, | | | | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | | | | | | ECDH-ES+HKDF-512, | |
| | | | ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-256, | |
| | | | ECDH-SS+HKDF-512, | | | | | | ECDH-SS+HKDF-512, | |
skipping to change at page 27, line 21 skipping to change at page 27, line 21
6.1.1. Direct Key 6.1.1. Direct Key
This recipient algorithm is the simplest; the identified key is This recipient algorithm is the simplest; the identified key is
directly used as the key for the next layer down in the message. directly used as the key for the next layer down in the message.
There are no algorithm parameters defined for this algorithm. The There are no algorithm parameters defined for this algorithm. The
algorithm identifier value is assigned in Table 11. algorithm identifier value is assigned in Table 11.
When this algorithm is used, the protected field MUST be zero length. When this algorithm is used, the protected field MUST be zero length.
The key type MUST be 'Symmetric'. The key type MUST be 'Symmetric'.
+--------+-------+-------------------+ +========+=======+===================+
| Name | Value | Description | | Name | Value | Description |
+========+=======+===================+ +========+=======+===================+
| direct | -6 | Direct use of CEK | | direct | -6 | Direct use of CEK |
+--------+-------+-------------------+ +--------+-------+-------------------+
Table 11: Direct Key Table 11: Direct Key
6.1.1.1. Security Considerations 6.1.1.1. Security Considerations for Direct Key
This recipient algorithm has several potential problems that need to This recipient algorithm has several potential problems that need to
be considered: be considered:
* These keys need to have some method to be regularly updated over * These keys need to have some method to be regularly updated over
time. All of the content encryption algorithms specified in this time. All of the content encryption algorithms specified in this
document have limits on how many times a key can be used without document have limits on how many times a key can be used without
significant loss of security. significant loss of security.
* These keys need to be dedicated to a single algorithm. There have * These keys need to be dedicated to a single algorithm. There have
skipping to change at page 29, line 5 skipping to change at page 29, line 5
unpredictable manner (i.e., encrypting a counter). unpredictable manner (i.e., encrypting a counter).
The IV used for a key can also be generated from the same HKDF The IV used for a key can also be generated from the same HKDF
functionality as the key is generated. If HKDF is used for functionality as the key is generated. If HKDF is used for
generating the IV, the algorithm identifier is set to "IV- generating the IV, the algorithm identifier is set to "IV-
GENERATION". GENERATION".
The set of algorithms defined in this document can be found in The set of algorithms defined in this document can be found in
Table 12. Table 12.
+---------------------+-------+--------------+---------------------+ +=====================+=======+==============+=====================+
| Name | Value | KDF | Description | | Name | Value | KDF | Description |
+=====================+=======+==============+=====================+ +=====================+=======+==============+=====================+
| direct+HKDF-SHA-256 | -10 | HKDF SHA-256 | Shared secret w/ | | direct+HKDF-SHA-256 | -10 | HKDF SHA-256 | Shared secret w/ |
| | | | HKDF and SHA-256 | | | | | HKDF and SHA-256 |
+---------------------+-------+--------------+---------------------+ +---------------------+-------+--------------+---------------------+
| direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ | | direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ |
| | | | HKDF and SHA-512 | | | | | HKDF and SHA-512 |
+---------------------+-------+--------------+---------------------+ +---------------------+-------+--------------+---------------------+
| direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ | | direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ |
| | | MAC-128 | AES-MAC 128-bit key | | | | MAC-128 | AES-MAC 128-bit key |
skipping to change at page 29, line 34 skipping to change at page 29, line 34
made: made:
* The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
* If the 'alg' field is present, it MUST match the algorithm being * If the 'alg' field is present, it MUST match the algorithm being
used. used.
* If the 'key_ops' field is present, it MUST include 'deriveKey' or * If the 'key_ops' field is present, it MUST include 'deriveKey' or
'deriveBits'. 'deriveBits'.
6.1.2.1. Security Considerations 6.1.2.1. Security Considerations for Direct Key with KDF
The shared secret needs to have some method to be regularly updated The shared secret needs to have some method to be regularly updated
over time. The shared secret forms the basis of trust. Although not over time. The shared secret forms the basis of trust. Although not
used directly, it should still be subject to scheduled rotation. used directly, it should still be subject to scheduled rotation.
While these methods do not provide for perfect forward secrecy, as While these methods do not provide for perfect forward secrecy, as
the same shared secret is used for all of the keys generated, if the the same shared secret is used for all of the keys generated, if the
key for any single message is discovered, only the message (or series key for any single message is discovered, only the message (or series
of messages) using that derived key are compromised. A new key of messages) using that derived key are compromised. A new key
derivation step will generate a new key that requires the same amount derivation step will generate a new key that requires the same amount
skipping to change at page 30, line 35 skipping to change at page 30, line 35
* If the 'alg' field is present, it MUST match the AES Key Wrap * If the 'alg' field is present, it MUST match the AES Key Wrap
algorithm being used. algorithm being used.
* If the 'key_ops' field is present, it MUST include 'encrypt' or * If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
* If the 'key_ops' field is present, it MUST include 'decrypt' or * If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
+--------+-------+----------+-----------------------------+ +========+=======+==========+=============================+
| Name | Value | Key Size | Description | | Name | Value | Key Size | Description |
+========+=======+==========+=============================+ +========+=======+==========+=============================+
| A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key | | A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key |
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
| A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key | | A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key |
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
| A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key | | A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key |
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
Table 13: AES Key Wrap Algorithm Values Table 13: AES Key Wrap Algorithm Values
skipping to change at page 33, line 5 skipping to change at page 33, line 5
reason for this is that COSE is not an online protocol by itself and reason for this is that COSE is not an online protocol by itself and
thus does not have a method to establish ephemeral secrets on both thus does not have a method to establish ephemeral secrets on both
sides. The expectation is that a protocol would establish the sides. The expectation is that a protocol would establish the
secrets for both sides, and then they would be used as static-static secrets for both sides, and then they would be used as static-static
for the purposes of COSE, or that the protocol would generate a for the purposes of COSE, or that the protocol would generate a
shared secret and a direct encryption would be used. shared secret and a direct encryption would be used.
The set of direct ECDH algorithms defined in this document are found The set of direct ECDH algorithms defined in this document are found
in Table 14. in Table 14.
+-----------+-------+---------+------------+------+-----------------+ +===========+=======+=========+============+======+=================+
| Name | Value | KDF | Ephemeral- | Key | Description | | Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | | | | | | Static | Wrap | |
+===========+=======+=========+============+======+=================+ +===========+=======+=========+============+======+=================+
| ECDH-ES | -25 | HKDF - | yes | none | ECDH ES w/ HKDF | | ECDH-ES | -25 | HKDF - | yes | none | ECDH ES w/ HKDF |
| + | | SHA-256 | | | - generate key | | + | | SHA-256 | | | - generate key |
| HKDF-256 | | | | | directly | | HKDF-256 | | | | | directly |
+-----------+-------+---------+------------+------+-----------------+ +-----------+-------+---------+------------+------+-----------------+
| ECDH-ES | -26 | HKDF - | yes | none | ECDH ES w/ HKDF | | ECDH-ES | -26 | HKDF - | yes | none | ECDH ES w/ HKDF |
| + | | SHA-512 | | | - generate key | | + | | SHA-512 | | | - generate key |
| HKDF-512 | | | | | directly | | HKDF-512 | | | | | directly |
skipping to change at page 33, line 28 skipping to change at page 33, line 28
| + | | SHA-256 | | | - generate key | | + | | SHA-256 | | | - generate key |
| HKDF-256 | | | | | directly | | HKDF-256 | | | | | directly |
+-----------+-------+---------+------------+------+-----------------+ +-----------+-------+---------+------------+------+-----------------+
| ECDH-SS | -28 | HKDF - | no | none | ECDH SS w/ HKDF | | ECDH-SS | -28 | HKDF - | no | none | ECDH SS w/ HKDF |
| + | | SHA-512 | | | - generate key | | + | | SHA-512 | | | - generate key |
| HKDF-512 | | | | | directly | | HKDF-512 | | | | | directly |
+-----------+-------+---------+------------+------+-----------------+ +-----------+-------+---------+------------+------+-----------------+
Table 14: ECDH Algorithm Values Table 14: ECDH Algorithm Values
+-----------+-------+----------+-------------------+-------------+ +===========+=======+==========+===================+=============+
| Name | Label | Type | Algorithm | Description | | Name | Label | Type | Algorithm | Description |
+===========+=======+==========+===================+=============+ +===========+=======+==========+===================+=============+
| ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral | | ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral |
| key | | | ECDH-ES+HKDF-512, | public key | | key | | | ECDH-ES+HKDF-512, | public key |
| | | | ECDH-ES+A128KW, | for the | | | | | ECDH-ES+A128KW, | for the |
| | | | ECDH-ES+A192KW, | sender | | | | | ECDH-ES+A192KW, | sender |
| | | | ECDH-ES+A256KW | | | | | | ECDH-ES+A256KW | |
+-----------+-------+----------+-------------------+-------------+ +-----------+-------+----------+-------------------+-------------+
| static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static | | static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static |
| key | | | ECDH-SS+HKDF-512, | public key | | key | | | ECDH-SS+HKDF-512, | public key |
skipping to change at page 34, line 25 skipping to change at page 34, line 25
* If the 'alg' field is present, it MUST match the key agreement * If the 'alg' field is present, it MUST match the key agreement
algorithm being used. algorithm being used.
* If the 'key_ops' field is present, it MUST include 'derive key' or * If the 'key_ops' field is present, it MUST include 'derive key' or
'derive bits' for the private key. 'derive bits' for the private key.
* If the 'key_ops' field is present, it MUST be empty for the public * If the 'key_ops' field is present, it MUST be empty for the public
key. key.
6.3.1.1. Security Considerations 6.3.1.1. Security Considerations for ECDH
There is a method of checking that points provided from external There is a method of checking that points provided from external
entities are valid. For the 'EC2' key format, this can be done by entities are valid. For the 'EC2' key format, this can be done by
checking that the x and y values form a point on the curve. For the checking that the x and y values form a point on the curve. For the
'OKP' format, there is no simple way to do point validation. 'OKP' format, there is no simple way to do point validation.
Consideration was given to requiring that the public keys of both Consideration was given to requiring that the public keys of both
entities be provided as part of the key derivation process (as entities be provided as part of the key derivation process (as
recommended in Section 6.4 of [RFC7748]). This was not done as COSE recommended in Section 6.4 of [RFC7748]). This was not done as COSE
is used in a store and forward format rather than in online key is used in a store and forward format rather than in online key
skipping to change at page 36, line 5 skipping to change at page 36, line 5
ECDH with Key Agreement is parameterized by the same header ECDH with Key Agreement is parameterized by the same header
parameters as for ECDH; see Section 6.3.1, with the following parameters as for ECDH; see Section 6.3.1, with the following
modifications: modifications:
* Key Wrap Algorithm: Any of the key wrap algorithms defined in * Key Wrap Algorithm: Any of the key wrap algorithms defined in
Section 6.2 are supported. The size of the key used for the key Section 6.2 are supported. The size of the key used for the key
wrap algorithm is fed into the KDF. The set of identifiers are wrap algorithm is fed into the KDF. The set of identifiers are
found in Table 16. found in Table 16.
+---------+-------+---------+------------+--------+----------------+ +=========+=======+=========+============+========+================+
| Name | Value | KDF | Ephemeral- | Key | Description | | Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | | | | | | Static | Wrap | |
+=========+=======+=========+============+========+================+ +=========+=======+=========+============+========+================+
| ECDH-ES | -29 | HKDF - | yes | A128KW | ECDH ES w/ | | ECDH-ES | -29 | HKDF - | yes | A128KW | ECDH ES w/ |
| + | | SHA-256 | | | Concat KDF and | | + | | SHA-256 | | | Concat KDF and |
| A128KW | | | | | AES Key Wrap | | A128KW | | | | | AES Key Wrap |
| | | | | | w/ 128-bit key | | | | | | | w/ 128-bit key |
+---------+-------+---------+------------+--------+----------------+ +---------+-------+---------+------------+--------+----------------+
| ECDH-ES | -30 | HKDF - | yes | A192KW | ECDH ES w/ | | ECDH-ES | -30 | HKDF - | yes | A192KW | ECDH ES w/ |
| + | | SHA-256 | | | Concat KDF and | | + | | SHA-256 | | | Concat KDF and |
skipping to change at page 37, line 27 skipping to change at page 37, line 27
Private members allow for the archival of keys by individuals. Private members allow for the archival of keys by individuals.
However, there are some circumstances in which private keys may be However, there are some circumstances in which private keys may be
distributed to entities in a protocol. Examples include: entities distributed to entities in a protocol. Examples include: entities
that have poor random number generation, centralized key creation for that have poor random number generation, centralized key creation for
multi-cast type operations, and protocols in which a shared secret is multi-cast type operations, and protocols in which a shared secret is
used as a bearer token for authorization purposes. used as a bearer token for authorization purposes.
Key types are identified by the 'kty' member of the COSE_Key object. Key types are identified by the 'kty' member of the COSE_Key object.
In this document, we define four values for the member: In this document, we define four values for the member:
+-----------+-------+--------------------------+ +===========+=======+==========================+
| Name | Value | Description | | Name | Value | Description |
+===========+=======+==========================+ +===========+=======+==========================+
| OKP | 1 | Octet Key Pair | | OKP | 1 | Octet Key Pair |
+-----------+-------+--------------------------+ +-----------+-------+--------------------------+
| EC2 | 2 | Elliptic Curve Keys w/ | | EC2 | 2 | Elliptic Curve Keys w/ |
| | | x- and y-coordinate pair | | | | x- and y-coordinate pair |
+-----------+-------+--------------------------+ +-----------+-------+--------------------------+
| Symmetric | 4 | Symmetric Keys | | Symmetric | 4 | Symmetric Keys |
+-----------+-------+--------------------------+ +-----------+-------+--------------------------+
| Reserved | 0 | This value is reserved | | Reserved | 0 | This value is reserved |
skipping to change at page 38, line 5 skipping to change at page 38, line 5
Two different key structures are defined for elliptic curve keys. Two different key structures are defined for elliptic curve keys.
One version uses both an x-coordinate and a y-coordinate, potentially One version uses both an x-coordinate and a y-coordinate, potentially
with point compression ('EC2'). This is the traditional EC point with point compression ('EC2'). This is the traditional EC point
representation that is used in [RFC5480]. The other version uses representation that is used in [RFC5480]. The other version uses
only the x-coordinate as the y-coordinate is either to be recomputed only the x-coordinate as the y-coordinate is either to be recomputed
or not needed for the key agreement operation ('OKP'). or not needed for the key agreement operation ('OKP').
Applications MUST check that the curve and the key type are Applications MUST check that the curve and the key type are
consistent and reject a key if they are not. consistent and reject a key if they are not.
+---------+-------+----------+------------------------------------+ +=========+=======+==========+====================================+
| Name | Value | Key Type | Description | | Name | Value | Key Type | Description |
+=========+=======+==========+====================================+ +=========+=======+==========+====================================+
| P-256 | 1 | EC2 | NIST P-256 also known as secp256r1 | | P-256 | 1 | EC2 | NIST P-256 also known as secp256r1 |
+---------+-------+----------+------------------------------------+ +---------+-------+----------+------------------------------------+
| P-384 | 2 | EC2 | NIST P-384 also known as secp384r1 | | P-384 | 2 | EC2 | NIST P-384 also known as secp384r1 |
+---------+-------+----------+------------------------------------+ +---------+-------+----------+------------------------------------+
| P-521 | 3 | EC2 | NIST P-521 also known as secp521r1 | | P-521 | 3 | EC2 | NIST P-521 also known as secp521r1 |
+---------+-------+----------+------------------------------------+ +---------+-------+----------+------------------------------------+
| X25519 | 4 | OKP | X25519 for use w/ ECDH only | | X25519 | 4 | OKP | X25519 for use w/ ECDH only |
+---------+-------+----------+------------------------------------+ +---------+-------+----------+------------------------------------+
skipping to change at page 39, line 17 skipping to change at page 39, line 17
supported. supported.
d: This contains the private key. d: This contains the private key.
For public keys, it is REQUIRED that 'crv', 'x', and 'y' be present For public keys, it is REQUIRED that 'crv', 'x', and 'y' be present
in the structure. For private keys, it is REQUIRED that 'crv' and in the structure. For private keys, it is REQUIRED that 'crv' and
'd' be present in the structure. For private keys, it is RECOMMENDED 'd' be present in the structure. For private keys, it is RECOMMENDED
that 'x' and 'y' also be present, but they can be recomputed from the that 'x' and 'y' also be present, but they can be recomputed from the
required elements and omitting them saves on space. required elements and omitting them saves on space.
+------+------+-------+--------+---------------------------------+ +======+======+=======+========+=================================+
| Key | Name | Label | CBOR | Description | | Key | Name | Label | CBOR | Description |
| Type | | | Type | | | Type | | | Type | |
+======+======+=======+========+=================================+ +======+======+=======+========+=================================+
| 2 | crv | -1 | int / | EC identifier - Taken from the | | 2 | crv | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry | | | | | tstr | "COSE Elliptic Curves" registry |
+------+------+-------+--------+---------------------------------+ +------+------+-------+--------+---------------------------------+
| 2 | x | -2 | bstr | x-coordinate | | 2 | x | -2 | bstr | x-coordinate |
+------+------+-------+--------+---------------------------------+ +------+------+-------+--------+---------------------------------+
| 2 | y | -3 | bstr / | y-coordinate | | 2 | y | -3 | bstr / | y-coordinate |
| | | | bool | | | | | | bool | |
skipping to change at page 40, line 13 skipping to change at page 40, line 13
it is a little-endian integer.) it is a little-endian integer.)
d: This contains the private key. d: This contains the private key.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the For public keys, it is REQUIRED that 'crv' and 'x' be present in the
structure. For private keys, it is REQUIRED that 'crv' and 'd' be structure. For private keys, it is REQUIRED that 'crv' and 'd' be
present in the structure. For private keys, it is RECOMMENDED that present in the structure. For private keys, it is RECOMMENDED that
'x' also be present, but it can be recomputed from the required 'x' also be present, but it can be recomputed from the required
elements and omitting it saves on space. elements and omitting it saves on space.
+------+----------+-------+-------+---------------------------------+ +======+==========+=======+=======+=================================+
| Name | Key | Label | Type | Description | | Name | Key | Label | Type | Description |
| | Type | | | | | | Type | | | |
+======+==========+=======+=======+=================================+ +======+==========+=======+=======+=================================+
| crv | 1 | -1 | int / | EC identifier - Taken from the | | crv | 1 | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry | | | | | tstr | "COSE Elliptic Curves" registry |
+------+----------+-------+-------+---------------------------------+ +------+----------+-------+-------+---------------------------------+
| x | 1 | -2 | bstr | Public Key | | x | 1 | -2 | bstr | Public Key |
+------+----------+-------+-------+---------------------------------+ +------+----------+-------+-------+---------------------------------+
| d | 1 | -4 | bstr | Private key | | d | 1 | -4 | bstr | Private key |
+------+----------+-------+-------+---------------------------------+ +------+----------+-------+-------+---------------------------------+
skipping to change at page 40, line 43 skipping to change at page 40, line 43
member that is defined for this key type is: member that is defined for this key type is:
k: This contains the value of the key. k: This contains the value of the key.
This key structure does not have a form that contains only public This key structure does not have a form that contains only public
members. As it is expected that this key structure is going to be members. As it is expected that this key structure is going to be
transmitted, care must be taken that it is never transmitted transmitted, care must be taken that it is never transmitted
accidentally or insecurely. For symmetric keys, it is REQUIRED that accidentally or insecurely. For symmetric keys, it is REQUIRED that
'k' be present in the structure. 'k' be present in the structure.
+------+----------+-------+------+-------------+ +======+==========+=======+======+=============+
| Name | Key Type | Label | Type | Description | | Name | Key Type | Label | Type | Description |
+======+==========+=======+======+=============+ +======+==========+=======+======+=============+
| k | 4 | -1 | bstr | Key Value | | k | 4 | -1 | bstr | Key Value |
+------+----------+-------+------+-------------+ +------+----------+-------+------+-------------+
Table 21: Symmetric Key Parameters Table 21: Symmetric Key Parameters
8. COSE Capabilities 8. COSE Capabilities
There are some situations that have been identified where There are some situations that have been identified where
skipping to change at page 42, line 10 skipping to change at page 42, line 10
element). For a key, the first element should be the key type value. element). For a key, the first element should be the key type value.
While this means that the key type value will be duplicated if both While this means that the key type value will be duplicated if both
an algorithm and key capability are used, the key type is needed in an algorithm and key capability are used, the key type is needed in
order to understand the rest of the values. order to understand the rest of the values.
8.1. Assignments for Existing Algorithms 8.1. Assignments for Existing Algorithms
For the current set of algorithms in the registry, those in this For the current set of algorithms in the registry, those in this
document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig], document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig],
the capabilities list is an array with one element, the key type the capabilities list is an array with one element, the key type
(from the "COSE Key Types" Registry). It is expected future (from the "COSE Key Types" Registry). It is expected that future
registered algorithms could have zero, one, or multiple elements. registered algorithms could have zero, one, or multiple elements.
8.2. Assignments for Existing Key Types 8.2. Assignments for Existing Key Types
There are a number of pre-existing key types, the following deals There are a number of pre-existing key types, the following deals
with creating the capability definition for those structures: with creating the capability definition for those structures:
* OKP, EC2: The list of capabilities is: * OKP, EC2: The list of capabilities is:
- The key type value. (1 for OKP or 2 for EC2.) - The key type value. (1 for OKP or 2 for EC2.)
skipping to change at page 45, line 33 skipping to change at page 45, line 33
application can perform the check for duplicate keys. application can perform the check for duplicate keys.
10. IANA Considerations 10. IANA Considerations
10.1. Changes to "COSE Key Types" registry. 10.1. Changes to "COSE Key Types" registry.
IANA is requested to create a new column in the "COSE Key Types" IANA is requested to create a new column in the "COSE Key Types"
registry. The new column is to be labeled "Capabilities". The new registry. The new column is to be labeled "Capabilities". The new
column is to be populated according the entries in Table 22. column is to be populated according the entries in Table 22.
+-------+-----------+--------------------------+ +=======+===========+==========================+
| Value | Name | Capabilities | | Value | Name | Capabilities |
+=======+===========+==========================+ +=======+===========+==========================+
| 1 | OKP | [kty(1), crv] | | 1 | OKP | [kty(1), crv] |
+-------+-----------+--------------------------+ +-------+-----------+--------------------------+
| 2 | EC2 | [kty(2), crv] | | 2 | EC2 | [kty(2), crv] |
+-------+-----------+--------------------------+ +-------+-----------+--------------------------+
| 3 | RSA | [kty(3)] | | 3 | RSA | [kty(3)] |
+-------+-----------+--------------------------+ +-------+-----------+--------------------------+
| 4 | Symmetric | [kty(4)] | | 4 | Symmetric | [kty(4)] |
+-------+-----------+--------------------------+ +-------+-----------+--------------------------+
skipping to change at page 46, line 27 skipping to change at page 46, line 27
IANA is requested to update the pointer for expert rview to [[this IANA is requested to update the pointer for expert rview to [[this
document]]. document]].
IANA is requested to update the reference column in the "COSE IANA is requested to update the reference column in the "COSE
Algorithms" registry to include [[This Document]] as a reference for Algorithms" registry to include [[This Document]] as a reference for
all rows where it is not already present. all rows where it is not already present.
IANA is requested to add a new row to the "COSE Algorithms" registry. IANA is requested to add a new row to the "COSE Algorithms" registry.
+----------+---------------+-------------+------------+-------------+ +==========+===============+=============+============+=============+
| Name | Value | Description | Reference | Recommended | | Name | Value | Description | Reference | Recommended |
+==========+===============+=============+============+=============+ +==========+===============+=============+============+=============+
| IV | IV-GENERATION |For doing IV | [[THIS | No | | IV | IV-GENERATION |For doing IV | [[THIS | No |
|Generation| | generation | DOCUMENT]] | | |Generation| | generation | DOCUMENT]] | |
| | |for symmetric| | | | | |for symmetric| | |
| | | algorithms. | | | | | | algorithms. | | |
+----------+---------------+-------------+------------+-------------+ +----------+---------------+-------------+------------+-------------+
Table 23 Table 23
 End of changes. 45 change blocks. 
45 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/