draft-ietf-cose-rfc8152bis-algs-07.txt   draft-ietf-cose-rfc8152bis-algs-08.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 9 March 2020 Obsoletes: 8152 (if approved) 14 May 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 10 September 2020 Expires: 15 November 2020
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-07 draft-ietf-cose-rfc8152bis-algs-08
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 2, line 10 skipping to change at page 2, line 10
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 10 September 2020. This Internet-Draft will expire on 15 November 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5
2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Security Considerations . . . . . . . . . . . . . . . 7 2.1.1. Security Considerations . . . . . . . . . . . . . . . 7
2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 8 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 8
2.2.1. Security Considerations . . . . . . . . . . . . . . . 9 2.2.1. Security Considerations . . . . . . . . . . . . . . . 9
3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9
3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9 3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9
3.1.1. Security Considerations . . . . . . . . . . . . . . . 11 3.1.1. Security Considerations . . . . . . . . . . . . . . . 11
3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11
3.2.1. Security Considerations . . . . . . . . . . . . . . . 12 3.2.1. Security Considerations . . . . . . . . . . . . . . . 12
4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12
4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Security Considerations . . . . . . . . . . . . . . . 13 4.1.1. Security Considerations . . . . . . . . . . . . . . . 13
4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Security Considerations . . . . . . . . . . . . . . . 17 4.2.1. Security Considerations . . . . . . . . . . . . . . . 17
4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 17 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 18
4.3.1. Security Considerations . . . . . . . . . . . . . . . 18 4.3.1. Security Considerations . . . . . . . . . . . . . . . 18
5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 18 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 19
5.1. HMAC-Based Extract-and-Expand Key Derivation Function 5.1. HMAC-Based Extract-and-Expand Key Derivation Function
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 19 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Context Information Structure . . . . . . . . . . . . . . 20 5.2. Context Information Structure . . . . . . . . . . . . . . 21
6. Content Key Distribution Methods . . . . . . . . . . . . . . 25 6. Content Key Distribution Methods . . . . . . . . . . . . . . 26
6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 26 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 26
6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 26 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 27
6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 27 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 28
6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 29 6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. Security Considerations for AES-KW . . . . . . . . . 29 6.2.1. Security Considerations for AES-KW . . . . . . . . . 30
6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 30 6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Security Considerations . . . . . . . . . . . . . . . 33 6.3.1. Security Considerations . . . . . . . . . . . . . . . 34
6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 33 6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 34
7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 35 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 36
7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 35 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 36
7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 36 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 37
7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 37 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 38
7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 38 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 39
8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 39 8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Assignments for Existing Key Types . . . . . . . . . . . 39 8.1. Assignments for Existing Key Types . . . . . . . . . . . 40
8.2. Assignments for Existing Algorithms . . . . . . . . . . . 40 8.2. Assignments for Existing Algorithms . . . . . . . . . . . 41
8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 40 8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 41
9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 41 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 42
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 41 10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 42
10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 42 10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 43
10.3. Changes to the "COSE Key Type Parameters" registry . . . 42 10.3. Changes to the "COSE Key Type Parameters" registry . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
12.1. Normative References . . . . . . . . . . . . . . . . . . 44 12.1. Normative References . . . . . . . . . . . . . . . . . . 45
12.2. Informative References . . . . . . . . . . . . . . . . . 46 12.2. Informative References . . . . . . . . . . . . . . . . . 47
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
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 27, line 33 skipping to change at page 28, line 33
A new IV must be used for each message if the same key is used. The A new IV must be used for each message if the same key is used. The
IV can be modified in a predictable manner, a random manner, or an IV can be modified in a predictable manner, a random manner, or an
unpredictable manner (i.e., encrypting a counter). unpredictable manner (i.e., encrypting a counter).
The IV used for a key can also be generated from the same HKDF The IV used for a key can also be generated from the same HKDF
functionality as the key is generated. If HKDF is used for functionality as the key is generated. If HKDF is used for
generating the IV, the algorithm identifier is set to "IV- generating the IV, the algorithm identifier is set to "IV-
GENERATION". GENERATION".
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 SHA-256 | Shared secret w/ | | direct+HKDF-SHA-256 | -10 | HKDF SHA-256 | Shared secret w/ |
| | | | HKDF and SHA-256 | | | | | HKDF and SHA-256 |
+---------------------+-------+--------------+---------------------+ +---------------------+-------+--------------+---------------------+
| direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ | | direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ |
skipping to change at page 33, line 14 skipping to change at page 34, line 14
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
entities be provided as part of the key derivation process (as entities be provided as part of the key derivation process (as
recommended in Section 6.1 of [RFC7748]). This was not done as COSE recommended in Section 6.4 of [RFC7748]). This was not done as COSE
is used in a store and forward format rather than in online key is used in a store and forward format rather than in online key
exchange. In order for this to be a problem, either the receiver exchange. In order for this to be a problem, either the receiver
public key has to be chosen maliciously or the sender has to be public key has to be chosen maliciously or the sender has to be
malicious. In either case, all security evaporates anyway. malicious. In either case, all security evaporates anyway.
A proof of possession of the private key associated with the public A proof of possession of the private key associated with the public
key is recommended when a key is moved from untrusted to trusted key is recommended when a key is moved from untrusted to trusted
(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).
skipping to change at page 39, line 16 skipping to change at page 40, line 16
There are some situations that have been identified where There are some situations that have been identified where
identification of capabilities of an algorithm need to be specified. identification of capabilities of an algorithm need to be specified.
One example of this is in [I-D.ietf-core-oscore-groupcomm] where the One example of this is in [I-D.ietf-core-oscore-groupcomm] where the
capabilities of the counter signature algorithm are mixed into the capabilities of the counter signature algorithm are mixed into the
traffic key derivation process. This has a counterpart in the S/MIME traffic key derivation process. This has a counterpart in the S/MIME
specifications where SMIMECapabilities is defined in Section 2.5.2 of specifications where SMIMECapabilities is defined in Section 2.5.2 of
[RFC8551]. The concept is being pulled forward and defined now for [RFC8551]. The concept is being pulled forward and defined now for
COSE. COSE.
There is a presumption in the way that this is laid out is that the The algorithm identifier is not part of the capabilities data as it
algorithm identifier itself is not needed to be a part of this as it should already be part of message structure. There is a presumption
is specified in a different location. in the way that this is laid out is that the algorithm identifier
itself is not needed to be a part of this as it is specified in a
different location.
Two different types of capabilities are defined: Capabilities for Two different types of capabilities are defined: capabilities for
algorithms and capabilities for key structures. Once defined by algorithms and capabilities for key structures. Once defined by
registration with IANA, the list capabilities is immutable. If it is registration with IANA, the list of capabilities is immutable. If it
later found that a new capability is needed for a key type or an is later found that a new capability is needed for a key type or an
algorithm, it will require that a new code point be assigned to deal algorithm, it will require that a new code point be assigned to deal
with that. As a general rule, the capabilities are going to map to with that. As a general rule, the capabilities are going to map to
algorithm specific header parameters or key parameters, but they do algorithm-specific header parameters or key parameters, but they do
not need to do so. An example of this is the HSS-LMS key not need to do so. An example of this is the HSS-LMS key
capabilities defined below where the hash algorithm used is included. capabilities defined below where the hash algorithm used is included.
The capability structure is an array of values, the order being The capability structure is an array of values, the order being
dependent on the specific algorithm or key. For an algorithm, the dependent on the specific algorithm or key. For an algorithm, the
first element should always be a key type value, but the items that first element should always be a key type value, but the items that
are specific to a key should not be included in the algorithm are specific to a key should not be included in the algorithm
capabilities. This means that if one wishes to enumerate all of the capabilities. This means that if one wishes to enumerate all of the
capabilities for a device which implements ECDH, it requires multiple capabilities for a device which implements ECDH, it requires multiple
pairs of capability structures (algorithm, key) to deal with the pairs of capability structures (algorithm, key) to deal with the
different key types and curves that are supported. For a key, the different key types and curves that are supported. For a key, the
first element should also be a key type value, while this means that first element should also be a key type value. While this means that
this value will be duplicated if both an algorithm and key capability this value will be duplicated if both an algorithm and key capability
are used, the key type is needed in order to understand the rest of are used, the key type is needed in order to understand the rest of
the values. the values.
8.1. Assignments for Existing Key Types 8.1. Assignments for Existing Key Types
There are a number of pre-existing key types, the following deals There are a number of pre-existing key types, the following deals
with creating the capability definition for those structures: with creating the capability definition for those structures:
* OKP, EC2: The list of capabilities is: * OKP, EC2: The list of capabilities is:
skipping to change at page 40, line 26 skipping to change at page 41, line 26
- The key type value (5), - The key type value (5),
- Algorithm identifier for the underlying hash function from the - Algorithm identifier for the underlying hash function from the
"COSE Algorithms" registry. "COSE Algorithms" registry.
8.2. Assignments for Existing Algorithms 8.2. Assignments for Existing Algorithms
For the current set of algorithms in the registry, those in this For the current set of algorithms in the registry, those in this
document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig], document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig],
the capabilities is set to the single entry of the key type (from the the capabilities list is an array with one element, the key type
"COSE Key Types" Registry) that will be accepted. It is expected (from the "COSE Key Types" Registry). It is expected future
future registered algorithms could have zero, one, multiple items. registered algorithms could have zero, one, or multiple elements.
8.3. Examples 8.3. Examples
In this section a trio of examples are provided. In all three cases In this section a trio of examples is provided. In all three cases
the pair of capabilities is always provided as the algorithm and then it it encodes the algorithm capabilities followed by the key
the key capabilities. For simplicity's sake, a CBOR sequence capabilities. For simplicity's sake, a CBOR sequence
[I-D.ietf-cbor-sequence] is used for the two arrays. [I-D.ietf-cbor-sequence] is used for the two arrays.
ECDSA with SHA-512 and a P-256 curve: ECDSA with SHA-512 and a P-256 curve:
0x8102820201 / [2],[2, 1] / 0x8102820201 / [2],[2, 1] /
ECDH-ES + A256KW with a P-256 curve: ECDH-ES + A256KW with a P-256 curve:
0x8102820201 / [2],[2, 1] / 0x8102820201 / [2],[2, 1] /
ECDH-ES + A256KW with an X25519 curve: ECDH-ES + A256KW with an X25519 curve:
0x8101820104 / [1],[1, 4] / 0x8101820104 / [1],[1, 4] /
9. CBOR Encoding Restrictions 9. CBOR Encoding Restrictions
There has been an attempt to limit the number of places where the This document limits the restrictions it imposes on how the CBOR
document needs to impose restrictions on how the CBOR Encoder needs Encoder needs to work. We have managed to narrow it down to the
to work. We have managed to narrow it down to the following following restrictions:
restrictions:
* The restriction applies to the encoding of the COSE_KDF_Context. * The restriction applies to the encoding of the COSE_KDF_Context.
* Encoding MUST be done using definite lengths and the length of 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".
* 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
skipping to change at page 42, line 12 skipping to change at page 43, line 12
Table 22: Key Type Capabilities Table 22: Key Type Capabilities
10.2. Changes to "COSE Algorithms" registry 10.2. Changes to "COSE Algorithms" registry
IANA is requested to create a new column in the "COSE Algorithms" IANA is requested to create a new column in the "COSE Algorithms"
registry. The new column is to be labeled "Capabilities". The new registry. The new column is to be labeled "Capabilities". The new
column is populated with "[kty]" for all current, non-provisional, column is populated with "[kty]" for all current, non-provisional,
registrations. It is expected that the documents which define those registrations. It is expected that the documents which define those
algorithms will be expanded to include this registration, if this is algorithms will be expanded to include this registration, if this is
not done then the DE should be consulted final registration for this not done then the DE should be consulted before final registration
document is done. for this document is done.
IANA is requested to update the reference column in the "COSE IANA is requested to update the reference column in the "COSE
Algorithms" registry to include [[This Document]] as a reference for Algorithms" registry to include [[This Document]] as a reference for
all rows where it is not already present. Note to IANA: There is an all rows where it is not already present. Note to IANA: There is an
action in [I-D.ietf-cose-rfc8152bis-struct] which also modifies data action in [I-D.ietf-cose-rfc8152bis-struct] which also modifies data
in the reference column. That action should be applied first. in the reference column. That action should be applied first.
IANA is rquested to add a new row to the "COSE Algorithms" registry.
+----------+---------------+-------------+------------+-------------+
| Name | Value | Description | Reference | Recommended |
+==========+===============+=============+============+=============+
| IV | IV-GENERATION |Reserved for | [[THIS | No |
|Generation| | doing IV | DOCUMENT]] | |
| | | generation | | |
| | |for symmetric| | |
| | | algorithms. | | |
+----------+---------------+-------------+------------+-------------+
Table 23
10.3. Changes to the "COSE Key Type Parameters" registry 10.3. Changes to the "COSE Key Type Parameters" registry
IANA is required to modify the description to "Public Key" for the IANA is requested to modify the description to "Public Key" for the
line with "Key Type" of 2 and the "Name" of "x". See Table 20 which line with "Key Type" of 2 and the "Name" of "x". See Table 20 which
has been modified with this change. has been modified with this change.
11. Security Considerations 11. Security Considerations
There are a number of security considerations that need to be taken There are a number of security considerations that need to be taken
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
skipping to change at page 44, line 31 skipping to change at page 45, line 42
in order to prevent or discourage such analysis. (For example, the in order to prevent or discourage such analysis. (For example, the
text strings could be defined as 'YES' and 'NO '.) text strings could be defined as 'YES' and 'NO '.)
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-07, 17 November 2019, draft-ietf-cose-rfc8152bis-struct-08, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
struct-07>. struct-08>.
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 47, line 37 skipping to change at page 48, line 47
[RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
and Encryption (COSE) Messages", RFC 8230, and Encryption (COSE) Messages", RFC 8230,
DOI 10.17487/RFC8230, September 2017, DOI 10.17487/RFC8230, September 2017,
<https://www.rfc-editor.org/info/rfc8230>. <https://www.rfc-editor.org/info/rfc8230>.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", Work "Group OSCORE - Secure Group Communication for CoAP", Work
in Progress, Internet-Draft, draft-ietf-core-oscore- in Progress, Internet-Draft, draft-ietf-core-oscore-
groupcomm-06, 4 November 2019, groupcomm-08, 6 April 2020, <https://tools.ietf.org/html/
<https://tools.ietf.org/html/draft-ietf-core-oscore- draft-ietf-core-oscore-groupcomm-08>.
groupcomm-06>.
[I-D.ietf-cose-hash-sig] [I-D.ietf-cose-hash-sig]
Housley, R., "Use of the HSS/LMS Hash-based Signature Housley, R., "Use of the HSS/LMS Hash-based Signature
Algorithm with CBOR Object Signing and Encryption (COSE)", Algorithm with CBOR Object Signing and Encryption (COSE)",
Work in Progress, Internet-Draft, draft-ietf-cose-hash- Work in Progress, Internet-Draft, draft-ietf-cose-hash-
sig-09, 11 December 2019, sig-09, 11 December 2019,
<https://tools.ietf.org/html/draft-ietf-cose-hash-sig-09>. <https://tools.ietf.org/html/draft-ietf-cose-hash-sig-09>.
[I-D.ietf-cbor-sequence] [I-D.ietf-cbor-sequence]
Bormann, C., "Concise Binary Object Representation (CBOR) Bormann, C., "Concise Binary Object Representation (CBOR)
 End of changes. 27 change blocks. 
63 lines changed or deleted 75 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/