rfc9052v2.txt   rfc9052.txt 
Internet Engineering Task Force (IETF) J. Schaad Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 9052 August Cellars Request for Comments: 9052 August Cellars
STD: 96 October 2021 STD: 96 January 2022
Obsoletes: 8152 Obsoletes: 8152
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
CBOR Object Signing and Encryption (COSE): Structures and Process CBOR Object Signing and Encryption (COSE): Structures and Process
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
skipping to change at line 40 skipping to change at line 40
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9052. https://www.rfc-editor.org/info/rfc9052.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Requirements Terminology 1.1. Requirements Terminology
1.2. Changes from RFC 8152 1.2. Changes from RFC 8152
1.3. Design Changes from JOSE 1.3. Design Changes from JOSE
1.4. CBOR Grammar 1.4. CBOR Grammar
1.5. CBOR-Related Terminology 1.5. CBOR-Related Terminology
1.6. Document Terminology 1.6. Document Terminology
skipping to change at line 148 skipping to change at line 148
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)" [STD94]. CBOR extended the data model of the JavaScript (CBOR)" [STD94]. CBOR extended the data model of the JavaScript
Object Notation (JSON) [STD90] by allowing for binary data, among Object Notation (JSON) [STD90] by allowing for binary data, among
other changes. CBOR has been adopted by several of the IETF working other changes. CBOR has been 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
structures. CBOR was designed specifically to be small in terms of structures. CBOR was designed specifically to be small in terms of
both messages transported and implementation size and to be a schema- both messages transported and implementation size and to have a
free decoder. A need exists to provide message security services for schema-free decoder. A need exists to provide message security
IoT, and using CBOR as the message-encoding format makes sense. services for IoT, and using CBOR as the message-encoding format makes
sense.
The JOSE Working Group produced a set of documents [RFC7515] The JOSE Working Group produced a set of documents [RFC7515]
[RFC7516] [RFC7517] [RFC7518] that specified how to process [RFC7516] [RFC7517] [RFC7518] that specified how to process
encryption, signatures, and Message Authentication Code (MAC) encryption, signatures, and Message Authentication Code (MAC)
operations and how to encode keys using JSON. This document defines operations and how to encode keys using JSON. This document defines
the CBOR Object Signing and Encryption (COSE) standard, which does the CBOR Object Signing and Encryption (COSE) standard, which does
the same thing for the CBOR encoding format. This document is the same thing for the CBOR encoding format. This document is
combined with [RFC9053], which provides an initial set of algorithms. combined with [RFC9053], which provides an initial set of algorithms.
While there is a strong attempt to keep the flavor of the original While there is a strong attempt to keep the flavor of the original
JSON Object Signing and Encryption (JOSE) documents, two JSON Object Signing and Encryption (JOSE) documents, two
skipping to change at line 249 skipping to change at line 250
1.2. Changes from RFC 8152 1.2. Changes from RFC 8152
* Split the original document into this document and [RFC9053]. * Split the original document into this document and [RFC9053].
* Added some text describing why there is no digest structure * Added some text describing why there is no digest structure
defined by COSE. defined by COSE.
* Made text clarifications and changes in terminology. * Made text clarifications and changes in terminology.
* Removed all of the details relating to countersignatures and * Removed all of the details relating to countersignatures and
placed in [COSE-COUNTERSIGN]. placed them in [COSE-COUNTERSIGN].
1.3. Design Changes from JOSE 1.3. Design Changes from JOSE
* A single overall message structure has been defined so that * A single overall message structure has been defined so that
encrypted, signed, and MACed messages can easily be identified and encrypted, signed, and MACed messages can easily be identified and
still have a consistent view. still have a consistent view.
* Signed messages distinguish between the protected and unprotected * Signed messages distinguish between the protected and unprotected
header parameters that relate to the content and those that relate header parameters that relate to the content and those that relate
to the signature. to the signature.
skipping to change at line 280 skipping to change at line 281
* The authentication tag for encryption algorithms has been combined * The authentication tag for encryption algorithms has been combined
with the ciphertext. with the ciphertext.
* The set of cryptographic algorithms has been expanded in some * The set of cryptographic algorithms has been expanded in some
directions and trimmed in others. directions and trimmed in others.
1.4. CBOR Grammar 1.4. CBOR Grammar
There was not a standard CBOR grammar available when COSE was There was not a standard CBOR grammar available when COSE was
originally written. For that reason, the CBOR data objects defined originally written. For that reason, the CBOR data objects defined
here are described in prose. Since that time, Concise Data here are described in prose. Since that time, [RFC8610] has
Definition Language (CDDL) [RFC8610] has been published as an RFC, specified Concise Data Definition Language (CDDL, providing such a
providing such a data description grammar to describe CBOR. The CBOR data description grammar to describe CBOR. The CBOR grammar
grammar presented in this document is compatible with CDDL. presented in this document is compatible with CDDL.
This document was developed by first working on the grammar and then This document was developed by first working on the grammar and then
developing the prose to go with it. An artifact of this is that the developing the prose to go with it. An artifact of this is that the
prose was written using the primitive-type strings defined by Concise prose was written using the primitive-type strings defined by Concise
Data Definition Language (CDDL) [RFC8610]. In this specification, Data Definition Language (CDDL) [RFC8610]. In this specification,
the following primitive types are used: the following primitive types are used:
any: A nonspecific value that permits all CBOR values to be placed any: A nonspecific value that permits all CBOR values to be placed
here. here.
skipping to change at line 439 skipping to change at line 440
Elements after this point are dependent on the specific message type. Elements after this point are dependent on the specific message type.
COSE messages are built using the concept of layers to separate COSE messages are built using the concept of layers to separate
different types of cryptographic concepts. As an example of how this different types of cryptographic concepts. As an example of how this
works, consider the COSE_Encrypt message (Section 5.1). This message works, consider the COSE_Encrypt message (Section 5.1). This message
type is broken into two layers: the content layer and the recipient type is broken into two layers: the content layer and the recipient
layer. The content layer contains the encrypted plaintext and layer. The content layer contains the encrypted plaintext and
information about the encrypted message. The recipient layer information about the encrypted message. The recipient layer
contains the encrypted content encryption key (CEK) and information contains the encrypted content encryption key (CEK) and information
about how it is encrypted for each recipient. A single-layer version about how it is encrypted, for each recipient. A single-layer
of the encryption message COSE_Encrypt0 (Section 5.2) is provided for version of the encryption message COSE_Encrypt0 (Section 5.2) is
cases where the CEK is preshared. provided for cases where the CEK is preshared.
Identification of which type of message has been presented is done by Identification of which type of message has been presented is done by
the following methods: the following methods:
1. The specific message type is known from the context. This may be 1. The specific message type is known from the context. This may be
defined by a marker in the containing structure or by defined by a marker in the containing structure or by
restrictions specified by the application protocol. restrictions specified by the application protocol.
2. The message type is identified by a CBOR tag. Messages with a 2. The message type is identified by a CBOR tag. Messages with a
CBOR tag are known in this specification as tagged messages, CBOR tag are known in this specification as tagged messages,
skipping to change at line 567 skipping to change at line 568
The two buckets are: The two buckets are:
protected: Contains parameters about the current layer that are protected: Contains parameters about the current layer that are
cryptographically protected. This bucket MUST be empty if it is cryptographically protected. This bucket MUST be empty if it is
not going to be included in a cryptographic computation. This not going to be included in a cryptographic computation. This
bucket is encoded in the message as a binary object. This value bucket is encoded in the message as a binary object. This value
is obtained by CBOR encoding the protected map and wrapping it in is obtained by CBOR encoding the protected map and wrapping it in
a bstr object. Senders SHOULD encode a zero-length map as a zero- a bstr object. Senders SHOULD encode a zero-length map as a zero-
length byte string rather than as a zero-length map (encoded as length byte string rather than as a zero-length map (encoded as
h'a0'). The zero-length binary encoding is preferred, because it h'a0'). The zero-length byte string encoding is preferred,
is both shorter and the version used in the serialization because it is both shorter and the version used in the
structures for cryptographic computation. Recipients MUST accept serialization structures for cryptographic computation.
both a zero-length byte string and a zero-length map encoded in a Recipients MUST accept both a zero-length byte string and a zero-
byte string. length map encoded in a byte string.
Wrapping the encoding with a byte string allows the protected map Wrapping the encoding with a byte string allows the protected map
to be transported with a greater chance that it will not be to be transported with a greater chance that it will not be
altered accidentally in transit. (Badly behaved intermediates altered accidentally in transit. (Badly behaved intermediates
could decode and re-encode, but this will result in a failure to could decode and re-encode, but this will result in a failure to
verify unless the re-encoded byte string is identical to the verify unless the re-encoded byte string is identical to the
decoded byte string.) This avoids the problem of all parties decoded byte string.) This avoids the problem of all parties
needing to be able to do a common canonical encoding of the map needing to be able to do a common canonical encoding of the map
for input to crytographic operations. for input to crytographic operations.
skipping to change at line 608 skipping to change at line 609
"map" type). The presence of both buckets is required. The header "map" type). The presence of both buckets is required. The header
parameters that go into the buckets come from the IANA "COSE Header parameters that go into the buckets come from the IANA "COSE Header
Parameters" registry (Section 11.1). Some header parameters are Parameters" registry (Section 11.1). Some header parameters are
defined in the next section. defined in the next section.
Labels in each of the maps MUST be unique. When processing messages, Labels in each of the maps MUST be unique. When processing messages,
if a label appears multiple times, the message MUST be rejected as if a label appears multiple times, the message MUST be rejected as
malformed. Applications SHOULD verify that the same label does not malformed. Applications SHOULD verify that the same label does not
occur in both the protected and unprotected header parameters. If occur in both the protected and unprotected header parameters. If
the message is not rejected as malformed, attributes MUST be obtained the message is not rejected as malformed, attributes MUST be obtained
from the protected bucket, and only if not found are attributes from the protected bucket, and only if not found in the protected
obtained from the unprotected bucket. bucket.
The following CDDL fragment represents the two header-parameter The following CDDL fragment represents the two header-parameter
buckets. A group "Headers" is defined in CDDL that represents the buckets. A group "Headers" is defined in CDDL that represents the
two buckets in which attributes are placed. This group is used to two buckets in which attributes are placed. This group is used to
provide these two fields consistently in all locations. A type is provide these two fields consistently in all locations. A type is
also defined that represents the map of common header parameters. also defined that represents the map of common header parameters.
Headers = ( Headers = (
protected : empty_or_serialized_map, protected : empty_or_serialized_map,
unprotected : header_map unprotected : header_map
skipping to change at line 665 skipping to change at line 666
Not all header-parameter labels need to be included in the "crit" Not all header-parameter labels need to be included in the "crit"
header parameter. The rules for deciding which header parameters header parameter. The rules for deciding which header parameters
are placed in the array are: are placed in the array are:
* Integer labels in the range of 0 to 7 SHOULD be omitted. * Integer labels in the range of 0 to 7 SHOULD be omitted.
* Integer labels in the range -1 to -128 can be omitted. * Integer labels in the range -1 to -128 can be omitted.
Algorithms can assign labels in this range where the ability to Algorithms can assign labels in this range where the ability to
process the content of the label is considered to be core to process the content of the label is considered to be core to
implementing the algorithm. Algorithms can assign labels implementing the algorithm. Algorithms can assign labels
outside of this range where the ability to process the content outside of this range and include them in the "crit" header
of the label is not considered to be core but needs to be parameter when the ability to process the content of the label
understood to correctly process this instance. Integer labels is not considered to be core functionality of the algorithm but
in the range -129 to -65536 SHOULD be included, as these would does need to be understood to correctly process this instance.
be less common header parameters that might not be generally Integer labels in the range -129 to -65536 SHOULD be included,
supported. as these would be less common header parameters that might not
be generally supported.
* Labels for header parameters required for an application MAY be * Labels for header parameters required for an application MAY be
omitted. Applications should have a statement declaring omitted. Applications should have a statement declaring
whether or not the label can be omitted. whether or not the label can be omitted.
The header parameters indicated by "crit" can be processed by The header parameters indicated by "crit" can be processed by
either the security-library code or an application using a either the security-library code or an application using a
security library; the only requirement is that the header security library; the only requirement is that the header
parameter is processed. If the "crit" value list includes a label parameter is processed. If the "crit" value list includes a label
for which the header parameter is not in the protected-header- for which the header parameter is not in the protected-header-
parameters bucket, this is a fatal error in processing the parameters bucket, this is a fatal error in processing the
message. message.
content type: This header parameter is used to indicate the content content type: This header parameter is used to indicate the content
type of the data in the "payload" or "ciphertext" fields. type of the data in the "payload" or "ciphertext" field. Integers
Integers are from the "CoAP Content-Formats" IANA registry table are from the "CoAP Content-Formats" IANA registry table
[COAP.Formats]. Text values follow the syntax of "<type- [COAP.Formats]. Text values follow the syntax of "<type-
name>/<subtype-name>", where <type-name> and <subtype-name> are name>/<subtype-name>", where <type-name> and <subtype-name> are
defined in Section 4.2 of [RFC6838]. Leading and trailing defined in Section 4.2 of [RFC6838]. Leading and trailing
whitespace is also omitted. Textual content values, along with whitespace is also omitted. Textual content values, along with
parameters and subparameters, can be located using the IANA "Media parameters and subparameters, can be located using the IANA "Media
Types" registry. Applications SHOULD provide this header Types" registry. Applications SHOULD provide this header
parameter if the content structure is potentially ambiguous. parameter if the content structure is potentially ambiguous.
kid: This header parameter identifies one piece of data that can be kid: This header parameter identifies one piece of data that can be
used as input to find the needed cryptographic key. The value of used as input to find the needed cryptographic key. The value of
skipping to change at line 951 skipping to change at line 953
This document describes the process for using a byte array of This document describes the process for using a byte array of
externally supplied authenticated data; the method of constructing externally supplied authenticated data; the method of constructing
the byte array is a function of the application. Applications that the byte array is a function of the application. Applications that
use this feature need to define how the externally supplied use this feature need to define how the externally supplied
authenticated data is to be constructed. Such a construction needs authenticated data is to be constructed. Such a construction needs
to take into account the following issues: to take into account the following issues:
* If multiple items are included, applications need to ensure that * If multiple items are included, applications need to ensure that
the same byte string cannot be produced if there are different the same byte string cannot be produced if there are different
inputs. This would occur by concatenating the text strings "AB" inputs. An example of how the problematic scenario could arise
and "CDE" or by concatenating the text strings "ABC" and "DE". would be by concatenating the text strings "AB" and "CDE" or by
This is usually addressed by making fields a fixed width and/or concatenating the text strings "ABC" and "DE". This is usually
encoding the length of the field as part of the output. Using addressed by making fields a fixed width and/or encoding the
options from CoAP [RFC7252] as an example, these fields use a TLV length of the field as part of the output. Using options from
structure so they can be concatenated without any problems. CoAP [RFC7252] as an example, these fields use a TLV structure so
they can be concatenated without any problems.
* If multiple items are included, an order for the items needs to be * If multiple items are included, an order for the items needs to be
defined. Using options from CoAP as an example, an application defined. Using options from CoAP as an example, an application
could state that the fields are to be ordered by the option could state that the fields are to be ordered by the option
number. number.
* Applications need to ensure that the byte string is going to be * Applications need to ensure that the byte string is going to be
the same on both sides. Using options from CoAP might give a the same on both sides. Using options from CoAP might give a
problem if the same relative numbering is kept. An intermediate problem if the same relative numbering is kept. An intermediate
node could insert or remove an option, changing how the relative node could insert or remove an option, changing how the relative
skipping to change at line 1267 skipping to change at line 1270
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
(Section 8.5.3), key wrap keys (Section 8.5.2), and preshared (Section 8.5.3), key wrap keys (Section 8.5.2), and preshared
secrets. secrets.
Direct Encryption and Direct Key Agreement: The key is Direct Encryption and Direct Key Agreement: The key is
determined by the key and algorithm in the recipient determined by the key and algorithm in the recipient
structure. The encryption algorithm and size of the key to be structure. The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient. (For used are inputs into the KDF used for the recipient. (For
direct, the KDF can be thought of as the identity operation.) direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections 6.1.2 and Examples of these algorithms are found in Sections 6.1 and 6.3
6.3 of [RFC9053]. of [RFC9053].
Other: The key is randomly or pseudorandomly generated. Other: The key is randomly or pseudorandomly generated.
4. Call the encryption algorithm with K (the encryption key), P (the 4. Call the encryption algorithm with K (the encryption key), P (the
plaintext), and AAD. Place the returned ciphertext into the plaintext), and AAD. Place the returned ciphertext into the
"ciphertext" field of the structure. "ciphertext" field of the structure.
5. For recipients of the message, recursively perform the encryption 5. For recipients of the message, recursively perform the encryption
algorithm for that recipient, using K (the encryption key) as the algorithm for that recipient, using K (the encryption key) as the
plaintext. plaintext.
skipping to change at line 1483 skipping to change at line 1486
COSE_Mac0 = [ COSE_Mac0 = [
Headers, Headers,
payload : bstr / nil, payload : bstr / nil,
tag : bstr, tag : bstr,
] ]
6.3. How to Compute and Verify a MAC 6.3. How to Compute and Verify a MAC
In order to get a consistent encoding of the data to be In order to get a consistent encoding of the data to be
authenticated, the MAC_structure is used to have a canonical form. authenticated, the MAC_structure is used to create the canonical
The MAC_structure is a CBOR array. The fields of the MAC_structure, form. The MAC_structure is a CBOR array. The fields of the
in order, are: MAC_structure, in order, are:
1. A context text string that identifies the structure that is being 1. A context text string that identifies the structure that is being
encoded. This context text string is "MAC" for the COSE_Mac encoded. This context text string is "MAC" for the COSE_Mac
structure. This context text string is "MAC0" for the COSE_Mac0 structure. This context text string is "MAC0" for the COSE_Mac0
structure. structure.
2. The protected attributes from the COSE_MAC structure. If there 2. The protected attributes from the COSE_MAC structure. If there
are no protected attributes, a zero-length bstr is used. are no protected attributes, a zero-length bstr is used.
3. The externally supplied data from the application, encoded as a 3. The externally supplied data from the application, encoded as a
skipping to change at line 1667 skipping to change at line 1670
IV is used twice. IV is used twice.
If different keys are derived for each sender, starting at the If different keys are derived for each sender, starting at the
same Base IV is likely to satisfy this condition. If the same key same Base IV is likely to satisfy this condition. If the same key
is used for multiple senders, then the application needs to is used for multiple senders, then the application needs to
provide for a method of dividing the IV space up between the provide for a method of dividing the IV space up between the
senders. This could be done by providing a different base point senders. This could be done by providing a different base point
to start from or a different Partial IV to start with and to start from or a different Partial IV to start with and
restricting the number of messages to be sent before rekeying. restricting the number of messages to be sent before rekeying.
+=========+=======+==============================================+ +=========+=======+===========================================+
| Name | Value | Description | | Name | Value | Description |
+=========+=======+==============================================+ +=========+=======+===========================================+
| sign | 1 | The key is used to create signatures. | | sign | 1 | The key is used to create signatures. |
| | | Requires private key fields. | | | | Requires private key fields. |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| verify | 2 | The key is used for verification of | | verify | 2 | The key is used for verification of |
| | | signatures. | | | | signatures. |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| encrypt | 3 | The key is used for key transport | | encrypt | 3 | The key is used for key transport |
| | | encryption. | | | | encryption. |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| decrypt | 4 | The key is used for key transport | | decrypt | 4 | The key is used for key transport |
| | | decryption. Requires private key fields. | | | | decryption. Requires private key fields. |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| wrap | 5 | The key is used for key wrap encryption. | | wrap | 5 | The key is used for key wrap encryption. |
| key | | | | key | | |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| unwrap | 6 | The key is used for key wrap decryption. | | unwrap | 6 | The key is used for key wrap decryption. |
| key | | Requires private key fields. | | key | | Requires private key fields. |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| derive | 7 | The key is used for deriving keys. Requires | | derive | 7 | The key is used for deriving keys. |
| key | | private key fields. | | key | | |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| derive | 8 | The key is used for deriving bits not to be | | derive | 8 | The key is used for deriving bits not to |
| bits | | used as a key. Requires private key fields. | | bits | | be used as a key. |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| MAC | 9 | The key is used for creating MACs. | | MAC | 9 | The key is used for creating MACs. |
| create | | | | create | | |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
| MAC | 10 | The key is used for validating MACs. | | MAC | 10 | The key is used for validating MACs. |
| verify | | | | verify | | |
+---------+-------+----------------------------------------------+ +---------+-------+-------------------------------------------+
Table 5: Key Operation Values Table 5: Key Operation Values
8. Taxonomy of Algorithms Used by COSE 8. Taxonomy of Algorithms Used by COSE
In this section, a taxonomy of the different algorithm types that can In this section, a taxonomy of the different algorithm types that can
be used in COSE is laid out. This taxonomy should not be considered be used in COSE is laid out. This taxonomy should not be considered
to be exhaustive. New algorithms will be created that will not fit to be exhaustive. New algorithms will be created that will not fit
into this taxonomy. into this taxonomy.
8.1. Signature Algorithms 8.1. Signature Algorithms
skipping to change at line 1734 skipping to change at line 1737
The signature functions for this scheme are: The signature functions for this scheme are:
signature = Sign(message content, key) signature = Sign(message content, key)
valid = Verification(message content, key, signature) valid = Verification(message content, key, signature)
The second scheme is signature with message recovery; an example of The second scheme is signature with message recovery; an example of
such an algorithm is [PVSig]. In this scheme, the message content is such an algorithm is [PVSig]. In this scheme, the message content is
processed, but part of it is included in the signature. Moving bytes processed, but part of it is included in the signature. Moving bytes
of the message content into the signature allows for smaller of the message content into the signature allows for smaller signed
signatures; the signature size is still potentially large, but the messages; the signature size is still potentially large, but the
message content has shrunk. This has implications for systems message content has shrunk. This has implications for systems
implementing these algorithms and applications that use them. The implementing these algorithms and applications that use them. The
first is that the message content is not fully available until after first is that the message content is not fully available until after
a signature has been validated. Until that point, the part of the a signature has been validated. Until that point, the part of the
message contained inside of the signature is unrecoverable. The message contained inside of the signature is unrecoverable. The
second implication is that the security analysis of the strength of second implication is that the security analysis of the strength of
the signature can be very much dependent on the structure of the the signature can be very much dependent on the structure of the
message content. Finally, in the event that multiple signatures are message content. Finally, in the event that multiple signatures are
applied to a message, all of the signature algorithms are going to be applied to a message, all of the signature algorithms are going to be
required to consume the same bytes of message content. This means required to consume the same bytes of message content. This means
skipping to change at line 1757 skipping to change at line 1760
with-appendix schemes in a single message is not supported. with-appendix schemes in a single message is not supported.
The signature functions for this scheme are: The signature functions for this scheme are:
signature, message sent = Sign(message content, key) signature, message sent = Sign(message content, key)
valid, message content = Verification(message sent, key, signature) valid, message content = Verification(message sent, key, signature)
No message recovery signature algorithms have been formally defined No message recovery signature algorithms have been formally defined
for COSE yet. Given the new constraints arising from this scheme, for COSE yet. Given the new constraints arising from this scheme,
while some of these issues have already been identified, there is a while some issues have already been identified, there is a high
high probability that additional issues will arise when integrating probability that additional issues will arise when integrating
message recovery signature algorithms. The first algorithm defined message recovery signature algorithms. The first algorithm defined
is going to need to make decisions about these issues, and those is going to need to make decisions about these issues, and those
decisions are likely to be binding on any further algorithms defined. decisions are likely to be binding on any further algorithms defined.
We use the following terms below: We use the following terms below:
message content bytes: The byte provided by the application to be message content bytes: The byte string provided by the application
signed. to be signed.
to-be-signed bytes: The byte string passed into the signature to-be-signed bytes: The byte string passed into the signature
algorithm. algorithm.
recovered bytes: The bytes recovered during the signature recovered bytes: The bytes recovered during the signature
verification process. verification process.
Some of the issues that have already been identified are: Some of the issues that have already been identified are:
* The to-be-signed bytes are not the same as the message content * The to-be-signed bytes are not the same as the message content
skipping to change at line 1875 skipping to change at line 1878
that is created by a good random number generator. that is created by a good random number generator.
* Secrets that are not uniformly random. This is the type of secret * Secrets that are not uniformly random. This is the type of secret
that is created by operations like key agreement. that is created by operations like key agreement.
* Secrets that are not random. This is the type of secret that * Secrets that are not random. This is the type of secret that
people generate for things like passwords. people generate for things like passwords.
General KDFs work well with the first type of secret, can do General KDFs work well with the first type of secret, can do
reasonably well with the second type of secret, and generally do reasonably well with the second type of secret, and generally do
poorly with the last type of secret. Functions like Argon2 poorly with the last type of secret. Functions like Argon2 [RFC9106]
[CFRG-ARGON2] need to be used for nonrandom secrets. need to be used for nonrandom secrets.
The same KDF can be set up to deal with the first two types of The same KDF can be set up to deal with the first two types of
secrets in different ways. The KDF defined in Section 5.1 of secrets in different ways. The KDF defined in Section 5.1 of
[RFC9053] is such a function. This is reflected in the set of [RFC9053] is such a function. This is reflected in the set of
algorithms defined around the HMAC-based Extract-and-Expand Key algorithms defined around the HMAC-based Extract-and-Expand Key
Derivation Function (HKDF). Derivation Function (HKDF).
When using KDFs, one component that is included is context When using KDFs, one component that is included is context
information. Context information is used to allow for different information. Context information is used to allow for different
keying information to be derived from the same secret. The use of keying information to be derived from the same secret. The use of
skipping to change at line 1938 skipping to change at line 1941
Encryption if the system has any capability for doing random-key Encryption if the system has any capability for doing random-key
generation. This is because the shared key is used to wrap random generation. This is because the shared key is used to wrap random
data rather than data that has some degree of organization and may in data rather than data that has some degree of organization and may in
fact be repeating the same content. The use of key wrap loses the fact be repeating the same content. The use of key wrap loses the
weak data origination that is provided by the direct-encryption weak data origination that is provided by the direct-encryption
algorithms. algorithms.
The COSE_Recipient structure for the recipient is organized as The COSE_Recipient structure for the recipient is organized as
follows: follows:
* The "protected" field MUST be absent if the key wrap algorithm is * The "protected" field MUST be a zero-length byte string if the key
an AE algorithm. wrap algorithm is an AE algorithm.
* The "recipients" field is normally absent but can be used. * The "recipients" field is normally absent but can be used.
Applications MUST deal with a recipient field being present that Applications MUST deal with a recipient field being present that
has an unsupported algorithm. Failing to decrypt that specific has an unsupported algorithm. Failing to decrypt that specific
recipient is an acceptable way of dealing with it. Failing to recipient is an acceptable way of dealing with it. Failing to
process the message is not an acceptable way of dealing with it. process the message is not an acceptable way of dealing with it.
* The plaintext to be encrypted is the key from the next layer down * The plaintext to be encrypted is the key from the next layer down
(usually the content layer). (usually the content layer).
skipping to change at line 1965 skipping to change at line 1968
Key transport mode is also called key encryption mode in some Key transport mode is also called key encryption mode in some
standards. Key transport mode differs from key wrap mode in that it standards. Key transport mode differs from key wrap mode in that it
uses an asymmetric encryption algorithm rather than a symmetric uses an asymmetric encryption algorithm rather than a symmetric
encryption algorithm to protect the key. A set of key transport encryption algorithm to protect the key. A set of key transport
algorithms is defined in [RFC8230]. algorithms is defined in [RFC8230].
When using a key transport algorithm, the COSE_Recipient structure When using a key transport algorithm, the COSE_Recipient structure
for the recipient is organized as follows: for the recipient is organized as follows:
* The "protected" field MUST be absent. * The "protected" field MUST be a zero-length byte string.
* The plaintext to be encrypted is the key from the next layer down * The plaintext to be encrypted is the key from the next layer down
(usually the content layer). (usually the content layer).
* At a minimum, the "unprotected" field MUST contain the "alg" * At a minimum, the "unprotected" field MUST contain the "alg"
header parameter and SHOULD contain a parameter identifying the header parameter and SHOULD contain a parameter identifying the
asymmetric key. asymmetric key.
8.5.4. Direct Key Agreement 8.5.4. Direct Key Agreement
skipping to change at line 2054 skipping to change at line 2057
9. CBOR Encoding Restrictions 9. CBOR Encoding Restrictions
This document limits the restrictions it imposes on how the CBOR This document limits the restrictions it imposes on how the CBOR
Encoder needs to work. The new encoding restrictions are aligned Encoder needs to work. The new encoding restrictions are aligned
with the deterministically encoded CBOR requirements specified in with the deterministically encoded CBOR requirements specified in
[STD94]. It has been narrowed down to the following restrictions: [STD94]. It has been narrowed down to the following restrictions:
* The restriction applies to the encoding of the the Sig_structure, * The restriction applies to the encoding of the the Sig_structure,
the Enc_structure, and the MAC_structure. the Enc_structure, and the MAC_structure.
* Encoding MUST be done using definite lengths, and the value's * Encoding MUST be done using definite lengths, and the length of
length MUST be the minimum possible length. This means that the the (encoded) argument MUST be the minimum possible length. This
integer 1 is encoded as "0x01" and not "0x1801". means that the integer 1 is encoded as "0x01" and not "0x1801".
* Applications MUST NOT generate messages with the same label used * Applications MUST NOT generate messages with the same label used
twice as a key in a single map. Applications MUST NOT parse and twice as a key in a single map. Applications MUST NOT parse and
process messages with the same label used twice as a key in a process messages with the same label used twice as a key in a
single map. Applications can enforce the parse and process single map. Applications can enforce the parse-and-process
requirement by using parsers that will 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.
10. Application Profiling Considerations 10. Application Profiling Considerations
This document is designed to provide a set of security services but This document is designed to provide a set of security services but
not impose algorithm implementation requirements for specific usage. not impose algorithm implementation requirements for specific usage.
The interoperability requirements are provided for how each of the The interoperability requirements are provided for how each of the
individual services are used and how the algorithms are to be used individual services are used and how the algorithms are to be used
skipping to change at line 2328 skipping to change at line 2331
document instead of [RFC8152]. document instead of [RFC8152].
11.5. CBOR Tags Registry 11.5. CBOR Tags Registry
IANA has updated the references to point to this document instead of IANA has updated the references to point to this document instead of
[RFC8152]. [RFC8152].
11.6. Expert Review Instructions 11.6. Expert Review Instructions
All of the IANA registries established by [RFC8152] are, at least in All of the IANA registries established by [RFC8152] are, at least in
part, defined as expert review. This section gives some general part, defined as Expert Review. This section gives some general
guidelines for what the experts should be looking for, but they are guidelines for what the experts should be looking for, but they are
being designated as experts for a reason, so they should be given being designated as experts for a reason, so they should be given
substantial latitude. substantial latitude.
Expert reviewers should take the following into consideration: Expert reviewers should take the following into consideration:
* Point squatting should be discouraged. Reviewers are encouraged * Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
that the usage is not going to duplicate an existing registration that the usage is not going to duplicate an existing registration
and that the code point is likely to be used in deployments. The and that the code point is likely to be used in deployments. The
skipping to change at line 2359 skipping to change at line 2362
interoperable way. When specifications are not provided, the interoperable way. When specifications are not provided, the
description provided needs to have sufficient information to description provided needs to have sufficient information to
identify what the point is being used for. identify what the point is being used for.
* Experts should take into account the expected usage of fields when * Experts should take into account the expected usage of fields when
approving code point assignment. The fact that the Standards approving code point assignment. The fact that the Standards
Action range is only available to Standards Track documents does Action range is only available to Standards Track documents does
not mean that a Standards Track document cannot have points not mean that a Standards Track document cannot have points
assigned outside of that range. The length of the encoded value assigned outside of that range. The length of the encoded value
should be weighed against how many code points of that length are should be weighed against how many code points of that length are
left, the size of device it will be used on, and the number of left and the size of device it will be used on.
code points left that encode to that size.
* When algorithms are registered, vanity registrations should be * When algorithms are registered, vanity registrations should be
discouraged. One way to do this is to require registrations to discouraged. One way to do this is to require registrations to
provide additional documentation on security analysis of the provide additional documentation on security analysis of the
algorithm. Another thing that should be considered is requesting algorithm. Another thing that should be considered is requesting
an opinion on the algorithm from the Crypto Forum Research Group an opinion on the algorithm from the Crypto Forum Research Group
(CFRG). Algorithms are expected to meet the security requirements (CFRG). Algorithms are expected to meet the security requirements
of the community and the requirements of the message structures in of the community and the requirements of the message structures in
order to be suitable for registration. order to be suitable for registration.
12. Security Considerations 12. 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. While some into account by implementers of this specification. 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 all Implementations need to protect the private key material for all
individuals. There are some cases that need to be highlighted on individuals. Some cases in this document need to be highlighted with
this issue. regard to this issue.
* Use of the same key for two different algorithms can leak * Use of 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.
* 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.
* Several of the algorithms in [RFC9053] have limits on the number * Several of the algorithms in [RFC9053] have limits on the number
skipping to change at line 2408 skipping to change at line 2410
recipients requires that the CEK be shared between two recipients. recipients requires that the CEK be shared between two recipients.
The second recipient therefore has a CEK that was derived from The second recipient therefore has a CEK that was derived from
material that can be used for the weak proof of origin. The second material that can be used for the weak proof of origin. The second
recipient could create a message using the same CEK and send it to recipient could create a message using the same CEK and send it to
the first recipient; the first recipient would, for either Static- the first recipient; the first recipient would, for either Static-
Static ECDH or direct plus KDF, make an assumption that the CEK could Static ECDH or direct plus KDF, make an assumption that the CEK could
be used for proof of origin, even though it is from the wrong entity. be used for proof of origin, even though it is from the wrong entity.
If the key wrap step is added, then no proof of origin is implied and If the key wrap step is added, then no proof of origin is implied and
this is not an issue. this is not an issue.
Although it has been mentioned before, the use of a single key for Although it has been mentioned before, it bears repeating that the
multiple algorithms has been demonstrated in some cases to leak use of a single key for multiple algorithms has been demonstrated in
information about that key, providing the opportunity for attackers some cases to leak information about a key, providing the opportunity
to forge integrity tags or gain information about encrypted content. for attackers to forge integrity tags or gain information about
Binding a key to a single algorithm prevents these problems. Key encrypted content. Binding a key to a single algorithm prevents
creators and key consumers are strongly encouraged not only to create these problems. Key creators and key consumers are strongly
new keys for each different algorithm, but to include that selection encouraged to not only create new keys for each different algorithm,
of algorithm in any distribution of key material and strictly enforce but to include that selection of algorithm in any distribution of key
the matching of algorithms in the key structure to algorithms in the material and strictly enforce the matching of algorithms in the key
message structure. In addition to checking that algorithms are structure to algorithms in the message structure. In addition to
correct, the key form needs to be checked as well. Do not use an checking that algorithms are correct, the key form needs to be
"EC2" key where an "OKP" key is expected. checked as well. Do not use an "EC2" key where an "OKP" key is
expected.
Before using a key for transmission, or before acting on information Before using a key for transmission, or before acting on information
received, a trust decision on a key needs to be made. Is the data or received, a trust decision on a key needs to be made. Is the data or
action something that the entity associated with the key has a right action something that the entity associated with the key has a right
to see or a right to request? A number of factors are associated to see or a right to request? A number of factors are associated
with this trust decision. Some of the ones that are highlighted here with this trust decision. Some highlighted here are:
are:
* What are the permissions associated with the key owner? * What are the permissions associated with the key owner?
* Is the cryptographic algorithm acceptable in the current context? * Is the cryptographic algorithm acceptable in the current context?
* Have the restrictions associated with the key, such as algorithm * Have the restrictions associated with the key, such as algorithm
or freshness, been checked, and are they correct? or freshness, been checked, and are they correct?
* Is the request something that is reasonable, given the current * Is the request something that is reasonable, given the current
state of the application? state of the application?
* Have any security considerations that are part of the message been * Have any security considerations that are part of the message been
enforced (as specified by the application or "crit" header enforced (as specified by the application or "crit" header
parameter)? parameter)?
One area that has been getting exposure is traffic analysis of One area that has been getting exposure is traffic analysis of
encrypted messages based on the length of the message. This encrypted messages based on the length of the message. This
specification does not provide for a uniform method of providing specification does not provide a uniform method for providing padding
padding as part of the message structure. An observer can as part of the message structure. An observer can distinguish
distinguish between two different messages (for example, "YES" and between two different messages (for example, "YES" and "NO") based on
"NO") based on the length for all of the content encryption the length for all of the content encryption algorithms that are
algorithms that are defined in [RFC9053]. This means that it is up defined in [RFC9053]. This means that it is up to the applications
to the applications to document how content padding is to be done in to document how content padding is to be done in order to prevent or
order to prevent or discourage such analysis. (For example, the text discourage such analysis. (For example, the text strings could be
strings could be defined as "YES" and "NO".) defined as "YES" and "NO ".)
13. References 13. References
13.1. Normative References 13.1. Normative References
[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 line 2481 skipping to change at line 2483
Representation (CBOR)", STD 94, RFC 8949, December 2020, Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/std94>. <https://www.rfc-editor.org/info/std94>.
13.2. Informative References 13.2. Informative References
[BCP201] Housley, R., "Guidelines for Cryptographic Algorithm [BCP201] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, November 2015, BCP 201, RFC 7696, November 2015,
<https://www.rfc-editor.org/info/bcp201>. <https://www.rfc-editor.org/info/bcp201>.
[CFRG-ARGON2]
Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "Argon2 Memory-Hard Function for Password
Hashing and Proof-of-Work Applications", Work in Progress,
Internet-Draft, draft-irtf-cfrg-argon2-13, 11 March 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
argon2-13>.
[COAP.Formats] [COAP.Formats]
IANA, "CoAP Content-Formats", IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters/>. <https://www.iana.org/assignments/core-parameters/>.
[CORE-GROUPCOMM] [CORE-GROUPCOMM]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
04, 12 July 2021, <https://datatracker.ietf.org/doc/html/ 05, 25 October 2021,
draft-ietf-core-groupcomm-bis-04>. <https://datatracker.ietf.org/doc/html/draft-ietf-core-
groupcomm-bis-05>.
[COSE-COUNTERSIGN] [COSE-COUNTERSIGN]
Schaad, J. and R. Housley, "CBOR Object Signing and Schaad, J. and R. Housley, "CBOR Object Signing and
Encryption (COSE): Countersignatures", Work in Progress, Encryption (COSE): Countersignatures", Work in Progress,
Internet-Draft, draft-ietf-cose-countersign-05, 23 June Internet-Draft, draft-ietf-cose-countersign-05, 23 June
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
cose-countersign-05>. cose-countersign-05>.
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
skipping to change at line 2637 skipping to change at line 2632
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC9054] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9054] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, October Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, October
2021, <https://www.rfc-editor.org/info/rfc9054>. 2021, <https://www.rfc-editor.org/info/rfc9054>.
[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "Argon2 Memory-Hard Function for Password
Hashing and Proof-of-Work Applications", RFC 9106,
DOI 10.17487/RFC9106, September 2021,
<https://www.rfc-editor.org/info/rfc9106>.
[STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017, Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/info/std90>. <https://www.rfc-editor.org/info/std90>.
[W3C.WebCrypto] [W3C.WebCrypto]
Watson, M., Ed., "Web Cryptography API", W3C Watson, M., Ed., "Web Cryptography API", W3C
Recommendation, 26 January 2017, Recommendation, 26 January 2017,
<https://www.w3.org/TR/WebCryptoAPI/>. <https://www.w3.org/TR/WebCryptoAPI/>.
Appendix A. Guidelines for External Data Authentication of Algorithms Appendix A. Guidelines for External Data Authentication of Algorithms
skipping to change at line 2838 skipping to change at line 2839
* Layer 2: Uses ECDH Ephemeral-Static direct to generate the Layer 1 * Layer 2: Uses ECDH Ephemeral-Static direct to generate the Layer 1
key. key.
In effect, this example is a decomposed version of using the ECDH- In effect, this example is a decomposed version of using the ECDH-
ES+A128KW algorithm. ES+A128KW algorithm.
Size of binary file is 183 bytes Size of binary file is 183 bytes
96( 96(
[ / COSE_Encrypt / [ / COSE_Encrypt /
/ protected h'a10101' / << { / protected h'a10101' / << {
/ alg / 1:1 / AES-GCM 128 / / alg / 1:1 / AES-GCM 128 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ iv / 5:h'02d1f7e6f26c43d4868d87ce' / iv / 5:h'02d1f7e6f26c43d4868d87ce'
}, },
/ ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e2852948658f0 / ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e2852948658f0
811139868826e89218a75715b', 811139868826e89218a75715b',
/ recipients / [ / recipients / [
[ / COSE_Recipient / [ / COSE_Recipient /
/ protected / h'', / protected / h'',
/ unprotected / { / unprotected / {
/ alg / 1:-3 / A128KW / / alg / 1:-3 / A128KW /
}, },
/ ciphertext / h'dbd43c4e9d719c27c6275c67d628d493f090593db82 / ciphertext / h'dbd43c4e9d719c27c6275c67d628d493f090593db82
18f11', 18f11',
/ recipients / [ / recipients / [
[ / COSE_Recipient / [ / COSE_Recipient /
/ protected h'a1013818' / << { / protected h'a1013818' / << {
/ alg / 1:-25 / ECDH-ES + HKDF-256 / / alg / 1:-25 / ECDH-ES + HKDF-256 /
} >> , } >> ,
/ unprotected / { / unprotected / {
/ ephemeral / -1:{ / ephemeral / -1:{
/ kty / 1:2, / kty / 1:2,
/ crv / -1:1, / crv / -1:1,
/ x / -2:h'b2add44368ea6d641f9ca9af308b4079aeb519f11 / x / -2:h'b2add44368ea6d641f9ca9af308b4079aeb519f11
e9b8a55a600b21233e86e68', e9b8a55a600b21233e86e68',
/ y / -3:false / y / -3:false
}, },
skipping to change at line 2892 skipping to change at line 2893
extended CBOR diagnostic notation (defined in [RFC8610]) rather than extended CBOR diagnostic notation (defined in [RFC8610]) rather than
as a binary dump. as a binary dump.
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 not only the examples presented in this Examples> that contains not only the examples presented in this
document, but a more complete set of testing examples as well. Each document, but a more complete 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 debugging the example, and the output of the example presented
both as a hex dump and in CBOR diagnostic notation format. Some of both as a hex dump and in CBOR diagnostic notation format. Some of
the examples at the site are designed failure-testing cases; these the examples at the site are designed to be failure-testing cases;
are clearly marked as such in the JSON file. If errors in the these are clearly marked as such in the JSON file. If errors in the
examples in this document are found, the examples on GitHub will be examples 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. updated, and a note to that effect will be placed in the JSON file.
As noted, the examples are presented using CBOR's diagnostic As noted, the examples are presented using CBOR's diagnostic
notation. A Ruby-based tool exists that can convert between the notation. A Ruby-based tool exists that can convert between the
diagnostic notation and binary. This tool can be installed with the diagnostic notation and binary. This tool can be installed with the
command line: command line:
gem install cbor-diag gem install cbor-diag
skipping to change at line 3127 skipping to change at line 3128
/ protected h'a1010a' / << { / protected h'a1010a' / << {
/ alg / 1:10 / AES-CCM-16-64-128 / / alg / 1:10 / AES-CCM-16-64-128 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ iv / 5:h'89f52f65a1c580933b5261a76c' / iv / 5:h'89f52f65a1c580933b5261a76c'
}, },
/ ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93 / ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93
1b687b847', 1b687b847',
/ recipients / [ / recipients / [
[ [
/ protected h'a10129' / << { / protected h'a10129' / << {
/ alg / 1:-10 / alg / 1:-10
} >>, } >>,
/ unprotected / { / unprotected / {
/ salt / -20:'aabbccddeeffgghh', / salt / -20:'aabbccddeeffgghh',
/ kid / 4:'our-secret' / kid / 4:'our-secret'
}, },
/ ciphertext / h'' / ciphertext / h''
] ]
] ]
] ]
skipping to change at line 3214 skipping to change at line 3215
This example uses the following: This example uses the following:
* CEK: AES-CCM w/ 128-bit key and a 64-bit tag * CEK: AES-CCM w/ 128-bit key and a 64-bit tag
* Prefix for IV is 89F52F65A1C580933B52 * Prefix for IV is 89F52F65A1C580933B52
Size of binary file is 41 bytes Size of binary file is 41 bytes
16( 16(
[ [
/ protected h'a1010a' / << { / protected h'a1010a' / << {
/ alg / 1:10 / AES-CCM-16-64-128 / / alg / 1:10 / AES-CCM-16-64-128 /
} >> , } >> ,
/ unprotected / { / unprotected / {
/ partial iv / 6:h'61a7' / partial iv / 6:h'61a7'
}, },
/ ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05 / ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05
3bd09abca' 3bd09abca'
] ]
) )
skipping to change at line 3239 skipping to change at line 3240
This example uses the following: This example uses the following:
* MAC: AES-CMAC, 256-bit key, truncated to 64 bits * MAC: AES-CMAC, 256-bit key, truncated to 64 bits
* Recipient class: direct shared secret * Recipient class: direct shared secret
Size of binary file is 57 bytes Size of binary file is 57 bytes
97( 97(
[ [
/ protected h'a1010f' / << { / protected h'a1010f' / << {
/ alg / 1:15 / AES-CBC-MAC-256//64 / / alg / 1:15 / AES-CBC-MAC-256//64 /
} >> , } >> ,
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ tag / h'9e1226ba1f81b848', / tag / h'9e1226ba1f81b848',
/ recipients / [ / recipients / [
[ [
/ protected / h'', / protected / h'',
/ unprotected / { / unprotected / {
/ alg / 1:-6 / direct /, / alg / 1:-6 / direct /,
skipping to change at line 3271 skipping to change at line 3272
* MAC: HMAC w/SHA-256, 256-bit key * MAC: HMAC w/SHA-256, 256-bit key
* Recipient class: ECDH key agreement, two static keys, HKDF w/ * Recipient class: ECDH key agreement, two static keys, HKDF w/
context structure context structure
Size of binary file is 214 bytes Size of binary file is 214 bytes
97( 97(
[ [
/ protected h'a10105' / << { / protected h'a10105' / << {
/ alg / 1:5 / HMAC 256//256 / / alg / 1:5 / HMAC 256//256 /
} >> , } >> ,
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99 / tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99
4bc3f16a41', 4bc3f16a41',
/ recipients / [ / recipients / [
[ [
/ protected h'a101381a' / << { / protected h'a101381a' / << {
/ alg / 1:-27 / ECDH-SS + HKDF-256 / / alg / 1:-27 / ECDH-SS + HKDF-256 /
} >> , } >> ,
/ unprotected / { / unprotected / {
/ static kid / -3:'peregrin.took@tuckborough.example', / static kid / -3:'peregrin.took@tuckborough.example',
/ kid / 4:'meriadoc.brandybuck@buckland.example', / kid / 4:'meriadoc.brandybuck@buckland.example',
/ U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d / U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d
19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583 19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583
68b017e7f2a9e5ce4db5' 68b017e7f2a9e5ce4db5'
}, },
/ ciphertext / h'' / ciphertext / h''
skipping to change at line 3308 skipping to change at line 3309
This example uses the following: This example uses the following:
* MAC: AES-MAC, 128-bit key, truncated to 64 bits * MAC: AES-MAC, 128-bit key, truncated to 64 bits
* Recipient class: AES Key Wrap w/ a preshared 256-bit key * Recipient class: AES Key Wrap w/ a preshared 256-bit key
Size of binary file is 109 bytes Size of binary file is 109 bytes
97( 97(
[ [
/ protected h'a1010e' / << { / protected h'a1010e' / << {
/ alg / 1:14 / AES-CBC-MAC-128//64 / / alg / 1:14 / AES-CBC-MAC-128//64 /
} >> , } >> ,
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ tag / h'36f5afaf0bab5d43', / tag / h'36f5afaf0bab5d43',
/ recipients / [ / recipients / [
[ [
/ protected / h'', / protected / h'',
/ unprotected / { / unprotected / {
/ alg / 1:-5 / A256KW /, / alg / 1:-5 / A256KW /,
skipping to change at line 3478 skipping to change at line 3479
C.7.2. Private Keys C.7.2. Private Keys
This is an example of a COSE Key Set. This example includes the This is an example of a COSE Key Set. This example includes the
private keys for all of the previous examples. private keys for all of the previous examples.
In order the keys are: In order the keys are:
* An EC key with a kid of "meriadoc.brandybuck@buckland.example" * An EC key with a kid of "meriadoc.brandybuck@buckland.example"
* An EC key with a kid of "11"
* An EC key with a kid of "bilbo.baggins@hobbiton.example"
* A shared-secret key with a kid of "our-secret" * A shared-secret key with a kid of "our-secret"
* An EC key with a kid of "peregrin.took@tuckborough.example" * An EC key with a kid of "peregrin.took@tuckborough.example"
* A shared-secret key with kid "our-secret2"
* A shared-secret key with a kid of "018c0ae5-4d9b-471b- * A shared-secret key with a kid of "018c0ae5-4d9b-471b-
bfd6-eef314bc7037" bfd6-eef314bc7037"
* An EC key with a kid of "bilbo.baggins@hobbiton.example"
* An EC key with a kid of "11"
Size of binary file is 816 bytes Size of binary file is 816 bytes
[ [
{ {
1:2, 1:2,
2:'meriadoc.brandybuck@buckland.example', 2:'meriadoc.brandybuck@buckland.example',
-1:1, -1:1,
-2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0 -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d', 8551d',
-3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008 -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
skipping to change at line 3578 skipping to change at line 3581
The following individuals provided input into the final form of the The following individuals provided input into the final form of the
document: Carsten Bormann, John Bradley, Brian Campbell, Michael document: Carsten Bormann, John Bradley, Brian Campbell, Michael
B. Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and B. Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and
Göran Selander. Göran Selander.
Author's Address Author's Address
Jim Schaad Jim Schaad
August Cellars August Cellars
Email: ietf@augustcellars.com
 End of changes. 46 change blocks. 
142 lines changed or deleted 145 lines changed or added

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

mirror server hosted at Truenetwork, Russian Federation.