rfc9053v2.txt   rfc9053.txt 
Internet Engineering Task Force (IETF) J. Schaad Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 9053 August Cellars Request for Comments: 9053 August Cellars
Obsoletes: 8152 October 2021 Obsoletes: 8152 January 2022
Category: Informational Category: Informational
ISSN: 2070-1721 ISSN: 2070-1721
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
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 to be for small code size and small message size. There is a need to be
able to define basic security services for this data format. This able to define basic security services for this data format. This
skipping to change at line 38 skipping to change at line 38
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841. Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9053. https://www.rfc-editor.org/info/rfc9053.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Requirements Terminology 1.1. Requirements Terminology
1.2. Changes from RFC 8152 1.2. Changes from RFC 8152
1.3. Document Terminology 1.3. Document Terminology
1.4. CBOR Grammar 1.4. CBOR Grammar
1.5. Examples 1.5. Examples
2. Signature Algorithms 2. Signature Algorithms
2.1. ECDSA 2.1. ECDSA
2.1.1. Security Considerations for ECDSA 2.1.1. Security Considerations for ECDSA
2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) 2.2. Edwards-Curve Digital Signature Algorithm (EdDSA)
2.2.1. Security Considerations for EdDSA 2.2.1. Security Considerations for EdDSA
3. Message Authentication Code (MAC) Algorithms 3. Message Authentication Code (MAC) Algorithms
3.1. Hash-Based Message Authentication Codes (HMACs) 3.1. Hash-Based Message Authentication Codes (HMACs)
3.1.1. Security Considerations for HMAC 3.1.1. Security Considerations for HMAC
3.2. AES Message Authentication Code (AES-CBC-MAC) 3.2. AES Message Authentication Code (AES-CBC-MAC)
3.2.1. Security Considerations for AES-CBC-MAC 3.2.1. Security Considerations for AES-CBC-MAC
4. Content Encryption Algorithms 4. Content Encryption Algorithms
4.1. AES-GCM 4.1. AES-GCM
4.1.1. Security Considerations for AES-GCM 4.1.1. Security Considerations for AES-GCM
4.2. AES-CCM 4.2. AES-CCM
skipping to change at line 122 skipping to change at line 122
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is "Concise Binary Object Representation come out of this process is "Concise Binary Object Representation
(CBOR)" [RFC8949]. CBOR extended the data model of JavaScript Object (CBOR)" [RFC8949]. CBOR extended the data model of JavaScript Object
Notation (JSON) [STD90] by allowing for binary data, among other Notation (JSON) [STD90] by allowing for binary data, among other
changes. CBOR is being adopted by several of the IETF working groups changes. CBOR is being adopted by several of the IETF working groups
dealing with the IoT world as their method of encoding data dealing with the IoT world as their method of encoding data
structures. CBOR was designed specifically to be small in terms of structures. CBOR was designed specifically to be small in terms of
both messages transported and implementation size and be a schema both messages transported and implementation size and be a schema-
free decoder. A need exists to provide message security services for free decoder. A need exists to provide message security services for
IoT, and using CBOR as the message-encoding format makes sense. IoT, and using CBOR as the message-encoding format makes sense.
The core COSE specification consists of two documents. [RFC9052] The core COSE specification consists of two documents. [RFC9052]
contains the serialization structures and the procedures for using contains the serialization structures and the procedures for using
the different cryptographic algorithms. This document provides an the different cryptographic algorithms. This document provides an
initial set of algorithms for use with those structures. initial set of algorithms for use with those structures.
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Changes from RFC 8152 1.2. Changes from RFC 8152
* Extracted the sections dealing with specific algorithms and place * Extracted the sections dealing with specific algorithms and placed
them into this document. The sections dealing with structure and them into this document. The sections dealing with structure and
general processing rules are placed in [RFC9052]. general processing rules are placed in [RFC9052].
* Made text clarifications and changes in terminology. * Made text clarifications and changes in terminology.
1.3. Document Terminology 1.3. Document Terminology
In this document, we use the following terminology: In this document, we use the following terminology:
Byte: A synonym for octet. Byte: A synonym for octet.
Constrained Application Protocol (CoAP): A specialized web transfer Constrained Application Protocol (CoAP): A specialized web transfer
protocol for use in constrained systems. It is defined in protocol for use in constrained systems. It is defined in
[RFC7252]. [RFC7252].
Authenticated Encryption (AE) algorithms [RFC5116]: Encryption Authenticated Encryption (AE) algorithms [RFC5116]: Encryption
algorithms that provide an authentication check of the contents algorithms that provide an authentication check of the contents
with the encryption service. An example of an AE algorithm used along with the encryption service. An example of an AE algorithm
in COSE is AES Key Wrap [RFC3394]. These algorithms are used for used in COSE is AES Key Wrap [RFC3394]. These algorithms are used
key encryption algorithms, but Authenticated Encryption with for key encryption, but Authenticated Encryption with Associated
Associated Data (AEAD) algorithms would be preferred. Data (AEAD) algorithms would be preferred.
AEAD algorithms [RFC5116]: Provide the same authentication service AEAD algorithms [RFC5116]: Provide the same authentication service
of the content as AE algorithms do. They also allow associated of the content as AE algorithms do. They also allow associated
data that is not part of the encrypted body to be included in the data that is not part of the encrypted body to be included in the
authentication service. An example of an AEAD algorithm used in authentication service. An example of an AEAD algorithm used in
COSE is AES-GCM [RFC5116]. These algorithms are used for content COSE is AES-GCM [RFC5116]. These algorithms are used for content
encryption and can be used for key encryption as well. encryption and can be used for key encryption as well.
The term "byte string" is used for sequences of bytes, while the term The term "byte string" is used for sequences of bytes, while the term
"text string" is used for sequences of characters. "text string" is used for sequences of characters.
The tables for algorithms contain the following columns: The tables for algorithms contain the following columns:
* A name for the algorithms for use in documents. * A name for the algorithm for use in documents.
* The value used on the wire for the algorithm. One place this is * The value used on the wire for the algorithm. One place this is
used is the algorithm header parameter of a message. used is the algorithm header parameter of a message.
* A short description so that the algorithm can be easily identified * A short description so that the algorithm can be easily identified
when scanning the IANA registry. when scanning the IANA registry.
Additional columns may be present in a table depending on the Additional columns may be present in a table depending on the
algorithms. algorithms.
1.4. CBOR Grammar 1.4. CBOR Grammar
At the time that [RFC8152] was initially published, the CBOR Data There was not a standard CBOR grammar available when COSE was
Definition Language (CDDL) [RFC8610] had not yet been published. originally written. For that reason, the CBOR data objects defined
Since that time, [RFC8610] has been published as an RFC, providing here are described in prose. Since that time, [RFC8610] has
such a data description grammar to describe CBOR. This document uses specified the Concise Data Definition Language (CDDL), providing such
a variant of CDDL that is described in [RFC9052]. a data description grammar to describe CBOR. The CBOR grammar
presented in this document is compatible with CDDL.
1.5. Examples 1.5. Examples
A GitHub project has been created at [GitHub-Examples] that contains A GitHub project has been created at [GitHub-Examples] that contains
a set of testing examples as well. Each example is found in a JSON a set of testing examples. Each example is found in a JSON file that
file that contains the inputs used to create the example, some of the contains the inputs used to create the example, some of the
intermediate values that can be used for debugging, and the output of intermediate values that can be used for debugging, and the output of
the example. The results are encoded using both hexadecimal and CBOR the example. The results are encoded using both hexadecimal and CBOR
diagnostic notation format. diagnostic notation format.
Some of the examples are designed to test the failure case; these are Some of the examples are designed to be failure-testing cases; these
clearly marked as such in the JSON file. If errors in the examples are clearly marked as such in the JSON file.
in this document are found, the examples on GitHub will be updated,
and a note to that effect will be placed in the JSON file.
2. Signature Algorithms 2. Signature Algorithms
Section 8.1 of [RFC9052] contains a generic description of signature Section 8.1 of [RFC9052] contains a generic description of signature
algorithms. This document defines signature algorithm identifiers algorithms. This document defines signature algorithm identifiers
for two signature algorithms. for two signature algorithms.
2.1. ECDSA 2.1. ECDSA
The Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] defines The Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] defines
skipping to change at line 327 skipping to change at line 326
* Changing the hash function used to validate the signature: If one * Changing the hash function used to validate the signature: If one
either has two different hash functions of the same length or can either has two different hash functions of the same length or can
truncate a hash function, then one could potentially find truncate a hash function, then one could potentially find
collisions between the hash functions rather than within a single collisions between the hash functions rather than within a single
hash function. For example, truncating SHA-512 to 256 bits might hash function. For example, truncating SHA-512 to 256 bits might
collide with a SHA-256 bit hash value. As the hash algorithm is collide with a SHA-256 bit hash value. As the hash algorithm is
part of the signature algorithm identifier, this attack is part of the signature algorithm identifier, this attack is
mitigated by including a signature algorithm identifier in the mitigated by including a signature algorithm identifier in the
protected-header bucket. protected-header bucket.
2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) 2.2. Edwards-Curve Digital Signature Algorithm (EdDSA)
[RFC8032] describes the elliptic curve signature scheme Edwards-curve [RFC8032] describes the elliptic curve signature scheme Edwards-curve
Digital Signature Algorithm (EdDSA). In that document, the signature Digital Signature Algorithm (EdDSA). In that document, the signature
algorithm is instantiated using parameters for edwards25519 and algorithm is instantiated using parameters for edwards25519 and
edwards448 curves. The document additionally describes two variants edwards448 curves. The document additionally describes two variants
of the EdDSA algorithm: Pure EdDSA, where no hash function is applied of the EdDSA algorithm: Pure EdDSA, where no hash function is applied
to the content before signing, and HashEdDSA, where a hash function to the content before signing, and HashEdDSA, where a hash function
is applied to the content before signing and the result of that hash is applied to the content before signing and the result of that hash
function is signed. For EdDSA, the content to be signed (either the function is signed. For EdDSA, the content to be signed (either the
message or the prehash value) is processed twice inside of the message or the prehash value) is processed twice inside of the
skipping to change at line 393 skipping to change at line 392
Diffie-Hellman (ECDH); for this reason, the public key from one Diffie-Hellman (ECDH); for this reason, the public key from one
should not be used with the other algorithm. 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 nonbatch signature verification are [RFC8032]). Signing and nonbatch 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.
3. Message Authentication Code (MAC) Algorithms 3. Message Authentication Code (MAC) Algorithms
Section 9.2 of [RFC9052] contains a generic description of MAC Section 8.2 of [RFC9052] contains a generic description of MAC
algorithms. This section defines the conventions for two MAC algorithms. This section defines the conventions for two MAC
algorithms. algorithms.
3.1. Hash-Based Message Authentication Codes (HMACs) 3.1. Hash-Based Message Authentication Codes (HMACs)
HMAC [RFC2104] [RFC4231] was designed to deal with length extension HMAC [RFC2104] [RFC4231] was designed to deal with length extension
attacks. The algorithm was also designed to allow new hash attacks. The HMAC algorithm was also designed to allow new hash
algorithms to be directly plugged in without changes to the hash functions to be directly plugged in without changes to the hash
function. The HMAC design process has been shown to be solid; function. The HMAC design process has been shown to be solid;
although the security of hash algorithms such as MD5 has decreased although the security of hash functions such as MD5 has decreased
over time, the security of HMAC combined with MD5 has not yet been over time, the security of HMAC combined with MD5 has not yet been
shown to be compromised [RFC6151]. shown to be compromised [RFC6151].
The HMAC algorithm is parameterized by an inner and outer padding, a The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h), and an authentication tag value length. For this hash function (h), and an authentication tag value length. For this
specification, the inner and outer padding are fixed to the values specification, the inner and outer padding are fixed to the values
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
skipping to change at line 543 skipping to change at line 542
* In Cipher Block Chaining (CBC) mode, if the same key is used for * In Cipher Block Chaining (CBC) mode, if the same key is used for
both encryption and authentication operations, an attacker can both encryption and authentication operations, an attacker can
produce messages with a valid authentication code. produce messages with a valid authentication code.
* If the IV can be modified, then messages can be forged. This is * If the IV can be modified, then messages can be forged. This is
addressed by fixing the IV to all zeros. addressed by fixing the IV to all zeros.
4. Content Encryption Algorithms 4. Content Encryption Algorithms
Section 9.3 of [RFC9052] contains a generic description of content Section 8.3 of [RFC9052] contains a generic description of content
encryption algorithms. This document defines the identifier and encryption algorithms. This document defines the identifier and
usages for three content encryption algorithms. usages for three content encryption algorithms.
4.1. AES-GCM 4.1. AES-GCM
The Galois/Counter Mode (GCM) mode is a generic AEAD block cipher The Galois/Counter Mode (GCM) mode is a generic AEAD block cipher
mode defined in [AES-GCM]. The GCM mode is combined with the AES mode defined in [AES-GCM]. The GCM mode is combined with the AES
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
skipping to change at line 574 skipping to change at line 573
| 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 Values for AES-GCM Table 5: Algorithm Values for AES-GCM
Keys may be obtained from either a key structure or a recipient Keys may be obtained from either a key structure or a recipient
structure. Implementations that are encrypting and decrypting MUST structure. Implementations that are encrypting or decrypting MUST
validate that the key type, key length, and algorithm are correct and validate that the key type, key length, and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
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 AES-GCM algorithm * If the "alg" field is present, it MUST match the AES-GCM algorithm
being used. being used.
skipping to change at line 606 skipping to change at line 605
* 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 this limit might be environments where it is expected that this limit might be
exceeded. exceeded.
* A more recent analysis in [ROBUST] indicates that the number of * A more recent analysis in [ROBUST] indicates that the number of
failed decryptions needs to be taken into account as part of failed decryptions needs to be taken into account as part of
determining when a key rollover is to be done. Following the determining when a key rollover is to be done. Following the
recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of recommendation in DTLS (Section 4.5.3 of [DTLS13]), the number of
failed message decryptions should be limited to 2^36. failed message decryptions should be limited to 2^36.
Consideration was given to supporting smaller tag values; the Consideration was given to supporting smaller tag values; the
constrained community would desire tag sizes in the 64-bit range. constrained community would desire tag sizes in the 64-bit range.
Such use drastically changes both the maximum message size (generally Such use drastically changes both the maximum message size (generally
not an issue) and the number of times that a key can be used. Given not an issue) and the number of times that a key can be used. Given
that Counter with CBC-MAC (CCM) is the usual mode for constrained that Counter with CBC-MAC (CCM) is the usual mode for constrained
environments, restricted modes are not supported. environments, restricted modes are not supported.
4.2. AES-CCM 4.2. AES-CCM
CCM is a generic authentication encryption block cipher mode defined CCM is a generic authentication encryption block cipher mode defined
in [RFC3610]. The CCM mode is combined with the AES block encryption in [RFC3610]. The CCM mode is combined with the AES block encryption
algorithm to define a commonly used content encryption algorithm used algorithm to define an AEAD cipher that is commonly used in
in constrained devices. constrained devices.
CCM mode has two parameter choices. The first choice is M, the size The CCM mode has two parameter choices. The first choice is M, the
of the authentication field. The choice of the value for M involves size of the authentication field. The choice of the value for M
a trade-off between message growth (from the tag) and the probability involves a trade-off between message growth (from the tag) and the
that an attacker can undetectably modify a message. The second probability that an attacker can undetectably modify a message. The
choice is L, the size of the length field. This value requires a second choice is L, the size of the length field. This value
trade-off between the maximum message size and the size of the nonce. requires a trade-off between the maximum message size and the size of
the nonce.
It is unfortunate that the specification for CCM specified L and M as It is unfortunate that the specification for CCM specified L and M as
a count of bytes rather than a count of bits. This leads to possible a count of bytes rather than a count of bits. This leads to possible
misunderstandings where AES-CCM-8 is frequently used to refer to a misunderstandings where AES-CCM-8 is frequently used to refer to a
version of CCM mode where the size of the authentication is 64 bits version of CCM mode where the size of the authentication is 64 bits
and not 8 bits. In most cryptographic algorithm specifications, and not 8 bits. In most cryptographic algorithm specifications,
these values have traditionally been specified as bit counts rather these values have traditionally been specified as bit counts rather
than byte counts. This document will follow the convention of using than byte counts. This document will follow the convention of using
bit counts so that it is easier to compare the different algorithms bit counts so that it is easier to compare the different algorithms
presented in this document. presented in this document.
skipping to change at line 717 skipping to change at line 717
+--------------------+-------+----+-----+--------+---------------+ +--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode | | AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, | | | | | | | 256-bit key, |
| | | | | | 128-bit tag, | | | | | | | 128-bit tag, |
| | | | | | 7-byte nonce | | | | | | | 7-byte nonce |
+--------------------+-------+----+-----+--------+---------------+ +--------------------+-------+----+-----+--------+---------------+
Table 6: Algorithm Values for AES-CCM Table 6: Algorithm Values for AES-CCM
Keys may be obtained from either a key structure or a recipient Keys may be obtained from either a key structure or a recipient
structure. Implementations that are encrypting and decrypting MUST structure. Implementations that are encrypting or decrypting MUST
validate that the key type, key length, and algorithm are correct and validate that the key type, key length, and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
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 AES-CCM algorithm * If the "alg" field is present, it MUST match the AES-CCM algorithm
being used. being used.
skipping to change at line 749 skipping to change at line 749
* 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 limit is the sum of times the block exceed 2^61 operations. This limit is the sum of times the block
cipher is used in computing the MAC value and performing stream cipher is used in computing the MAC value and performing stream
encryption operations. An explicit check is required only in encryption operations. An explicit check is required only in
environments where it is expected that this limit might be environments where it is expected that this limit might be
exceeded. exceeded.
* [RFC9001] contains an analysis on the use of AES-CCM in that * [RFC9001] contains an analysis on the use of AES-CCM for its
environment. Based on that recommendation, one should restrict environment. Based on that recommendation, one should restrict
the number of messages encrypted to 2^23. If one is using the the number of messages encrypted to 2^23. If one is using the
64-bit tag, then the limits are significantly smaller if one wants 64-bit tag, then the limits are significantly smaller if one wants
to keep the same integrity limits. A protocol recommending this to keep the same integrity limits. A protocol recommending this
needs to analyze what level of integrity is acceptable for the needs to analyze what level of integrity is acceptable for the
smaller tag size. It may be that, to keep the desired integrity, smaller tag size. It may be that, to keep the desired level of
one needs to rekey as often as every 2^7 messages. integrity, one needs to rekey as often as every 2^7 messages.
* In addition to the number of messages successfully decrypted, the * In addition to the number of messages successfully decrypted, the
number of failed decryptions needs to be kept as well. If the number of failed decryptions needs to be tracked as well. If the
number of failed decryptions exceeds 2^23, then a rekeying number of failed decryptions exceeds 2^23, then a rekeying
operation should occur. operation should occur.
[RFC3610] additionally calls out one other consideration of note. It [RFC3610] additionally calls out one other consideration of note. It
is possible to do a precomputation attack against the algorithm in is possible to do a precomputation attack against the algorithm in
cases where portions of the plaintext are highly predictable. This cases where portions of the plaintext are highly predictable. This
reduces the security of the key size by half. Ways to deal with this reduces the security of the key size by half. Ways to deal with this
attack include adding a random portion to the nonce value and/or attack include adding a random portion to the nonce value and/or
increasing the key size used. Using a portion of the nonce for a increasing the key size used. Using a portion of the nonce for a
random value will decrease the number of messages that a single key random value will decrease the number of messages that a single key
can be used for. Increasing the key size may require more resources can be used for. Increasing the key size may require more resources
in the constrained device. See Sections 5 and 10 of [RFC3610] for in the constrained device. See Sections 5 and 10 of [RFC3610] for
more information. more information.
4.3. ChaCha20 and Poly1305 4.3. ChaCha20 and Poly1305
ChaCha20 and Poly1305 combined together is an AEAD mode that is ChaCha20 and Poly1305 combined together is an AEAD mode that is
defined in [RFC8439]. This is an algorithm defined to be a cipher defined in [RFC8439]. This is an algorithm defined using a cipher
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 as inputs a 256-bit key and a 96-bit parameterization. It takes as inputs a 256-bit key and a 96-bit
nonce, as well as the plaintext and additional data, and produces the nonce, as well as the plaintext and additional data, and produces the
ciphertext as an option. We define one algorithm identifier for this ciphertext as an output. 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 from either a key structure or a recipient Keys may be obtained from either a key structure or a recipient
structure. Implementations that are encrypting and decrypting MUST structure. Implementations that are encrypting or decrypting MUST
validate that the key type, key length, and algorithm are correct and validate that the key type, key length, and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
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 ChaCha20/Poly1305 * If the "alg" field is present, it MUST match the ChaCha20/Poly1305
algorithm being used. algorithm being used.
skipping to change at line 825 skipping to change at line 825
4.3.1. Security Considerations for ChaCha20/Poly1305 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 number of A more recent analysis in [ROBUST] indicates that the number of
failed decryptions needs to be taken into account as part of failed decryptions needs to be taken into account as part of
determining when a key rollover is to be done. Following the determining when a key rollover is to be done. Following the
recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of recommendation in DTLS (Section 4.5.3 of [DTLS13]), the number of
failed message decryptions should be limited to 2^36. failed message decryptions should be limited to 2^36.
[RFC9001] recommends that no more than 2^24.5 messages be encrypted [RFC9001] recommends that no more than 2^24.5 messages be encrypted
under a single key. under a single key.
5. Key Derivation Functions (KDFs) 5. Key Derivation Functions (KDFs)
Section 9.4 of [RFC9052] contains a generic description of key Section 8.4 of [RFC9052] contains a generic description of key
derivation functions. This document defines a single context derivation functions. This document defines a single context
structure and a single KDF. These elements are used for all of the structure and a single KDF. These elements are used for all of the
recipient algorithms defined in this document that require a KDF recipient algorithms defined in this document that require a KDF
process. These algorithms are defined in Sections 6.1.2, 6.3.1, and process. These algorithms are defined in Sections 6.1.2, 6.3.1, and
6.4.1. 6.4.1.
5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) 5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF)
The HKDF key derivation algorithm is defined in [RFC5869] and [HKDF]. The HKDF key derivation algorithm is defined in [RFC5869] and [HKDF].
skipping to change at line 1092 skipping to change at line 1092
identities can be assigned in one of two manners. First, a identities can be assigned in one of two manners. First, a
protocol can assign identities based on roles. For example, protocol can assign identities based on roles. For example,
the roles of "client" and "server" may be assigned to different the roles of "client" and "server" may be assigned to different
entities in the protocol. Each entity would then use the entities in the protocol. Each entity would then use the
correct label for the data it sends or receives. The second correct label for the data it sends or receives. The second
way for a protocol to assign identities is to use a name based way for a protocol to assign identities is to use a name based
on a naming system (i.e., DNS or X.509 names). on a naming system (i.e., DNS or X.509 names).
We define an algorithm parameter, "PartyU identity", that can We define an algorithm parameter, "PartyU identity", that can
be used to carry identity information in the message. However, be used to carry identity information in the message. However,
identity information is often known to be part of the protocol identity information is often known as part of the protocol and
and can thus be inferred rather than made explicit. If can thus be inferred rather than made explicit. If identity
identity information is carried in the message, applications information is carried in the message, applications SHOULD have
SHOULD have a way of validating the supplied identity a way of validating the supplied identity information. The
information. The identity information does not need to be identity information does not need to be specified and is set
specified and is set to nil in that case. to nil in that case.
nonce: This contains a nonce value. The nonce can be either nonce: This contains a nonce value. The nonce can be either
implicit from the protocol or carried as a value in the implicit from the protocol or carried as a value in the
unprotected header bucket. unprotected header bucket.
We define an algorithm parameter, "PartyU nonce", that can be We define an algorithm parameter, "PartyU nonce", that can be
used to carry this value in the message; however, the nonce used to carry this value in the message; however, the nonce
value could be determined by the application and and its value value could be determined by the application and and its value
obtained in a different manner. obtained in a different manner.
skipping to change at line 1119 skipping to change at line 1119
set to nil. set to nil.
other: This contains other information that is defined by the other: This contains other information that is defined by the
protocol. This option does not need to be specified; if not protocol. This option does not need to be specified; if not
needed, it is set to nil. needed, it is set to nil.
PartyVInfo: This field holds information about PartyV. The content PartyVInfo: This field holds information about PartyV. The content
of the structure is the same as for the PartyUInfo but for PartyV. of the structure is the same as for the PartyUInfo but for PartyV.
SuppPubInfo: This field contains public information that is mutually SuppPubInfo: This field contains public information that is mutually
known to both parties. known to both parties, and is encoded as a CBOR array.
keyDataLength: This is set to the number of bits of the desired keyDataLength: This is set to the number of bits of the desired
output value. This practice means if algorithm A can use two output value. This practice means if algorithm A can use two
different key lengths, the key derived for the longer key size different key lengths, the key derived for the longer key size
will not contain the key for the shorter key size as a prefix. will not contain the key for the shorter key size as a prefix.
protected: This field contains the protected parameter field. If protected: This field contains the protected parameter field. If
there are no elements in the "protected" field, then use a there are no elements in the "protected" field, then use a
zero-length bstr. zero-length bstr.
skipping to change at line 1188 skipping to change at line 1188
[RFC9052]. Information about how to fill in the COSE_Recipient [RFC9052]. Information about how to fill in the COSE_Recipient
structure is detailed there. structure is detailed there.
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 have zero When this algorithm is used, the "protected" field MUST be zero
length. The key type MUST be "Symmetric". length. The key type MUST be "Symmetric".
+========+=======+============================================+ +========+=======+============================================+
| Name | Value | Description | | Name | Value | Description |
+========+=======+============================================+ +========+=======+============================================+
| direct | -6 | Direct use of content encryption key (CEK) | | direct | -6 | Direct use of content encryption key (CEK) |
+--------+-------+--------------------------------------------+ +--------+-------+--------------------------------------------+
Table 11: Direct Key Table 11: Direct Key
skipping to change at line 1241 skipping to change at line 1241
If the salt/nonce value is generated randomly, then it is suggested If the salt/nonce value is generated randomly, then it is suggested
that the length of the random value be the same length as the output that the length of the random value be the same length as the output
of the hash function underlying HKDF. While there is no way to of the hash function underlying HKDF. While there is no way to
guarantee that it will be unique, there is a high probability that it guarantee that it will be unique, there is a high probability that it
will be unique. If the salt/nonce value is generated will be unique. If the salt/nonce value is generated
deterministically, it can be guaranteed to be unique, and thus there deterministically, it can be guaranteed to be unique, and thus there
is no length requirement. is no length requirement.
A new IV must be used for each message if the same key is used. The A new IV must be used for each message if the same key is used. The
IV can be modified in a predictable manner, a random manner, or an IV can be modified in a predictable manner, a random manner, or an
unpredictable manner (i.e., encrypting a counter). unpredictable manner (e.g., encrypting a counter).
The IV used for a key can also be generated using the same HKDF The IV used for a key can also be generated using the same HKDF
functionality used to generate the key. If HKDF is used for functionality used to generate the key. 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.
+=====================+=======+==============+=====================+ +=====================+=======+==============+=====================+
skipping to change at line 1311 skipping to change at line 1311
The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm
uses an AES key to wrap a value that is a multiple of 64 bits. As uses an AES key to wrap a value that is a multiple of 64 bits. As
such, it can be used to wrap a key for any of the content encryption such, it can be used to wrap a key for any of the content encryption
algorithms defined in this document. The algorithm requires a single algorithms defined in this document. The algorithm requires a single
fixed parameter, the initial value. This is fixed to the value fixed parameter, the initial value. This is fixed to the value
specified in Section 2.2.3.1 of [RFC3394]. There are no public key specified in Section 2.2.3.1 of [RFC3394]. There are no public key
parameters that vary on a per-invocation basis. The protected header parameters that vary on a per-invocation basis. The protected header
bucket MUST be empty. bucket MUST be empty.
Keys may be obtained from either a key structure or a recipient Keys may be obtained from either a key structure or a recipient
structure. Implementations that are encrypting and decrypting MUST structure. Implementations that are encrypting or decrypting MUST
validate that the key type, key length, and algorithm are correct and validate that the key type, key length, and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
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 AES Key Wrap * If the "alg" field is present, it MUST match the AES Key Wrap
algorithm being used. algorithm being used.
skipping to change at line 1348 skipping to change at line 1348
Table 13: AES Key Wrap Algorithm Values Table 13: AES Key Wrap Algorithm Values
6.2.1.1. Security Considerations for AES Key Wrap 6.2.1.1. Security Considerations for AES Key Wrap
The shared secret needs to have some method of being regularly The shared secret needs to have some method of being regularly
updated over time. The shared secret is the basis of trust. updated over time. The shared secret is the basis of trust.
6.3. Direct Key Agreement 6.3. Direct Key Agreement
Key transport is defined in Section 8.5.3 of [RFC9052]. Information Direct Key Agreement is defined in Section 8.5.3 of [RFC9052].
about how to fill in the COSE_Recipient structure is detailed there. Information about how to fill in the COSE_Recipient structure is
detailed there.
6.3.1. Direct ECDH 6.3.1. Direct ECDH
The mathematics for ECDH can be found in [RFC6090]. In this The mathematics for ECDH can be found in [RFC6090]. In this
document, the algorithm is extended to be used with the two curves document, the algorithm is extended to be used with the two curves
defined in [RFC7748]. defined in [RFC7748].
ECDH is parameterized by the following: ECDH is parameterized by the following:
Curve Type/Curve: The curve selected controls not only the size of Curve Type/Curve: The curve selected controls not only the size of
skipping to change at line 1387 skipping to change at line 1388
defined in [RFC8017], using the same computation for n as is defined in [RFC8017], using the same computation for n as is
defined in Section 2.1. defined in Section 2.1.
Ephemeral-Static or Static-Static: The key agreement process may be Ephemeral-Static or Static-Static: The key agreement process may be
done using either a static or an ephemeral key for the sender's done using either a static or an ephemeral key for the sender's
side. When using ephemeral keys, the sender MUST generate a new side. When using ephemeral keys, the sender MUST generate a new
ephemeral key for every key agreement operation. The ephemeral ephemeral key for every key agreement operation. The ephemeral
key is placed in the "ephemeral key" parameter and MUST be present key is placed in the "ephemeral key" parameter and MUST be present
for all algorithm identifiers that use ephemeral keys. When using for all algorithm identifiers that use ephemeral keys. When using
static keys, the sender MUST either generate a new random value or static keys, the sender MUST either generate a new random value or
create a unique value. For the KDFs used, this means that either create a unique value for use as a KDF input. For the KDFs used,
the "salt" parameter for HKDF (Table 9) or the "PartyU nonce" this means that either the "salt" parameter for HKDF (Table 9) or
parameter for the context structure (Table 10) MUST be present the "PartyU nonce" parameter for the context structure (Table 10)
(both can be present if desired). The value in the parameter MUST MUST be present (both can be present if desired). The value in
be unique for the pair of keys being used. It is acceptable to the parameter MUST be unique for the pair of keys being used. It
use a global counter that is incremented for every Static-Static is acceptable to use a global counter that is incremented for
operation and use the resulting value. Care must be taken that every Static-Static operation and use the resulting value. Care
the counter is saved to permanent storage in a way that avoids must be taken that the counter is saved to permanent storage in a
reuse of that counter value. When using static keys, the static way that avoids reuse of that counter value. When using static
key should be identified to the recipient. The static key can be keys, the static key should be identified to the recipient. The
identified by providing either the key ("static key") or a key static key can be identified by providing either the key ("static
identifier for the static key ("static key id"). Both of these key") or a key identifier for the static key ("static key id").
header parameters are defined in Table 15. Both of these header parameters are defined in Table 15.
Key Derivation Algorithm: The result of an ECDH key agreement Key Derivation Algorithm: The result of an ECDH key agreement
process does not provide a uniformly random secret. As such, it process does not provide a uniformly random secret. As such, it
needs to be run through a KDF in order to produce a usable key. needs to be run through a KDF in order to produce a usable key.
Processing the secret through a KDF also allows for the Processing the secret through a KDF also allows for the
introduction of context material: how the key is going to be used introduction of context material: how the key is going to be used
and one-time material for Static-Static key agreement. All of the and one-time material for Static-Static key agreement. All of the
algorithms defined in this document use one of the HKDF algorithms algorithms defined in this document use one of the HKDF algorithms
defined in Section 5.1 with the context structure defined in defined in Section 5.1 with the context structure defined in
Section 5.2. Section 5.2.
skipping to change at line 1779 skipping to change at line 1780
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 Parameter Table 21: Symmetric Key Parameters
8. COSE Capabilities 8. COSE Capabilities
Some situations have been identified where identification of Some situations have been identified where identification of
capabilities of an algorithm or a key type needs to be specified. capabilities of an algorithm or a key type needs to be specified.
One example of this is in [OSCORE-GROUPCOMM], where the capabilities One example of this is in [OSCORE-GROUPCOMM], where the capabilities
of the counter signature algorithm are mixed into the process of of the countersignature algorithm are mixed into the process of
traffic-key derivation. This has a counterpart in the S/MIME traffic-key derivation. This has a counterpart in the S/MIME
specifications, where SMIMECapabilities is defined in Section 2.5.2 specifications, where SMIMECapabilities is defined in Section 2.5.2
of [RFC8551]. This document defines the same concept for COSE. of [RFC8551]. This document defines the same concept for COSE.
The algorithm identifier is not included in the capabilities data, as The algorithm identifier is not included in the capabilities data, as
it should be encoded elsewhere in the message. The key type it should be encoded elsewhere in the message. The key type
identifier is included in the capabilities data, as it is not identifier is included in the capabilities data, as it is not
expected to be encoded elsewhere. expected to be encoded elsewhere.
Two different types of capabilities are defined: capabilities for Two different types of capabilities are defined: capabilities for
skipping to change at line 1858 skipping to change at line 1859
- The key type value (4). - The key type value (4).
* HSS-LMS: The list of capabilities is: * HSS-LMS: The list of capabilities is:
- The key type value (5). - The key type value (5).
- Algorithm identifier for the underlying hash function from the - Algorithm identifier for the underlying hash function from the
"COSE Algorithms" registry. "COSE Algorithms" registry.
* WalnutDSA: The list of capabilities is:
- The key type value (6).
8.3. Examples 8.3. Examples
Capabilities can be used in a key derivation process to make sure Capabilities can be used in a key derivation process to make sure
that both sides are using the same parameters. This is the approach that both sides are using the same parameters. This is the approach
that is being used by the group communication KDF in that is being used by the group communication KDF in
[OSCORE-GROUPCOMM]. The three examples below show different ways [OSCORE-GROUPCOMM]. The three examples below show different ways
that one might utilize parameters in specifying an application that one might utilize parameters in specifying an application
protocol: protocol:
* Only an algorithm capability: This is useful if the protocol wants * Only an algorithm capability: This is useful if the protocol wants
skipping to change at line 1954 skipping to change at line 1959
key type. key type.
* The last element indicates that the entity supports AES-GCM of 128 * The last element indicates that the entity supports AES-GCM of 128
bits for content encryption. bits for content encryption.
The entity does not advertise that it supports any MAC algorithms. The entity does not advertise that it supports any MAC algorithms.
9. CBOR Encoding Restrictions 9. CBOR Encoding Restrictions
This document limits the restrictions it imposes on how the CBOR This document limits the restrictions it imposes on how the CBOR
encoder needs to work. It has been narrowed down to the following Encoder needs to work. The new encoding restrictions are aligned
restrictions: with the deterministically encoded CBOR requirements specified in
[STD94]. It has been narrowed down to the following restrictions:
* The restriction applies to the encoding of the COSE_KDF_Context. * The restriction applies to the encoding of the COSE_KDF_Context.
* Encoding MUST be done using definite lengths, and the length of * Encoding MUST be done using definite lengths, and the length of
the (encoded) argument MUST be the minimum possible length. This the (encoded) argument MUST be the minimum possible length. This
means that the integer 1 is encoded as "0x01" and not "0x1801". means that the integer 1 is encoded as "0x01" and not "0x1801".
* Applications MUST NOT generate messages with the same label used * Applications MUST NOT generate messages with the same label used
twice as a key in a single map. Applications MUST NOT parse and twice as a key in a single map. Applications MUST NOT parse and
process messages with the same label used twice as a key in a process messages with the same label used twice as a key in a
single map. Applications can enforce the parse-and-process single map. Applications can enforce the parse-and-process
requirement by using parsers that will either fail the parse step requirement by using parsers that will fail the parse step or by
or pass all keys to the application, and the application can using parsers that will pass all keys to the application, and the
perform the check for duplicate keys. application can perform the check for duplicate keys.
10. IANA Considerations 10. IANA Considerations
IANA has updated all COSE registries except for "COSE Header IANA has updated all COSE registries except for "COSE Header
Parameters" and "COSE Key Common Parameters" to point to this Parameters" and "COSE Key Common Parameters" to point to this
document instead of [RFC8152]. document instead of [RFC8152].
10.1. Changes to the "COSE Key Types" Registry 10.1. Changes to the "COSE Key Types" Registry
IANA has added a new column in the "COSE Key Types" registry. The IANA has added a new column in the "COSE Key Types" registry. The
skipping to change at line 1996 skipping to change at line 2002
| 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)] |
+-------+-----------+--------------------------+ +-------+-----------+--------------------------+
| 5 | HSS-LMS | [kty(5), hash algorithm] | | 5 | HSS-LMS | [kty(5), hash algorithm] |
+-------+-----------+--------------------------+ +-------+-----------+--------------------------+
| 6 | WalnutDSA | [kty(6)] |
+-------+-----------+--------------------------+
Table 22: Key Type Capabilities Table 22: Key Type Capabilities
10.2. Changes to the "COSE Algorithms" Registry 10.2. Changes to the "COSE Algorithms" Registry
IANA has added a new column in the "COSE Algorithms" registry. The IANA has added a new column in the "COSE Algorithms" registry. The
new column is labeled "Capabilities" and has been populated with new column is labeled "Capabilities" and has been populated with
"[kty]" for all current, nonprovisional registrations. It is "[kty]" for all current, nonprovisional registrations.
expected that the documents that define those algorithms will be
expanded to include this registration. If this is not done, then the
designated expert should be consulted before final registration for
this document is done.
IANA has updated the Reference column in the "COSE Algorithms" IANA has updated the Reference column in the "COSE Algorithms"
registry to include this document as a reference for all rows where registry to include this document as a reference for all rows where
it was not already present. it was not already present.
IANA has added a new row to the "COSE Algorithms" registry. IANA has added a new row to the "COSE Algorithms" registry.
+============+===============+=============+==========+=============+ +===============+=======+===============+===========+=============+
| Name | Value |Description |Reference | Recommended | | Name | Value | Description | Reference | Recommended |
+============+===============+=============+==========+=============+ +===============+=======+===============+===========+=============+
| IV | IV-GENERATION |For doing IV |RFC 9053 | No | | IV-GENERATION | 34 | For doing IV | RFC 9053 | No |
| Generation | |generation | | | | | | generation | | |
| | |for symmetric| | | | | | for symmetric | | |
| | |algorithms. | | | | | | algorithms. | | |
+------------+---------------+-------------+----------+-------------+ +---------------+-------+---------------+-----------+-------------+
Table 23: New entry in the COSE Algorithms registry Table 23: New entry in the COSE Algorithms registry
The Capabilities column for this registration is to be empty. The Capabilities column for this registration is to be empty.
10.3. Changes to the "COSE Key Type Parameters" Registry 10.3. Changes to the "COSE Key Type Parameters" Registry
IANA has modified the description to "Public Key" for the line with IANA has modified the description to "Public Key" for the line with
"Key Type" of 1 and the "Name" of "x". See Table 20, which has been "Key Type" of 1 and the "Name" of "x". See Table 20, which has been
modified with this change. modified with this change.
10.4. Expert Review Instructions 10.4. Expert Review Instructions
All of the IANA registries established by [RFC8152] are, at least in All of the IANA registries established by [RFC8152] are, at least in
part, defined as Expert Review [RFC8126]. This section gives some part, defined as Expert Review [RFC8126]. This section gives some
general guidelines for what the experts should be looking for, but general guidelines for what the experts should be looking for, but
they are being designated as experts for a reason, so they should be they are being designated as experts for a reason, so they should be
given substantial latitude. given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take the following into consideration:
* Point squatting should be discouraged. Reviewers are encouraged * Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already that the usage is not going to duplicate an existing registration,
registered, and that the point is likely to be used in and that the code point is likely to be used in deployments. The
deployments. The zones tagged as private use are intended for zones tagged as private use are intended for testing purposes and
testing purposes and closed environments; code points in other closed environments; code points in other ranges should not be
ranges should not be assigned for testing. assigned for testing.
* Standards Track or BCP RFCs are required to register a code point * Standards Track or BCP RFCs are required to register a code point
in the Standards Action range. Specifications should exist for in the Standards Action range. Specifications should exist for
Specification Required ranges, but early assignment before an RFC Specification Required ranges, but early assignment before an RFC
is available is considered to be permissible. Specifications are is available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if the points are needed for the first-come, first-serve range if the points are
expected to be used outside of closed environments in an expected to be used outside of closed environments in an
interoperable way. When specifications are not provided, the interoperable way. When specifications are not provided, the
description provided needs to have sufficient information to description provided needs to have sufficient information to
identify what the point is being used for. identify what the point is being used for.
* Experts should take into account the expected usage of fields when * Experts should take into account the expected usage of fields when
approving point assignment. The fact that the Standards Action approving code point assignment. The fact that the Standards
range is only available to Standards Track documents does not mean Action range is only available to Standards Track documents does
that a Standards Track document cannot have points assigned not mean that a Standards Track document cannot have points
outside of that range. The length of the encoded value should be assigned outside of that range. The length of the encoded value
weighed against how many code points of that length are left, the should be weighed against how many code points of that length are
size of device it will be used on, and the number of code points left and the size of device it will be used on.
left that encode to that size.
* When algorithms are registered, vanity registrations should be * When algorithms are registered, vanity registrations should be
discouraged. One way to do this is to require registrations to discouraged. One way to do this is to require registrations to
provide additional documentation on security analysis of the provide additional documentation on security analysis of the
algorithm. Another thing that should be considered is requesting algorithm. Another thing that should be considered is requesting
an opinion on the algorithm from the Crypto Forum Research Group an opinion on the algorithm from the Crypto Forum Research Group
(CFRG). Algorithms are expected to meet the security requirements (CFRG). Algorithms are expected to meet the security requirements
of the community and the requirements of the message structures in of the community and the requirements of the message structures in
order to be suitable for registration. order to be suitable for registration.
skipping to change at line 2114 skipping to change at line 2117
The use of ECDH and direct plus KDF (with no key wrap) will not The use of ECDH and direct plus KDF (with no key wrap) will not
directly lead to the private key being leaked; the one-way function directly lead to the private key being leaked; the one-way function
of the KDF will prevent that. There is, however, a different issue of the KDF will prevent that. There is, however, a different issue
that needs to be addressed. Having two recipients requires that the that needs to be addressed. Having two recipients requires that the
CEK be shared between two recipients. The second recipient therefore CEK be shared between two recipients. The second recipient therefore
has a CEK that was derived from material that can be used for the has a CEK that was derived from material that can be used for the
weak proof of origin. The second recipient could create a message weak proof of origin. The second recipient could create a message
using the same CEK and send it to the first recipient; the first using the same CEK and send it to the first recipient; the first
recipient would, for either Static-Static ECDH or direct plus KDF, recipient would, for either Static-Static ECDH or direct plus KDF,
make an assumption that the CEK could be used for proof of origin make an assumption that the CEK could be used for proof of origin,
even though it is from the wrong entity. If the key wrap step is even though it is from the wrong entity. If the key wrap step is
added, then no proof of origin is implied and this is not an issue. added, then no proof of origin is implied and this is not an issue.
Although it has been mentioned before, the use of a single key for Although it has been mentioned before, it bears repeating that the
multiple algorithms has been demonstrated in some cases to leak use of a single key for multiple algorithms has been demonstrated in
information about a key, providing the opportunity for attackers to some cases to leak information about a key, providing the opportunity
forge integrity tags or gain information about encrypted content. for attackers to forge integrity tags or gain information about
Binding a key to a single algorithm prevents these problems. Key encrypted content. Binding a key to a single algorithm prevents
creators and key consumers are strongly encouraged to not only create these problems. Key creators and key consumers are strongly
new keys for each different algorithm, but include that selection of encouraged to not only create new keys for each different algorithm,
algorithm in any distribution of key material and strictly enforce but to include that selection of algorithm in any distribution of key
the matching of algorithms in the key structure to algorithms in the material and strictly enforce the matching of algorithms in the key
message structure. In addition to checking that algorithms are structure to algorithms in the message structure. In addition to
correct, the key form needs to be checked as well. Do not use an checking that algorithms are correct, the key form needs to be
"EC2" key where an "OKP" key is expected. checked as well. Do not use an "EC2" key where an "OKP" key is
expected.
Before using a key for transmission, or before acting on information Before using a key for transmission, or before acting on information
received, a trust decision on a key needs to be made. Is the data or received, a trust decision on a key needs to be made. Is the data or
action something that the entity associated with the key has a right action something that the entity associated with the key has a right
to see or a right to request? A number of factors are associated to see or a right to request? A number of factors are associated
with this trust decision. Some highlighted here are: with this trust decision. Some highlighted here are:
* What are the permissions associated with the key owner? * What are the permissions associated with the key owner?
* Is the cryptographic algorithm acceptable in the current context? * Is the cryptographic algorithm acceptable in the current context?
* Have the restrictions associated with the key, such as algorithm * Have the restrictions associated with the key, such as algorithm
or freshness, been checked, and are they correct? or freshness, been checked, and are they correct?
* Is the request something that is reasonable, given the current * Is the request something that is reasonable, given the current
state of the application? state of the application?
* Have any security considerations that are part of the message been * Have any security considerations that are part of the message been
enforced (as specified by the application or "crit" parameter)? enforced (as specified by the application or "crit" header
parameter)?
There are a large number of algorithms presented in this document There are a large number of algorithms presented in this document
that use nonce values. For all of the nonces defined in this that use nonce values. For all of the nonces defined in this
document, there is some type of restriction on the nonce being a document, there is some type of restriction on the nonce being a
unique value for either a key or some other conditions. In all of unique value for either a key or some other conditions. In all of
these cases, there is no known requirement on the nonce being both these cases, there is no known requirement on the nonce being both
unique and unpredictable; under these circumstances, it's reasonable unique and unpredictable; under these circumstances, it's reasonable
to use a counter for creation of the nonce. In cases where one wants to use a counter for creation of the nonce. In cases where one wants
the pattern of the nonce to be unpredictable as well as unique, one the pattern of the nonce to be unpredictable as well as unique, one
can use a key created for that purpose and encrypt the counter to can use a key created for that purpose and encrypt the counter to
produce the nonce value. produce the nonce value.
One area that has been getting exposure is traffic analysis of One area that has been getting exposure is traffic analysis of
encrypted messages based on the length of the message. This encrypted messages based on the length of the message. This
specification does not provide a uniform method of providing padding specification does not provide a uniform method for providing padding
as part of the message structure. An observer can distinguish as part of the message structure. An observer can distinguish
between two different messages (for example, "YES" and "NO") based on between two different messages (for example, "YES" and "NO") based on
the length for all of the content encryption algorithms that are the length for all of the content encryption algorithms that are
defined in this document. This means that it is up to the defined in this document. This means that it is up to the
applications to document how content padding is to be done, in order applications to document how content padding is to be done in order
to prevent or discourage such analysis. (For example, the text to prevent or discourage such analysis. (For example, the text
strings could be defined as "YES" and "NO".) strings could be defined as "YES" and "NO ".)
The analysis done in [RFC9001] is based on the number of records/ The analysis done in [RFC9001] is based on the number of records/
packets that are sent. This should map well to the number of packets that are sent. This should map well to the number of
messages sent when using COSE, so that analysis should hold here as messages sent when using COSE, so that analysis should hold here as
well. It needs to be noted that the limits are based on the number well. It needs to be noted that the limits are based on the number
of messages, but QUIC and DTLS are always pairwise-based endpoints of messages, but QUIC and DTLS are always pairwise-based endpoints.
[OSCORE-GROUPCOMM] and use COSE in a group communication. Under In contrast, [OSCORE-GROUPCOMM] uses COSE in a group communication
these circumstances, it may be that no one single entity will see all scenario. Under these circumstances, it may be that no one single
of the messages that are encrypted, and therefore no single entity entity will see all of the messages that are encrypted, and therefore
can trigger the rekey operation. no single entity can trigger the rekey operation.
12. References 12. References
12.1. Normative References 12.1. Normative References
[AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
November 2007, <https://csrc.nist.gov/publications/ November 2007, <https://csrc.nist.gov/publications/
nistpubs/800-38D/SP-800-38D.pdf>. nistpubs/800-38D/SP-800-38D.pdf>.
skipping to change at line 2267 skipping to change at line 2272
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, October 2021, DOI 10.17487/RFC9052, October 2021,
<https://www.rfc-editor.org/info/rfc9052>. <https://www.rfc-editor.org/info/rfc9052>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, September 2021,
<https://www.rfc-editor.org/info/rfc9147>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Standards for Efficient Cryptography, May 2009, Standards for Efficient Cryptography, May 2009,
<https://www.secg.org/sec1-v2.pdf>. <https://www.secg.org/sec1-v2.pdf>.
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/std94>.
12.2. Informative References 12.2. Informative References
[CFRG-DET-SIGS] [CFRG-DET-SIGS]
Mattsson, J. P., Thormarker, E., and S. Ruohomaa, Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
"Deterministic ECDSA and EdDSA Signatures with Additional "Deterministic ECDSA and EdDSA Signatures with Additional
Randomness", Work in Progress, Internet-Draft, draft- Randomness", Work in Progress, Internet-Draft, draft-
mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020, mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020,
<https://datatracker.ietf.org/doc/html/draft-mattsson- <https://datatracker.ietf.org/doc/html/draft-mattsson-
cfrg-det-sigs-with-noise-02>. cfrg-det-sigs-with-noise-02>.
[DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
dtls13-43>.
[GitHub-Examples] [GitHub-Examples]
"GitHub Examples of COSE", commit 3221310, 3 June 2020, "GitHub Examples of COSE", commit 3221310, 3 June 2020,
<https://github.com/cose-wg/Examples>. <https://github.com/cose-wg/Examples>.
[HKDF] Krawczyk, H., "Cryptographic Extraction and Key [HKDF] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", 2010, Derivation: The HKDF Scheme", 2010,
<https://eprint.iacr.org/2010/264.pdf>. <https://eprint.iacr.org/2010/264.pdf>.
[OSCORE-GROUPCOMM] [OSCORE-GROUPCOMM]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group OSCORE - Secure Group Communication and J. Park, "Group OSCORE - Secure Group Communication
for CoAP", Work in Progress, Internet-Draft, draft-ietf- for CoAP", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-groupcomm-12, 12 July 2021, core-oscore-groupcomm-13, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-core- <https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-groupcomm-12>. oscore-groupcomm-13>.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, DOI 10.17487/RFC4231, December 2005, RFC 4231, DOI 10.17487/RFC4231, December 2005,
<https://www.rfc-editor.org/info/rfc4231>. <https://www.rfc-editor.org/info/rfc4231>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/info/rfc4493>. 2006, <https://www.rfc-editor.org/info/rfc4493>.
skipping to change at line 2413 skipping to change at line 2424
The following individuals provided input into the final form of the The following individuals provided input into the final form of the
document: Carsten Bormann, John Bradley, Brian Campbell, Michael document: Carsten Bormann, John Bradley, Brian Campbell, Michael
B. Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and B. Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and
Göran Selander. Göran Selander.
Author's Address Author's Address
Jim Schaad Jim Schaad
August Cellars August Cellars
Email: ietf@augustcellars.com
 End of changes. 60 change blocks. 
137 lines changed or deleted 148 lines changed or added

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