draft-ietf-cose-rfc8152bis-algs-03.txt   draft-ietf-cose-rfc8152bis-algs-04.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) June 10, 2019 Obsoletes8152 (if approved) August 18, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: December 12, 2019 Expires: February 19, 2020
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-03 draft-ietf-cose-rfc8152bis-algs-04
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 the CBOR Object Signing and Encryption (COSE) This document defines the CBOR Object Signing and Encryption (COSE)
protocol. This specification describes how to create and process protocol. This specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR signatures, message authentication codes, and encryption using CBOR
for serialization. COSE additionally describes how to represent for serialization. COSE additionally describes how to represent
skipping to change at page 1, line 32 skipping to change at page 1, line 32
In this specification the conventions for the use of a number of In this specification the conventions for the use of a number of
cryptographic algorithms with COSE. The details of the structure of cryptographic algorithms with COSE. The details of the structure of
COSE are defined in [I-D.ietf-cose-rfc8152bis-struct]. COSE are defined in [I-D.ietf-cose-rfc8152bis-struct].
This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes
RFC8152. RFC8152.
Contributing to this document Contributing to this document
This note is to be removed before publishing as an RFC.
The source for this draft is being maintained in GitHub. Suggested The source for this draft is being maintained in GitHub. Suggested
changes should be submitted as pull requests at <https://github.com/ changes should be submitted as pull requests at https://github.com/
cose-wg/cose-rfc8152bis>. Instructions are on that page as well. cose-wg/cose-rfc8152bis. Instructions are on that page as well.
Editorial changes can be managed in GitHub, but any substantial Editorial changes can be managed in GitHub, but any substantial
issues need to be discussed on the COSE mailing list. issues need to be discussed on the COSE mailing list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 12, 2019. This Internet-Draft will expire on February 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . 4 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5
2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Security Considerations . . . . . . . . . . . . . . . 6 2.1.1. Security Considerations . . . . . . . . . . . . . . . 6
2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 7 2.2. Edwards-Curve Digital Signature Algorithms
(EdDSAs) . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Security Considerations . . . . . . . . . . . . . . . 8 2.2.1. Security Considerations . . . . . . . . . . . . . . . 8
3. Message Authentication Code (MAC) Algorithms . . . . . . . . 8 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 8
3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9 3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9
3.1.1. Security Considerations . . . . . . . . . . . . . . . 10 3.1.1. Security Considerations . . . . . . . . . . . . . . . 10
3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 10 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 10
3.2.1. Security Considerations . . . . . . . . . . . . . . . 11 3.2.1. Security Considerations . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . 13
4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Security Considerations . . . . . . . . . . . . . . . 16 4.2.1. Security Considerations . . . . . . . . . . . . . . . 16
4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 16 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 16
4.3.1. Security Considerations . . . . . . . . . . . . . . . 17 4.3.1. Security Considerations . . . . . . . . . . . . . . . 17
5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 17 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 18
5.1. HMAC-Based Extract-and-Expand Key Derivation Function 5.1. HMAC-Based Extract-and-Expand Key Derivation Function
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 18 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Context Information Structure . . . . . . . . . . . . . . 20
5.2. Context Information Structure . . . . . . . . . . . . . . 19 6. Content Key Distribution Methods . . . . . . . . . . . . . . 25
6. Content Key Distribution Methods . . . . . . . . . . . . . . 24 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 25
6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 24 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 24 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 26
6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 25 6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28
6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 27 6.2.1. Security Considerations for AES-KW . . . . . . . . . 29
6.2.1. Security Considerations for AES-KW . . . . . . . . . 28 6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 28 6.3.1. Security Considerations . . . . . . . . . . . . . . . 32
6.3.1. Security Considerations . . . . . . . . . . . . . . . 31 6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 32
6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 31 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 34
7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 33 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 35
7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 33 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 35
7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 34 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 37
7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 35 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 37
7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 36 8. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 38
8. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 39 11.2. Informative References . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . 41 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
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)" [RFC7049]. CBOR extended the data model of the JavaScript (CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript
Object Notation (JSON) [RFC8259] by allowing for binary data, among Object Notation (JSON) [RFC8259] by allowing for binary data, among
other changes. CBOR is being adopted by several of the IETF working other changes. CBOR is being adopted by several of the IETF working
groups dealing with the IoT world as their encoding of data groups dealing with the IoT world as their encoding of data
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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 RFC8152 1.2. Changes from RFC8152
o Extract the sections dealing with specific algorithms into this * Extract the sections dealing with specific algorithms into this
document. The sections dealing with structure and general document. The sections dealing with structure and general
processing rules are placed in [I-D.ietf-cose-rfc8152bis-struct]. processing rules are placed in [I-D.ietf-cose-rfc8152bis-struct].
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 is a synonym for octet. Byte is a synonym for octet.
Constrained Application Protocol (CoAP) is a specialized web transfer Constrained Application Protocol (CoAP) is a specialized web transfer
protocol for use in constrained systems. It is defined in [RFC7252]. protocol for use in constrained systems. It is defined in [RFC7252].
Authenticated Encryption (AE) [RFC5116] algorithms are those Authenticated Encryption (AE) [RFC5116] algorithms are those
encryption algorithms that provide an authentication check of the encryption algorithms that provide an authentication check of the
plain text contents as part of the encryption service. plain text contents as part of the encryption service.
Authenticated Encryption with Authenticated Data (AEAD) [RFC5116] Authenticated Encryption with Associated Data (AEAD) [RFC5116]
algorithms provide the same content authentication service as AE algorithms provide the same content authentication service as AE
algorithms, but they additionally provide for authentication of non- algorithms, but they additionally provide for authentication of non-
encrypted data as well. encrypted data as well.
1.4. CBOR Grammar 1.4. CBOR Grammar
At the time that [RFC8152] was initially published, the CBOR Data At the time that [RFC8152] was initially published, the CBOR Data
Definition Language (CDDL) [I-D.ietf-cbor-cddl] had not yet been Definition Language (CDDL) [RFC8610] had not yet been published.
published. This document uses a variant of CDDL which is described This document uses a variant of CDDL which is described in
in [I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
1.5. Examples 1.5. Examples
A GitHub project has been created at <https://github.com/cose-wg/ A GitHub project has been created at <https://github.com/cose-wg/
Examples> that contains a set of testing examples as well. Each Examples> that contains a set of testing examples as well. Each
example is found in a JSON file that contains the inputs used to example is found in a JSON file that contains the inputs used to
create the example, some of the intermediate values that can be used create the example, some of the intermediate values that can be used
in debugging the example and the output of the example presented in in debugging the example and the output of the example presented in
both a hex and a CBOR diagnostic notation format. Some of the both a hex and a CBOR diagnostic notation format. Some of the
examples at the site are designed failure testing cases; these are examples at the site are designed failure testing cases; these are
clearly marked as such in the JSON file. If errors in the examples clearly marked as such in the JSON file. If errors in the examples
in this document are found, the examples on GitHub will be updated, 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. and a note to that effect will be placed in the JSON file.
2. Signature Algorithms 2. Signature Algorithms
Section 9 of [I-D.ietf-cose-rfc8152bis-struct] Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
signature algorithms. The document defines signature algorithm signature algorithms. The document defines signature algorithm
identifiers for two signature algorithms. identifiers for two signature algorithms.
2.1. ECDSA 2.1. ECDSA
ECDSA [DSS] defines a signature algorithm using ECC. Implementations ECDSA [DSS] defines a signature algorithm using ECC. Implementations
SHOULD use a deterministic version of ECDSA such as the one defined SHOULD use a deterministic version of ECDSA such as the one defined
in [RFC6979]. The use of a deterministic signature algorithm allows in [RFC6979]. The use of a deterministic signature algorithm allows
for systems to avoid relying on random number generators in order to for systems to avoid relying on random number generators in order to
skipping to change at page 5, line 37 skipping to change at page 5, line 37
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
This document defines ECDSA to work only with the curves P-256, This document defines ECDSA to work only with the curves P-256,
P-384, and P-521. This document requires that the curves be encoded P-384, and P-521. This document requires that the curves be encoded
using the 'EC2' (2 coordinate elliptic curve) key type. using the 'EC2' (2 coordinate elliptic curve) key type.
Implementations need to check that the key type and curve are correct Implementations need to check that the key type and curve are correct
when creating and verifying a signature. Other documents can define when creating and verifying a signature. Other documents can define
it to work with other curves and points in the future. it to work with other curves and points in the future.
In order to promote interoperability, it is suggested that SHA-256 be In order to promote interoperability, it is suggested that SHA-256 be
used only with curve P-256, SHA-384 be used only with curve P-384, used only with curve P-256, SHA-384 be used only with curve P-384,
skipping to change at page 6, line 22 skipping to change at page 6, line 24
the signature process. The signature is encoded by converting the the signature process. The signature is encoded by converting the
integers into bit strings of the same length as the key size. The integers into bit strings of the same length as the key size. The
length is rounded up to the nearest byte and is left padded with zero length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length. The two integers are then bits to get to the correct length. The two integers are then
concatenated together to form a byte string that is the resulting concatenated together to form a byte string that is the resulting
signature. signature.
Using the function defined in [RFC8017], the signature is: Using the function defined in [RFC8017], the signature is:
Signature = I2OSP(R, n) | I2OSP(S, n) Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(key_length / 8) where n = ceiling(key_length / 8)
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:
o The 'kty' field MUST be present, and it MUST be 'EC2'. * The 'kty' field MUST be present, and it MUST be 'EC2'.
o 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.
o 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.
o 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
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. testing.
There are two substitution attacks that can theoretically be mounted There are two substitution attacks that can theoretically be mounted
against the ECDSA signature algorithm. against the ECDSA signature algorithm.
o Changing the curve used to validate the signature: If one changes * Changing the curve used to validate the signature: If one changes
the curve used to validate the signature, then potentially one the curve used to validate the signature, then potentially one
could have two messages with the same signature, each computed could have two messages with the same signature, each computed
under a different curve. The only requirement on the new curve is under a different curve. The only requirement on the new curve is
that its order be the same as the old one and it be acceptable to that its order be the same as the old one and it be acceptable to
the client. An example would be to change from using the curve the client. An example would be to change from using the curve
secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit
curves.) We currently do not have any way to deal with this curves.) We currently do not have any way to deal with this
version of the attack except to restrict the overall set of curves version of the attack except to restrict the overall set of curves
that can be used. that can be used.
o Change the hash function used to validate the signature: If one * Change 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 down, then one could potentially find truncate a hash function down, 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. protected header.
2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs)
skipping to change at page 8, line 7 skipping to change at page 8, line 9
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
made: made:
o The 'kty' field MUST be present, and it MUST be 'OKP' (Octet Key * The 'kty' field MUST be present, and it MUST be 'OKP' (Octet Key
Pair). Pair).
o The 'crv' field MUST be present, and it MUST be a curve defined * The 'crv' field MUST be present, and it MUST be a curve defined
for this signature algorithm. for this signature algorithm.
o If the 'alg' field is present, it MUST match 'EdDSA'. * If the 'alg' field is present, it MUST match 'EdDSA'.
o 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.
o 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
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, they and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they
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. Signing and non- cryptographic random number generator is REQUIRED. Signing and non-
batch signature verification are deterministic operations and do not batch signature verification are deterministic operations and do not
need random numbers of any kind. need random numbers of any kind.
3. Message Authentication Code (MAC) Algorithms 3. Message Authentication Code (MAC) Algorithms
Section 10 of [I-D.ietf-cose-rfc8152bis-struct] Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
MAC algorithms. This section defines the conventions for two MAC 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 for new hash attacks. The algorithm was also designed to allow for new hash
algorithms to be directly plugged in without changes to the hash algorithms to be directly plugged in without changes to the hash
function. The HMAC design process has been shown as solid since, function. The HMAC design process has been shown as solid since,
skipping to change at page 9, line 28 skipping to change at page 9, line 28
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 algorithms that is truncated. There environments, we define one HMAC algorithms 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 | Description | | Name | Value | Hash | Tag Length | Description |
| | | | Length | | +=============+=======+=========+============+======================+
+-----------+-------+---------+----------+--------------------------+ | 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 | +-------------+-------+---------+------------+----------------------+
| 384/384 | | | | | | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 |
| HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 | | 384/384 | | | | |
| 512/512 | | | | | +-------------+-------+---------+------------+----------------------+
+-----------+-------+---------+----------+--------------------------+ | HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 |
| 512/512 | | | | |
+-------------+-------+---------+------------+----------------------+
Table 3: HMAC Algorithm Values Table 3: HMAC Algorithm Values
Some recipient algorithms carry the key while others derive a key Some recipient algorithms carry the key while others derive a key
from secret data. For those algorithms that carry the key (such as from secret data. For those algorithms that carry the key (such as
AES Key Wrap), the size of the HMAC key SHOULD be the same size as AES Key Wrap), the size of the HMAC key SHOULD be the same size as
the underlying hash function. For those algorithms that derive the the underlying hash function. For those algorithms that derive the
key (such as ECDH), the derived key MUST be the same size as the key (such as ECDH), the derived key MUST be the same size as the
underlying hash function. underlying hash function.
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:
o The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o If the 'alg' field is present, it MUST match the HMAC algorithm * If the 'alg' field is present, it MUST match the HMAC algorithm
being used. being used.
o 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.
o 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
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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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 IV used. For all of these algorithms, the IV is tag length, and the IV used. For all of these algorithms, the IV is
fixed to all zeros. We provide an array of algorithms for various fixed to all zeros. We provide an array of algorithms for various
key lengths and tag lengths. The algorithms defined in this document key lengths and tag lengths. The algorithms defined in this document
are found in Table 4. are found in Table 4.
+-------------+-------+----------+----------+-----------------------+ +---------+-------+------------+------------+------------------+
| Name | Value | Key | Tag | Description | | Name | Value | Key Length | Tag Length | Description |
| | | Length | Length | | +=========+=======+============+============+==================+
+-------------+-------+----------+----------+-----------------------+ | AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit |
| AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit key, | | 128/64 | | | | key, 64-bit tag |
| 128/64 | | | | 64-bit tag | +---------+-------+------------+------------+------------------+
| AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit key, | | AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit |
| 256/64 | | | | 64-bit tag | | 256/64 | | | | key, 64-bit tag |
| AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit key, | +---------+-------+------------+------------+------------------+
| 128/128 | | | | 128-bit tag | | AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit |
| AES-MAC | 26 | 256 | 128 | AES-MAC 256-bit key, | | 128/128 | | | | key, 128-bit tag |
| 256/128 | | | | 128-bit tag | +---------+-------+------------+------------+------------------+
+-------------+-------+----------+----------+-----------------------+ | AES-MAC | 26 | 256 | 128 | AES-MAC 256-bit |
| 256/128 | | | | key, 128-bit tag |
+---------+-------+------------+------------+------------------+
Table 4: AES-MAC Algorithm Values Table 4: AES-MAC Algorithm Values
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 creating and validating MAC values MUST structure. Implementations creating and validating MAC values 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:
o The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o 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.
o 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.
o 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
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.
o 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
built and signed. (CMAC also addresses this issue.) built and signed. (CMAC also addresses this issue.)
o Cipher Block Chaining (CBC) mode, if the same key is used for both * Cipher Block Chaining (CBC) mode, if the same key is used for both
encryption and authentication operations, an attacker can produce encryption and authentication operations, an attacker can produce
messages with a valid authentication code. messages with a valid authentication code.
o 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 11 of [I-D.ietf-cose-rfc8152bis-struct] Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
Content Encryption algorithms. This document defines the identifier Content Encryption algorithms. This document defines the identifier
and usages for three content encryption algorithms. and usages for three content encryption algorithms.
4.1. AES GCM 4.1. AES GCM
The Galois/Counter Mode (GCM) mode is a generic authenticated The Galois/Counter Mode (GCM) mode is a generic authenticated
encryption block cipher mode defined in [AES-GCM]. The GCM mode is encryption block cipher mode defined in [AES-GCM]. The GCM mode is
combined with the AES block encryption algorithm to define an AEAD combined with the AES block encryption algorithm to define an AEAD
cipher. cipher.
skipping to change at page 12, line 36 skipping to change at page 12, line 38
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
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
that the key type, key length, and algorithm are correct and 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:
o The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o 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.
o 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.
o 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
When using AES-GCM, the following restrictions MUST be enforced: When using AES-GCM, the following restrictions MUST be enforced:
o The key and nonce pair MUST be unique for every message encrypted. * The key and nonce pair MUST be unique for every message encrypted.
o The total amount of data encrypted for a single key MUST NOT * The total amount of data encrypted for a single key MUST NOT
exceed 2^39 - 256 bits. An explicit check is required only in exceed 2^39 - 256 bits. 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.
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.
Doing so drastically changes both the maximum messages size Doing so drastically changes both the maximum messages size
(generally not an issue) and the number of times that a key can be (generally 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 used. Given that Counter with CBC-MAC (CCM) is the usual mode for
constrained environments, restricted modes are not supported. constrained environments, restricted modes are not supported.
skipping to change at page 14, line 18 skipping to change at page 14, line 22
L and M. Constrained devices are usually operating in situations L and M. Constrained devices are usually operating in situations
where they use short messages and want to avoid doing recipient- where they use short messages and want to avoid doing recipient-
specific cryptographic operations. This favors smaller values of specific cryptographic operations. This favors smaller values of
both L and M. Less-constrained devices will want to be able to use both L and M. Less-constrained devices will want to be able to use
larger messages and are more willing to generate new keys for every larger messages and are more willing to generate new keys for every
operation. This favors larger values of L and M. operation. This favors larger values of L and M.
The following values are used for L: The following values are used for L:
16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. 16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length.
This is sufficiently long for messages in the constrained world. This is sufficiently long for messages in the
The nonce length is 13 bytes allowing for 2^104 possible values of constrained world. The nonce length is 13 bytes
the nonce without repeating. allowing for 2^104 possible values of the nonce without
repeating.
64 bits (8): This limits messages to 2^64 bytes in length. The 64 bits (8): This limits messages to 2^64 bytes in length. The
nonce length is 7 bytes allowing for 2^56 possible values of the nonce length is 7 bytes allowing for 2^56 possible
nonce without repeating. values of the nonce without repeating.
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
will authenticate. modified message 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
will authenticate. modified message will authenticate.
+--------------------+-------+----+-----+-----+---------------------+ +--------------------+-------+----+-----+-----+---------------------+
| Name | Value | L | M | k | Description | | Name | Value | L | M | k | Description |
+--------------------+-------+----+-----+-----+---------------------+ +====================+=======+====+=====+=====+=====================+
| 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, 64-bit | | | | | | | 128-bit key, |
| | | | | | tag, 13-byte nonce | | | | | | | 64-bit tag, |
| | | | | | 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, 64-bit | | | | | | | 256-bit key, |
| | | | | | tag, 13-byte nonce | | | | | | | 64-bit tag, |
| | | | | | 13-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode | | AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, 64-bit | | | | | | | 128-bit key, |
| | | | | | tag, 7-byte nonce | | | | | | | 64-bit tag, |
| | | | | | 7-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode | | AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, 64-bit | | | | | | | 256-bit key, |
| | | | | | tag, 7-byte nonce | | | | | | | 64-bit tag, |
| | | | | | 7-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode | | AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, | | | | | | | 128-bit key, |
| | | | | | 128-bit tag, | | | | | | | 128-bit tag, |
| | | | | | 13-byte nonce | | | | | | | 13-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode | | AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, | | | | | | | 256-bit key, |
| | | | | | 128-bit tag, | | | | | | | 128-bit tag, |
| | | | | | 13-byte nonce | | | | | | | 13-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode | | AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, | | | | | | | 128-bit key, |
| | | | | | 128-bit tag, 7-byte | | | | | | | 128-bit tag, |
| | | | | | nonce | | | | | | | 7-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+
| 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, 7-byte | | | | | | | 128-bit tag, |
| | | | | | nonce | | | | | | | 7-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+ +--------------------+-------+----+-----+-----+---------------------+
Table 6: Algorithm Values for AES-CCM Table 6: Algorithm Values for AES-CCM
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
that the key type, key length, and algorithm are correct and 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:
o The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o 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.
o 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.
o 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
When using AES-CCM, the following restrictions MUST be enforced: When using AES-CCM, the following restrictions MUST be enforced:
o 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.
o 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
in environments where it is expected that it might be exceeded. in environments where it is expected that it might be exceeded.
[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 pre-computation attack against the algorithm in is possible to do a pre-computation 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
skipping to change at page 17, line 5 skipping to change at page 17, line 11
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/ 256-bit key, | | ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ |
| | | 128-bit tag | | | | 256-bit key, 128-bit tag |
+-------------------+-------+---------------------------------------+ +-------------------+-------+--------------------------+
Table 7: Algorithm Value for AES-GCM Table 7: Algorithm Value for AES-GCM
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
that the key type, key length, and algorithm are correct and 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:
o The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o 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.
o 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.
o 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
The key and nounce values MUST be a unique pair for every invocation The key and nounce 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.
5. Key Derivation Functions (KDFs) 5. Key Derivation Functions (KDFs)
Section 12 of [I-D.ietf-cose-rfc8152bis-struct] Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
Key Derivation Functions. This document defines a single context Key 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, and process. These algorithms are defined in Sections 6.1.2, 6.3, and
6.4. 6.4.
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]. The HKDF key derivation algorithm is defined in [RFC5869].
skipping to change at page 19, line 5 skipping to change at page 19, line 15
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 | HKDF using HMAC SHA-256 as the | | HKDF SHA-256 | HMAC with SHA-256 | HKDF using HMAC |
| | SHA-256 | PRF | | | | SHA-256 as the PRF |
| HKDF SHA-512 | HMAC with | HKDF using HMAC SHA-512 as the | +--------------+-------------------+------------------------+
| | SHA-512 | PRF | | HKDF SHA-512 | HMAC with SHA-512 | HKDF using HMAC |
| HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as the PRF | | | | SHA-512 as the PRF |
| MAC-128 | | w/ 128-bit key | +--------------+-------------------+------------------------+
| HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as the PRF | | HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as |
| MAC-256 | | w/ 256-bit key | | MAC-128 | | the PRF w/ 128-bit key |
+---------------+-----------------+---------------------------------+ +--------------+-------------------+------------------------+
| HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as |
| 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, direct | Random salt | | salt | -20 | bstr | direct+HKDF-SHA-256, | Random salt |
| | | | +HKDF-SHA-512, direct+HKDF- | | | | | | direct+HKDF-SHA-512, | |
| | | | AES-128, direct+HKDF-AES-256, | | | | | | direct+HKDF-AES-128, | |
| | | | ECDH-ES+HKDF-256, ECDH- | | | | | | direct+HKDF-AES-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | | | | | | ES+HKDF-256, ECDH-ES+HKDF- | |
| | | | SS+HKDF-256, ECDH- | | | | | | 512, ECDH- SS+HKDF-256, | |
| | | | SS+HKDF-512, ECDH-ES+A128KW, | | | | | | ECDH-SS+HKDF-512, ECDH- | |
| | | | ECDH-ES+A192KW, ECDH- | | | | | | ES+A128KW, ECDH-ES+A192KW, | |
| | | | ES+A256KW, ECDH-SS+A128KW, | | | | | | ECDH-ES+A256KW, ECDH- | |
| | | | ECDH-SS+A192KW, ECDH- | | | | | | SS+A128KW, ECDH-SS+A192KW, | |
| | | | SS+A256KW | | | | | | ECDH-SS+A256KW | |
+------+-------+------+-------------------------------+-------------+ +------+-------+------+----------------------------+-------------+
Table 9: HKDF Algorithm Parameters Table 9: HKDF Algorithm Parameters
5.2. Context Information Structure 5.2. Context Information Structure
The context information structure is used to ensure that the derived The context information structure is used to ensure that the derived
keying material is "bound" to the context of the transaction. The keying material is "bound" to the context of the transaction. The
context information structure used here is based on that defined in context information structure used here is based on that defined in
[SP800-56A]. By using CBOR for the encoding of the context [SP800-56A]. By using CBOR for the encoding of the context
information structure, we automatically get the same type and length information structure, we automatically get the same type and length
skipping to change at page 20, line 13 skipping to change at page 20, line 29
application protocol defines differently, we assign PartyU to the application protocol defines differently, we assign PartyU to the
entity that is creating the message and PartyV to the entity that is entity that is creating the message and PartyV to the entity that is
receiving the message. By doing this association, different keys receiving the message. By doing this association, different keys
will be derived for each direction as the context information is will be derived for each direction as the context information is
different in each direction. different in each direction.
The context structure is built from information that is known to both The context structure is built from information that is known to both
entities. This information can be obtained from a variety of entities. This information can be obtained from a variety of
sources: sources:
o Fields can be defined by the application. This is commonly used * Fields can be defined by the application. This is commonly used
to assign fixed names to parties, but it can be used for other to assign fixed names to parties, but it can be used for other
items such as nonces. items such as nonces.
o Fields can be defined by usage of the output. Examples of this * Fields can be defined by usage of the output. Examples of this
are the algorithm and key size that are being generated. are the algorithm and key size that are being generated.
o 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 parameters in Table 10 that can be used to carry the values set of parameters in Table 10 that can be used to carry the values
associated with the context structure. Examples of this are associated with the context structure. Examples of this are
identities and nonce values. These parameters are designed to be identities and nonce values. These parameters are designed to be
placed in the unprotected bucket of the recipient structure; they placed in the unprotected bucket of the recipient structure; they
do not need to be in the protected bucket since they already are do not need to be in the protected bucket since they already are
included in the cryptographic computation by virtue of being included in the cryptographic computation by virtue of being
included in the context structure. 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- | | | | | | ECDH-ES+HKDF-256, | |
| | | | ES+HKDF-512, ECDH- | | | | | | ECDH-ES+HKDF-512, | |
| | | | SS+HKDF-256, ECDH- | | | | | | ECDH- SS+HKDF-256, | |
| | | | SS+HKDF-512, ECDH- | | | | | | ECDH-SS+HKDF-512, | |
| | | | ES+A128KW, ECDH- | | | | | | ECDH-ES+A128KW, | |
| | | | ES+A192KW, ECDH- | | | | | | ECDH-ES+A192KW, | |
| | | | ES+A256KW, ECDH- | | | | | | ECDH-ES+A256KW, | |
| | | | SS+A128KW, ECDH- | | | | | | ECDH-SS+A128KW, | |
| | | | SS+A192KW, ECDH-SS+A256KW | | | | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U | | PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U |
| nonce | | / | direct+HKDF-SHA-512, | provided | | nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce | | | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | | | | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ECDH-ES+HKDF-256, | |
| | | | ES+HKDF-512, ECDH- | | | | | | ECDH-ES+HKDF-512, | |
| | | | SS+HKDF-256, ECDH- | | | | | | ECDH- SS+HKDF-256, | |
| | | | SS+HKDF-512, ECDH- | | | | | | ECDH-SS+HKDF-512, | |
| | | | ES+A128KW, ECDH- | | | | | | ECDH-ES+A128KW, | |
| | | | ES+A192KW, ECDH- | | | | | | ECDH-ES+A192KW, | |
| | | | ES+A256KW, ECDH- | | | | | | ECDH-ES+A256KW, | |
| | | | SS+A128KW, ECDH- | | | | | | ECDH-SS+A128KW, | |
| | | | SS+A192KW, ECDH-SS+A256KW | | | | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U | | PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U |
| other | | | direct+HKDF-SHA-512, | other | | other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided | | | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information | | | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ECDH-ES+HKDF-256, | |
| | | | ES+HKDF-512, ECDH- | | | | | | ECDH-ES+HKDF-512, | |
| | | | SS+HKDF-256, ECDH- | | | | | | ECDH- SS+HKDF-256, | |
| | | | SS+HKDF-512, ECDH- | | | | | | ECDH-SS+HKDF-512, | |
| | | | ES+A128KW, ECDH- | | | | | | ECDH-ES+A128KW, | |
| | | | ES+A192KW, ECDH- | | | | | | ECDH-ES+A192KW, | |
| | | | ES+A256KW, ECDH- | | | | | | ECDH-ES+A256KW, | |
| | | | SS+A128KW, ECDH- | | | | | | ECDH-SS+A128KW, | |
| | | | SS+A192KW, ECDH-SS+A256KW | | | | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V | | PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V |
| 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- | | | | | | ECDH-ES+HKDF-256, | |
| | | | ES+HKDF-512, ECDH- | | | | | | ECDH-ES+HKDF-512, | |
| | | | SS+HKDF-256, ECDH- | | | | | | ECDH- SS+HKDF-256, | |
| | | | SS+HKDF-512, ECDH- | | | | | | ECDH-SS+HKDF-512, | |
| | | | ES+A128KW, ECDH- | | | | | | ECDH-ES+A128KW, | |
| | | | ES+A192KW, ECDH- | | | | | | ECDH-ES+A192KW, | |
| | | | ES+A256KW, ECDH- | | | | | | ECDH-ES+A256KW, | |
| | | | SS+A128KW, ECDH- | | | | | | ECDH-SS+A128KW, | |
| | | | SS+A192KW, ECDH-SS+A256KW | | | | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V | | PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V |
| nonce | | / | direct+HKDF-SHA-512, | provided | | nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce | | | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | | | | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ECDH-ES+HKDF-256, | |
| | | | ES+HKDF-512, ECDH- | | | | | | ECDH-ES+HKDF-512, | |
| | | | SS+HKDF-256, ECDH- | | | | | | ECDH- SS+HKDF-256, | |
| | | | SS+HKDF-512, ECDH- | | | | | | ECDH-SS+HKDF-512, | |
| | | | ES+A128KW, ECDH- | | | | | | ECDH-ES+A128KW, | |
| | | | ES+A192KW, ECDH- | | | | | | ECDH-ES+A192KW, | |
| | | | ES+A256KW, ECDH- | | | | | | ECDH-ES+A256KW, | |
| | | | SS+A128KW, ECDH- | | | | | | ECDH-SS+A128KW, | |
| | | | SS+A192KW, ECDH-SS+A256KW | | | | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V | | PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V |
| other | | | direct+HKDF-SHA-512, | other | | other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided | | | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information | | | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | | | | | | ECDH-ES+HKDF-256, | |
| | | | ES+HKDF-512, ECDH- | | | | | | ECDH-ES+HKDF-512, | |
| | | | SS+HKDF-256, ECDH- | | | | | | ECDH- SS+HKDF-256, | |
| | | | SS+HKDF-512, ECDH- | | | | | | ECDH-SS+HKDF-512, | |
| | | | ES+A128KW, ECDH- | | | | | | ECDH-ES+A128KW, | |
| | | | ES+A192KW, ECDH- | | | | | | ECDH-ES+A192KW, | |
| | | | ES+A256KW, ECDH- | | | | | | ECDH-ES+A256KW, | |
| | | | SS+A128KW, ECDH- | | | | | | ECDH-SS+A128KW, | |
| | | | SS+A192KW, ECDH-SS+A256KW | | | | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+ +----------+-------+------+---------------------------+-------------+
Table 10: Context Algorithm Parameters Table 10: Context Algorithm Parameters
We define a CBOR object to hold the context information. This object We define a CBOR object to hold the context information. This object
is referred to as COSE_KDF_Context. The object is based on a CBOR is referred to as COSE_KDF_Context. The object is based on a CBOR
array type. The fields in the array are: array type. The fields in the array are:
AlgorithmID: This field indicates the algorithm for which the key AlgorithmID: This field indicates the algorithm for which the key
material will be used. This normally is either a key wrap material will be used. This normally is either a key
algorithm identifier or a content encryption algorithm identifier. wrap algorithm identifier or a content encryption
The values are from the "COSE Algorithms" registry. This field is algorithm identifier. The values are from the "COSE
required to be present. The field exists in the context Algorithms" registry. This field is required to be
information so that if the same environment is used for different present. The field exists in the context information
algorithms, then completely different keys will be generated for so that if the same environment is used for different
each of those algorithms. This practice means if algorithm A is algorithms, then completely different keys will be
broken and thus is easier to find, the key derived for algorithm B generated for each of those algorithms. This practice
will not be the same as the key derived for algorithm A. means if algorithm A is broken and thus is easier to
find, the key derived for algorithm B will not be the
same as the key derived for algorithm A.
PartyUInfo: This field holds information about party U. The PartyUInfo: This field holds information about party U. The
PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo PartyUInfo is encoded as a CBOR array. The elements
are encoded in the order presented. The elements of the of PartyUInfo are encoded in the order presented. The
PartyUInfo array are: elements of the PartyUInfo array are:
identity: This contains the identity information for party U. identity: This contains the identity information for
The identities can be assigned in one of two manners. First, a party U. The identities can be assigned in
protocol can assign identities based on roles. For example, one of two manners. First, a protocol can
the roles of "client" and "server" may be assigned to different assign identities based on roles. For
entities in the protocol. Each entity would then use the example, the roles of "client" and "server"
correct label for the data they send or receive. The second may be assigned to different entities in
way for a protocol to assign identities is to use a name based the protocol. Each entity would then use
on a naming system (i.e., DNS, X.509 names). the correct label for the data they send or
receive. The second way for a protocol to
assign identities is to use a name based on
a naming system (i.e., DNS, X.509 names).
We define an algorithm parameter 'PartyU identity' that can be We define an algorithm parameter 'PartyU
used to carry identity information in the message. However, identity' that can be used to carry
identity information is often known as part of the protocol and identity information in the message.
can thus be inferred rather than made explicit. If identity However, identity information is often
information is carried in the message, applications SHOULD have known as part of the protocol and can thus
a way of validating the supplied identity information. The be inferred rather than made explicit. If
identity information does not need to be specified and is set identity information is carried in the
to nil in that case. message, applications SHOULD have a way of
validating the supplied identity
information. The identity information does
not need to be specified and is set to nil
in that case.
nonce: This contains a nonce value. The nonce can either be nonce: This contains a nonce value. The nonce can
implicit from the protocol or be carried as a value in the either be implicit from the protocol or be
unprotected headers. carried as a value in the unprotected
headers.
We define an algorithm parameter 'PartyU nonce' that can be We define an algorithm parameter 'PartyU
used to carry this value in the message; however, the nonce nonce' that can be used to carry this value
value could be determined by the application and the value in the message; however, the nonce value
determined from elsewhere. could be determined by the application and
the value determined from elsewhere.
This option does not need to be specified and is set to nil in This option does not need to be specified
that case. and is set to nil in that case.
other: This contains other information that is defined by the other: This contains other information that is
protocol. This option does not need to be specified and is set defined by the protocol. This option does
to nil in that case. not need to be specified and is set to nil
in that case.
PartyVInfo: This field holds information about party V. The content PartyVInfo: This field holds information about party V. The
of the structure is the same as for the PartyUInfo but for party content of the structure is the same as for the
V. PartyUInfo but for party V.
SuppPubInfo: This field contains public information that is mutually SuppPubInfo: This field contains public information that is
known to both parties. mutually known to both parties.
keyDataLength: This is set to the number of bits of the desired keyDataLength: This is set to the number of bits of
output value. This practice means if algorithm A can use two the desired output value. This
different key lengths, the key derived for longer key size will practice means if algorithm A can use
not contain the key for shorter key size as a prefix. two different key lengths, the key
derived for longer key size will not
contain the key for shorter key size
as a prefix.
protected: This field contains the protected parameter field. If protected: This field contains the protected
there are no elements in the protected field, then use a zero- parameter field. If there are no
length bstr. elements in the protected field, then
use a zero-length bstr.
other: This field is for free form data defined by the other: This field is for free form data
application. An example is that an application could define defined by the application. An
two different strings to be placed here to generate different example is that an application could
keys for a data stream versus a control stream. This field is define two different strings to be
optional and will only be present if the application defines a placed here to generate different keys
structure for this information. Applications that define this for a data stream versus a control
SHOULD use CBOR to encode the data so that types and lengths stream. This field is optional and
are correctly included. will only be present if the
application defines a structure for
this information. Applications that
define this SHOULD use CBOR to encode
the data so that types and lengths are
correctly included.
SuppPrivInfo: This field contains private information that is SuppPrivInfo: This field contains private information that is
mutually known private information. An example of this mutually known private information. An example of
information would be a preexisting shared secret. (This could, this information would be a preexisting shared secret.
for example, be used in combination with an ECDH key agreement to (This could, for example, be used in combination with
provide a secondary proof of identity.) The field is optional and an ECDH key agreement to provide a secondary proof of
will only be present if the application defines a structure for identity.) The field is optional and will only be
this information. Applications that define this SHOULD use CBOR present if the application defines a structure for
to encode the data so that types and lengths are correctly this information. Applications that define this
included. SHOULD use CBOR to encode the data so that types and
lengths are correctly included.
The following CDDL fragment corresponds to the text above. The following CDDL fragment corresponds to the text above.
PartyInfo = ( PartyInfo = (
identity : bstr / nil, identity : bstr / nil,
nonce : bstr / int / nil, nonce : bstr / int / nil,
other : bstr / nil other : bstr / nil
) )
COSE_KDF_Context = [ COSE_KDF_Context = [
skipping to change at page 24, line 33 skipping to change at page 25, line 33
SuppPubInfo : [ SuppPubInfo : [
keyDataLength : uint, keyDataLength : uint,
protected : empty_or_serialized_map, protected : empty_or_serialized_map,
? other : bstr ? other : bstr
], ],
? SuppPrivInfo : bstr ? SuppPrivInfo : bstr
] ]
6. Content Key Distribution Methods 6. Content Key Distribution Methods
Section 13 of [I-D.ietf-cose-rfc8152bis-struct] Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
content key distribution methods. This document defines the content key distribution methods. This document defines the
identifiers and usage for a number of content key distribution identifiers and usage for a number of content key distribution
methods. methods.
6.1. Direct Encryption 6.1. Direct Encryption
Direct encryption algorithm is defined in Section 13.1 of [I-D.ietf- Direct encryption algorithm is defined in Section 9.5.1 of
cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]. [I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct].
Information about how to fill in the COSE_Recipient structure are Information about how to fill in the COSE_Recipient structure are
detailed there. 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 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
This recipient algorithm has several potential problems that need to This recipient algorithm has several potential problems that need to
be considered: be considered:
o 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.
o These keys need to be dedicated to a single algorithm. There have * These keys need to be dedicated to a single algorithm. There have
been a number of attacks developed over time when a single key is been a number of attacks developed over time when a single key is
used for multiple different algorithms. One example of this is used for multiple different algorithms. One example of this is
the use of a single key for both the CBC encryption mode and the the use of a single key for both the CBC encryption mode and the
CBC-MAC authentication mode. CBC-MAC authentication mode.
o Breaking one message means all messages are broken. If an * Breaking one message means all messages are broken. If an
adversary succeeds in determining the key for a single message, adversary succeeds in determining the key for a single message,
then the key for all messages is also determined. then the key for all messages is also determined.
6.1.2. Direct Key with KDF 6.1.2. Direct Key with KDF
These recipient algorithms take a common shared secret between the These recipient algorithms take a common shared secret between the
two parties and applies the HKDF function (Section 5.1), using the two parties and applies the HKDF function (Section 5.1), using the
context structure defined in Section 5.2 to transform the shared context structure defined in Section 5.2 to transform the shared
secret into the CEK. The 'protected' field can be of non-zero secret into the CEK. The 'protected' field can be of non-zero
length. Either the 'salt' parameter of HKDF or the 'PartyU nonce' length. Either the 'salt' parameter of HKDF or the 'PartyU nonce'
skipping to change at page 26, line 22 skipping to change at page 27, line 22
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".
When these algorithms are used, the key type MUST be 'symmetric'. When these algorithms are used, the key type MUST be 'symmetric'.
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 | Shared secret w/ HKDF | | direct+HKDF-SHA-256 | -10 | HKDF SHA-256 | Shared secret w/ |
| | | SHA-256 | and SHA-256 | | | | | HKDF and SHA-256 |
| direct+HKDF-SHA-512 | -11 | HKDF | Shared secret w/ HKDF | +---------------------+-------+--------------+---------------------+
| | | SHA-512 | and SHA-512 | | direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ |
| direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ AES- | | | | | HKDF and SHA-512 |
| | | MAC-128 | MAC 128-bit key | +---------------------+-------+--------------+---------------------+
| direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ AES- | | direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ |
| | | MAC-256 | MAC 256-bit key | | | | MAC-128 | AES-MAC 128-bit key |
+---------------------+-------+-------------+-----------------------+ +---------------------+-------+--------------+---------------------+
| direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ |
| | | MAC-256 | AES-MAC 256-bit key |
+---------------------+-------+--------------+---------------------+
Table 12: Direct Key with KDF Table 12: Direct Key with KDF
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:
o The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o 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.
o 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
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
skipping to change at page 27, line 31 skipping to change at page 28, line 37
field MUST be empty. field MUST be empty.
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
that the key type, key length, and algorithm are correct and 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:
o The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o 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.
o 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.
o 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
6.2.1. Security Considerations for AES-KW 6.2.1. Security Considerations for AES-KW
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 is the basis of trust. over time. The shared secret is the basis of trust.
6.3. Direct ECDH 6.3. 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:
o Curve Type/Curve: The curve selected controls not only the size of * Curve Type/Curve: The curve selected controls not only the size of
the shared secret, but the mathematics for computing the shared the shared secret, but the mathematics for computing the shared
secret. The curve selected also controls how a point in the curve secret. The curve selected also controls how a point in the curve
is represented and what happens for the identity points on the is represented and what happens for the identity points on the
curve. In this specification, we allow for a number of different curve. In this specification, we allow for a number of different
curves to be used. A set of curves are defined in Table 18. curves to be used. A set of curves are defined in Table 18.
The math used to obtain the computed secret is based on the curve The math used to obtain the computed secret is based on the curve
selected and not on the ECDH algorithm. For this reason, a new selected and not on the ECDH algorithm. For this reason, a new
algorithm does not need to be defined for each of the curves. algorithm does not need to be defined for each of the curves.
o Computed Secret to Shared Secret: Once the computed secret is * Computed Secret to Shared Secret: Once the computed secret is
known, the resulting value needs to be converted to a byte string known, the resulting value needs to be converted to a byte string
to run the KDF. The x-coordinate is used for all of the curves to run the KDF. The x-coordinate is used for all of the curves
defined in this document. For curves X25519 and X448, the defined in this document. For curves X25519 and X448, the
resulting value is used directly as it is a byte string of a known resulting value is used directly as it is a byte string of a known
length. For the P-256, P-384, and P-521 curves, the x-coordinate length. For the P-256, P-384, and P-521 curves, the x-coordinate
is run through the I2OSP function defined in [RFC8017], using the is run through the I2OSP function defined in [RFC8017], using the
same computation for n as is defined in Section 2.1. same computation for n as is defined in Section 2.1.
o Ephemeral-Static or Static-Static: The key agreement process may * Ephemeral-Static or Static-Static: The key agreement process may
be done using either a static or an ephemeral key for the sender's be 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 either the create a unique value. For the KDFs used, this means either the
'salt' parameter for HKDF (Table 9) or the 'PartyU nonce' 'salt' parameter for HKDF (Table 9) or the 'PartyU nonce'
parameter for the context structure (Table 10) MUST be present parameter for the context structure (Table 10) MUST be present
(both can be present if desired). The value in the parameter MUST (both can be present if desired). The value in the parameter MUST
be unique for the pair of keys being used. It is acceptable to be unique for the pair of keys being used. It is acceptable to
use a global counter that is incremented for every static-static use a global counter that is incremented for every static-static
operation and use the resulting value. When using static keys, operation and use the resulting value. When using static keys,
the static key should be identified to the recipient. The static the static key should be identified to the recipient. The static
key can be identified either by providing the key ('static key') key can be identified either by providing the key ('static key')
or by providing a key identifier for the static key ('static key or by providing a key identifier for the static key ('static key
id'). Both of these parameters are defined in Table 15. id'). Both of these parameters are defined in Table 15.
o 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.
o Key Wrap Algorithm: No key wrap algorithm is used. This is * Key Wrap Algorithm: No key wrap algorithm is used. This is
represented in Table 14 as 'none'. The key size for the context represented in Table 14 as 'none'. The key size for the context
structure is the content layer encryption algorithm size. structure is the content layer encryption algorithm size.
COSE does not have an Ephemeral-Ephemeral version defined. The COSE does not have an Ephemeral-Ephemeral version defined. The
reason for this is that COSE is not an an online protocol by itself reason for this is that COSE is not an an online protocol by itself
and thus does not have a method to establish ephemeral secrets on and thus does not have a method to establish ephemeral secrets on
both sides. The expectation is that a protocol would establish the both 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/ | | ECDH-ES | -25 | HKDF - | yes | none | ECDH ES w/ HKDF |
| HKDF-256 | | SHA-256 | | | HKDF - | | + | | SHA-256 | | | - generate key |
| | | | | | generate key | | HKDF-256 | | | | | directly |
| | | | | | directly | +-----------+-------+---------+------------+------+-----------------+
| ECDH-ES + | -26 | HKDF - | yes | none | ECDH ES w/ | | ECDH-ES | -26 | HKDF - | yes | none | ECDH ES w/ HKDF |
| HKDF-512 | | SHA-512 | | | HKDF - | | + | | SHA-512 | | | - generate key |
| | | | | | generate key | | HKDF-512 | | | | | directly |
| | | | | | directly | +-----------+-------+---------+------------+------+-----------------+
| ECDH-SS + | -27 | HKDF - | no | none | ECDH SS w/ | | ECDH-SS | -27 | HKDF - | no | none | ECDH SS w/ HKDF |
| HKDF-256 | | SHA-256 | | | HKDF - | | + | | SHA-256 | | | - generate key |
| | | | | | generate key | | HKDF-256 | | | | | directly |
| | | | | | directly | +-----------+-------+---------+------------+------+-----------------+
| ECDH-SS + | -28 | HKDF - | no | none | ECDH SS w/ | | ECDH-SS | -28 | HKDF - | no | none | ECDH SS w/ HKDF |
| HKDF-512 | | SHA-512 | | | HKDF - | | + | | SHA-512 | | | - generate key |
| | | | | | generate key | | HKDF-512 | | | | | directly |
| | | | | | 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 | +-----------+-------+----------+-------------------+-------------+
| key | | | ECDH-SS+HKDF-512, | public key | | static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static |
| | | | ECDH-SS+A128KW, | for the | | key | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A192KW, | sender | | | | | ECDH-SS+A128KW, | for the |
| | | | ECDH-SS+A256KW | | | | | | ECDH- SS+A192KW, | sender |
| static | -3 | bstr | ECDH-SS+HKDF-256, | Static | | | | | ECDH-SS+A256KW | |
| key id | | | ECDH-SS+HKDF-512, | public key | +-----------+-------+----------+-------------------+-------------+
| | | | ECDH-SS+A128KW, | identifier | | static | -3 | bstr | ECDH-SS+HKDF-256, | Static |
| | | | ECDH-SS+A192KW, | for the | | key id | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A256KW | sender | | | | | ECDH-SS+A128KW, | identifier |
+-----------+-------+----------+---------------------+--------------+ | | | | ECDH- SS+A192KW, | for the |
| | | | ECDH-SS+A256KW | sender |
+-----------+-------+----------+-------------------+-------------+
Table 15: ECDH Algorithm Parameters Table 15: ECDH Algorithm Parameters
This document defines these algorithms to be used with the curves This document defines these algorithms to be used with the curves
P-256, P-384, P-521, X25519, and X448. Implementations MUST verify P-256, P-384, P-521, X25519, and X448. Implementations MUST verify
that the key type and curve are correct. Different curves are that the key type and curve are correct. Different curves are
restricted to different key types. Implementations MUST verify that restricted to different key types. Implementations MUST verify that
the curve and algorithm are appropriate for the entities involved. the curve and algorithm are 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:
o The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'.
o 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.
o 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.
o 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. Security Considerations 6.3.1. Security Considerations
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
skipping to change at page 31, line 49 skipping to change at page 33, line 5
(either by the end user or by the entity that is responsible for (either by the end user or by the entity that is responsible for
making trust statements on keys). making trust statements on keys).
6.4. ECDH with Key Wrap 6.4. ECDH with Key Wrap
These algorithms are defined in Table 16. These algorithms are defined in Table 16.
ECDH with Key Agreement is parameterized by the same parameters as ECDH with Key Agreement is parameterized by the same parameters as
for ECDH; see Section 6.3, with the following modifications: for ECDH; see Section 6.3, with the following modifications:
o 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/ |
| A128KW | | SHA-256 | | | Concat KDF | | + | | SHA-256 | | | Concat KDF and |
| | | | | | and AES Key | | A128KW | | | | | AES Key Wrap |
| | | | | | Wrap w/ | | | | | | | w/ 128-bit key |
| | | | | | 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 |
| A192KW | | SHA-256 | | | Concat KDF | | A192KW | | | | | AES Key Wrap |
| | | | | | and AES Key | | | | | | | w/ 192-bit key |
| | | | | | Wrap w/ | +---------+-------+---------+------------+--------+----------------+
| | | | | | 192-bit key | | ECDH-ES | -31 | HKDF - | yes | A256KW | ECDH ES w/ |
| | | | | | | | + | | SHA-256 | | | Concat KDF and |
| ECDH-ES + | -31 | HKDF - | yes | A256KW | ECDH ES w/ | | A256KW | | | | | AES Key Wrap |
| A256KW | | SHA-256 | | | Concat KDF | | | | | | | w/ 256-bit key |
| | | | | | and AES Key | +---------+-------+---------+------------+--------+----------------+
| | | | | | Wrap w/ | | ECDH-SS | -32 | HKDF - | no | A128KW | ECDH SS w/ |
| | | | | | 256-bit key | | + | | SHA-256 | | | Concat KDF and |
| | | | | | | | A128KW | | | | | AES Key Wrap |
| ECDH-SS + | -32 | HKDF - | no | A128KW | ECDH SS w/ | | | | | | | w/ 128-bit key |
| A128KW | | SHA-256 | | | Concat KDF | +---------+-------+---------+------------+--------+----------------+
| | | | | | and AES Key | | ECDH-SS | -33 | HKDF - | no | A192KW | ECDH SS w/ |
| | | | | | Wrap w/ | | + | | SHA-256 | | | Concat KDF and |
| | | | | | 128-bit key | | A192KW | | | | | AES Key Wrap |
| | | | | | | | | | | | | w/ 192-bit key |
| ECDH-SS + | -33 | HKDF - | no | A192KW | ECDH SS w/ | +---------+-------+---------+------------+--------+----------------+
| A192KW | | SHA-256 | | | Concat KDF | | ECDH-SS | -34 | HKDF - | no | A256KW | ECDH SS w/ |
| | | | | | and AES Key | | + | | SHA-256 | | | Concat KDF and |
| | | | | | Wrap w/ | | A256KW | | | | | AES Key Wrap |
| | | | | | 192-bit key | | | | | | | w/ 256-bit key |
| | | | | | | +---------+-------+---------+------------+--------+----------------+
| ECDH-SS + | -34 | HKDF - | no | A256KW | ECDH SS w/ |
| A256KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 256-bit key |
+-----------+-------+---------+------------+--------+---------------+
Table 16: ECDH Algorithm Values with Key Wrap Table 16: ECDH Algorithm Values with Key Wrap
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:
o The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'.
o 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.
o 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.
o 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.
7. Key Object Parameters 7. Key Object Parameters
The COSE_Key object defines a way to hold a single key object. It is The COSE_Key object defines a way to hold a single key object. It is
still required that the members of individual key types be defined. still required that the members of individual key types be defined.
This section of the document is where we define an initial set of This section of the document is where we define an initial set of
members for specific key types. members for specific key types.
For each of the key types, we define both public and private members. For each of the key types, we define both public and private members.
skipping to change at page 33, line 35 skipping to change at page 34, line 33
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/ x- and y-coordinate | +-----------+-------+--------------------------+
| | | pair | | EC2 | 2 | Elliptic Curve Keys w/ |
| Symmetric | 4 | Symmetric Keys | | | | x- and y-coordinate pair |
| Reserved | 0 | This value is reserved | +-----------+-------+--------------------------+
+-----------+-------+-----------------------------------------------+ | Symmetric | 4 | Symmetric Keys |
+-----------+-------+--------------------------+
| Reserved | 0 | This value is reserved |
+-----------+-------+--------------------------+
Table 17: Key Type Values Table 17: Key Type Values
7.1. Elliptic Curve Keys 7.1. Elliptic Curve Keys
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 |
+---------+-------+----------+------------------------------------+
| X448 | 5 | OKP | X448 for use w/ ECDH only | | X448 | 5 | OKP | X448 for use w/ ECDH only |
+---------+-------+----------+------------------------------------+
| Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only | | Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only |
+---------+-------+----------+------------------------------------+
| Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only | | Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only |
+---------+-------+----------+------------------------------------+ +---------+-------+----------+------------------------------------+
Table 18: Elliptic Curves Table 18: Elliptic Curves
7.1.1. Double Coordinate Curves 7.1.1. Double Coordinate Curves
The traditional way of sending ECs has been to send either both the The traditional way of sending ECs has been to send either both the
x-coordinate and y-coordinate or the x-coordinate and a sign bit for x-coordinate and y-coordinate or the x-coordinate and a sign bit for
the y-coordinate. The latter encoding has not been recommended in the y-coordinate. The latter encoding has not been recommended in
the IETF due to potential IPR issues. However, for operations in the IETF due to potential IPR issues. However, for operations in
constrained environments, the ability to shrink a message by not constrained environments, the ability to shrink a message by not
sending the y-coordinate is potentially useful. sending the y-coordinate is potentially useful.
For EC keys with both coordinates, the 'kty' member is set to 2 For EC keys with both coordinates, the 'kty' member is set to 2
(EC2). The key parameters defined in this section are summarized in (EC2). The key parameters defined in this section are summarized in
Table 19. The members that are defined for this key type are: Table 19. The members that are defined for this key type are:
crv: This contains an identifier of the curve to be used with the crv: This contains an identifier of the curve to be used with the
key. The curves defined in this document for this key type can key. The curves defined in this document for this key type can
be found in Table 18. Other curves may be registered in the be found in Table 18. Other curves may be registered in the
future, and private curves can be used as well. future, and private curves can be used as well.
x: This contains the x-coordinate for the EC point. The integer is x: This contains the x-coordinate for the EC point. The integer is
converted to an octet string as defined in [SEC1]. Leading zero converted to an octet string as defined in [SEC1]. Leading zero
octets MUST be preserved. octets MUST be preserved.
y: This contains either the sign bit or the value of the y: This contains either the sign bit or the value of the
y-coordinate for the EC point. When encoding the value y, the y-coordinate for the EC point. When encoding the value y, the
skipping to change at page 35, line 17 skipping to change at page 36, line 30
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 | y | -3 | bstr / | y-coordinate | | 2 | x | -2 | bstr | x-coordinate |
| | | | bool | | +------+------+-------+--------+---------------------------------+
| 2 | d | -4 | bstr | Private key | | 2 | y | -3 | bstr / | y-coordinate |
+-------+------+-------+--------+-----------------------------------+ | | | | bool | |
+------+------+-------+--------+---------------------------------+
| 2 | d | -4 | bstr | Private key |
+------+------+-------+--------+---------------------------------+
Table 19: EC Key Parameters Table 19: EC Key Parameters
7.2. Octet Key Pair 7.2. Octet Key Pair
A new key type is defined for Octet Key Pairs (OKP). Do not assume A new key type is defined for Octet Key Pairs (OKP). Do not assume
that keys using this type are elliptic curves. This key type could that keys using this type are elliptic curves. This key type could
be used for other curve types (for example, mathematics based on be used for other curve types (for example, mathematics based on
hyper-elliptic surfaces). hyper-elliptic surfaces).
The key parameters defined in this section are summarized in The key parameters defined in this section are summarized in
Table 20. The members that are defined for this key type are: Table 20. The members that are defined for this key type are:
crv: This contains an identifier of the curve to be used with the crv: This contains an identifier of the curve to be used with the
key. The curves defined in this document for this key type can key. The curves defined in this document for this key type can
be found in Table 18. Other curves may be registered in the be found in Table 18. Other curves may be registered in the
future and private curves can be used as well. future and private curves can be used as well.
x: This contains the x-coordinate for the EC point. The octet x: This contains the x-coordinate for the EC point. The octet
string represents a little-endian encoding of x. string represents a little-endian encoding of x.
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 | x-coordinate | +------+----------+-------+-------+---------------------------------+
| d | 1 | -4 | bstr | Private key | | x | 1 | -2 | bstr | x-coordinate |
+------+-------+-------+--------+-----------------------------------+ +------+----------+-------+-------+---------------------------------+
| d | 1 | -4 | bstr | Private key |
+------+----------+-------+-------+---------------------------------+
Table 20: Octet Key Pair Parameters Table 20: Octet Key Pair Parameters
7.3. Symmetric Keys 7.3. Symmetric Keys
Occasionally it is required that a symmetric key be transported Occasionally it is required that a symmetric key be transported
between entities. This key structure allows for that to happen. between entities. This key structure allows for that to happen.
For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The
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. CBOR Encoding Restrictions 8. CBOR Encoding Restrictions
There has been an attempt to limit the number of places where the There has been an attempt to limit the number of places where the
document needs to impose restrictions on how the CBOR Encoder needs document needs to impose restrictions on how the CBOR Encoder needs
to work. We have managed to narrow it down to the following to work. We have managed to narrow it down to the following
restrictions: restrictions:
o The restriction applies to the encoding of the COSE_KDF_Context. * The restriction applies to the encoding of the COSE_KDF_Context.
o Encoding MUST be done using definite lengths and the length of the * Encoding MUST be done using definite lengths and the length of the
MUST be the minimum possible length. This means that the integer MUST be the minimum possible length. This means that the integer
1 is encoded as "0x01" and not "0x1801". 1 is encoded as "0x01" and not "0x1801".
o 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 fail the parse step or by requirement by using parsers that will fail the parse step or by
using parsers that will pass all keys to the application, and the using parsers that will pass all keys to the application, and the
application can perform the check for duplicate keys. application can perform the check for duplicate keys.
9. IANA Considerations 9. IANA Considerations
There are no IANA actions. The required actions are in There are no IANA actions. The required actions are in
skipping to change at page 37, line 37 skipping to change at page 39, line 18
into account by implementers of this specification. The security into account by implementers of this specification. The security
considerations that are specific to an individual algorithm are considerations that are specific to an individual algorithm are
placed next to the description of the algorithm. While some placed next to the description of the algorithm. While some
considerations have been highlighted here, additional considerations considerations have been highlighted here, additional considerations
may be found in the documents listed in the references. may be found in the documents listed in the references.
Implementations need to protect the private key material for any Implementations need to protect the private key material for any
individuals. There are some cases in this document that need to be individuals. There are some cases in this document that need to be
highlighted on this issue. highlighted on this issue.
o Using the same key for two different algorithms can leak * Using the same key for two different algorithms can leak
information about the key. It is therefore recommended that keys information about the key. It is therefore recommended that keys
be restricted to a single algorithm. be restricted to a single algorithm.
o Use of 'direct' as a recipient algorithm combined with a second * Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm exposes the direct key to the second recipient algorithm exposes the direct key to the second
recipient. recipient.
o Several of the algorithms in this document have limits on the * Several of the algorithms in this document have limits on the
number of times that a key can be used without leaking information number of times that a key can be used without leaking information
about the key. about the key.
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
skipping to change at page 38, line 33 skipping to change at page 40, line 14
correct, the key form needs to be checked as well. Do not use an correct, the key form needs to be checked as well. Do not use an
'EC2' key where an 'OKP' key is expected. '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 of the ones that are highlighted here with this trust decision. Some of the ones that are highlighted here
are: are:
o What are the permissions associated with the key owner? * What are the permissions associated with the key owner?
o Is the cryptographic algorithm acceptable in the current context? * Is the cryptographic algorithm acceptable in the current context?
o 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?
o 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?
o 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' 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 either for a key or for some other conditions. In all unique value either for a key or for some other conditions. In all
of these cases, there is no known requirement on the nonce being both of 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
skipping to change at page 39, line 26 skipping to change at page 41, line 7
up to the applications to document how content padding is to be done up to the applications to document how content padding is to be done
in order to prevent or discourage such analysis. (For example, the in order to prevent or discourage such analysis. (For example, the
strings could be defined as 'YES' and 'NO '.) strings could be defined as 'YES' and 'NO '.)
11. References 11. References
11.1. Normative References 11.1. Normative References
[AES-GCM] National Institute of Standards and Technology, [AES-GCM] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST Special Galois/Counter Mode (GCM) and GMAC",
Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November DOI 10.6028/NIST.SP.800-38D, NIST Special
2007, <https://csrc.nist.gov/publications/nistpubs/800- Publication 800-38D, November 2007,
38D/SP-800-38D.pdf>. <https://csrc.nist.gov/publications/nistpubs/800-38D/SP-
800-38D.pdf>.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4, Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013, FIPS PUB 186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR CBOR Object Signing and Encryption Schaad, J., "CBOR Object Signing and Encryption (COSE):
(COSE): Structures and Process", draft-ietf-cose- Structures and Process", draft-ietf-cose-rfc8152bis-
rfc8152bis-struct-02 (work in progress), March 2019. struct-05 (work in progress), August 18, 2019,
<https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-struct-05>.
[MAC] National Institute of Standards and Technology, "Computer [MAC] National Institute of Standards and Technology, "Computer
Data Authentication", FIPS PUB 113, May 1985, Data Authentication", FIPS PUB 113, May 1985,
<http://csrc.nist.gov/publications/fips/fips113/ <http://csrc.nist.gov/publications/fips/fips113/
fips113.html>. fips113.html>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 40, line 44 skipping to change at page 42, line 26
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<http://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Standards for Efficient Cryptography, Version 2.0, May May 2009, <http://www.secg.org/sec1-v2.pdf>.
2009, <http://www.secg.org/sec1-v2.pdf>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor-
cddl-08 (work in progress), March 2019.
[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>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
skipping to change at page 42, line 14 skipping to change at page 43, line 38
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[SP800-56A] [SP800-56A]
Barker, E., Chen, L., Roginsky, A., and M. Smid, Barker, E., Chen, L., Roginsky, A., and M. Smid,
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special Using Discrete Logarithm Cryptography",
Publication 800-56A, Revision 2, DOI 10.6028/NIST.SP.800-56Ar2, NIST Special Publication
DOI 10.6028/NIST.SP.800-56Ar2, May 2013, 800-56A, Revision 2, May 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>. NIST.SP.800-56Ar2.pdf>.
Acknowledgments Acknowledgments
This document is a product of the COSE working group of the IETF. This document is a product of the COSE working group of the IETF.
The following individuals are to blame for getting me started on this The following individuals are to blame for getting me started on this
project in the first place: Richard Barnes, Matt Miller, and Martin project in the first place: Richard Barnes, Matt Miller, and Martin
Thomson. Thomson.
 End of changes. 183 change blocks. 
497 lines changed or deleted 572 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/