rfc9338.original   rfc9338.txt 
COSE Working Group J. Schaad Internet Engineering Task Force (IETF) J. Schaad
Internet-Draft August Cellars Request for Comments: 9338 August Cellars
Updates: 9052 (if approved) R. Housley, Ed. STD: 96 December 2022
Intended status: Standards Track Vigil Security Updates: 9052
Expires: 24 March 2023 20 September 2022 Category: Standards Track
ISSN: 2070-1721
CBOR Object Signing and Encryption (COSE): Countersignatures CBOR Object Signing and Encryption (COSE): Countersignatures
draft-ietf-cose-countersign-10
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. CBOR Object Signing and for small code size and small message size. CBOR Object Signing and
Encryption (COSE) defines a set of security services for CBOR. This Encryption (COSE) defines a set of security services for CBOR. This
document defines a countersignature algorithm along with the needed document defines a countersignature algorithm along with the needed
header parameters and CBOR tags for COSE. This document updates RFC header parameters and CBOR tags for COSE. This document updates RFC
9052. 9052.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 March 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9338.
Copyright Notice Copyright Notice
Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 1.1. Requirements Terminology
1.2. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4 1.2. CBOR Grammar
1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 1.3. Document Terminology
2. Countersignature Header Parameters . . . . . . . . . . . . . 5 2. Countersignature Header Parameters
3. Version 2 Countersignatures . . . . . . . . . . . . . . . . . 6 3. Version 2 Countersignatures
3.1. Full Countersignatures . . . . . . . . . . . . . . . . . 7 3.1. Full Countersignatures
3.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 8 3.2. Abbreviated Countersignatures
3.3. Signing and Verification Process . . . . . . . . . . . . 8 3.3. Signing and Verification Process
4. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 10 4. CBOR Encoding Restrictions
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations
5.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . . 11 5.1. CBOR Tags Registry
5.2. COSE Header Parameters Registry . . . . . . . . . . . . . 11 5.2. COSE Header Parameters Registry
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 7. References
7.1. Author's Versions . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References
7.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 13 7.2. Informative References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Examples
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 A.1. Examples of Signed Messages
8.2. Informative References . . . . . . . . . . . . . . . . . 14 A.1.1. Countersignature
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 A.2. Examples of Signed1 Messages
A.1. Use of Early Code Points . . . . . . . . . . . . . . . . 16 A.2.1. Countersignature
A.2. Examples of Signed Messages . . . . . . . . . . . . . . . 16 A.3. Examples of Enveloped Messages
A.2.1. Countersignature . . . . . . . . . . . . . . . . . . 16 A.3.1. Countersignature on Encrypted Content
A.3. Examples of Signed1 Messages . . . . . . . . . . . . . . 17 A.4. Examples of Encrypted Messages
A.3.1. Countersignature . . . . . . . . . . . . . . . . . . 17 A.4.1. Countersignature on Encrypted Content
A.4. Examples of Enveloped Messages . . . . . . . . . . . . . 18 A.5. Examples of MACed Messages
A.4.1. Countersignature on Encrypted Content . . . . . . . . 18 A.5.1. Countersignature on MAC Content
A.5. Examples of Encrypted Messages . . . . . . . . . . . . . 19 A.6. Examples of MAC0 Messages
A.5.1. Countersignature on Encrypted Content . . . . . . . . 20 A.6.1. Countersignature on MAC0 Content
A.6. Examples of MACed Messages . . . . . . . . . . . . . . . 20 Acknowledgments
A.6.1. Countersignature on MAC Content . . . . . . . . . . . 20 Author's Address
A.7. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 21
A.7.1. Countersignature on MAC0 Content . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is "Concise Binary Object Representation come out of this process is "Concise Binary Object Representation
(CBOR)" [RFC8949]. CBOR extended the data model of the JavaScript (CBOR)" [RFC8949]. 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 method of encoding data groups dealing with the IoT world as their method of encoding data
structures. CBOR was designed specifically to be small in terms of structures. CBOR was designed specifically to be small in terms of
both messages transported and implementation size and to have a both messages transported and implementation size and to have a
schema-free decoder. A need exists to provide message security schema-free decoder. A need exists to provide message security
services for IoT, and using CBOR as the message-encoding format makes services for IoT, and using CBOR as the message-encoding format makes
sense. sense.
A countersignature is a second signature that confirms the primary A countersignature is a second signature that confirms the primary
signature. During the process of advancing COSE to Internet signature. During the process of advancing CBOR Object Signing and
Standard, it was noticed that the description of the security Encryption (COSE) to Internet Standard, it was noticed that the
properties of countersignatures was incorrect for the COSE_Sign1 description of the security properties of countersignatures was
structure in Section 4.5 of [RFC8152]. To remedy this situation, the incorrect for the COSE_Sign1 structure mentioned in Section 4.5 of
working group decided to remove all of the countersignature text from [RFC8152]. To remedy this situation, the COSE Working Group decided
[RFC9052], which obsoletes [RFC8152]. This document defines a new to remove all of the countersignature text from [RFC9052], which
countersignature with the desired security properties. obsoletes [RFC8152]. This document defines a new countersignature
with the desired security properties.
The problem with the previous countersignature algorithm was that the The problem with the previous countersignature algorithm was that the
cryptographically computed value was not always included. The cryptographically computed value was not always included. The
initial assumption that the cryptographic value was in the third slot initial assumption that the cryptographic value was in the third slot
of the array was known not to be true at the time, but in the case of of the array was known not to be true at the time, but in the case of
the MAC structures this was not deemed to be an issue. The new the Message Authentication Code (MAC) structures this was not deemed
algorithm defined in this document requires the inclusion of more to be an issue. The new algorithm defined in this document requires
values for the countersignature computation. The exception to this the inclusion of more values for the countersignature computation.
is the COSE_Signature structure where there is no cryptographic The exception to this is the COSE_Signature structure where there is
computed value. no cryptographically computed value.
The new algorithm defined in this document is designed to produce the The new algorithm defined in this document is designed to produce the
same countersignature value in those cases where the computed same countersignature value in those cases where the computed
cryptographic value was already included. This means that for those cryptographic value was already included. This means that for those
structures the only thing that would need to be done is to change the structures the only thing that would need to be done is to change the
value of the header parameter. value of the header parameter.
With the publication of this document, implementers are encouraged to With the publication of this document, implementers are encouraged to
migrate uses of the previous countersignature algorithm to the one migrate uses of the previous countersignature algorithm to the one
specified in this document. In particular, uses of specified in this document. In particular, uses of
skipping to change at page 4, line 18 skipping to change at line 147
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. CBOR Grammar 1.2. CBOR Grammar
CBOR grammar in this document uses the CBOR Data Definition Language CBOR grammar in this document uses the Concise Data Definition
(CDDL) [RFC8610]. Language (CDDL) [RFC8610].
The collected CDDL can be extracted from the XML version of this The collected CDDL can be extracted from the XML version of this
document via the following XPath expression below. (Depending on the document via the XPath expression below. (Depending on the XPath
XPath evaluator one is using, it may be necessary to deal with > evaluator one is using, it may be necessary to deal with > as an
as an entity.) entity.)
//sourcecode[@type='cddl']/text() //sourcecode[@type='cddl']/text()
CDDL expects the initial non-terminal symbol to be the first symbol CDDL expects the initial non-terminal symbol to be the first symbol
in the file. For this reason, the first fragment of CDDL is in the file. For this reason, the first fragment of CDDL is
presented here. presented here.
start = COSE_Countersignature_Tagged / Internal_Types start = COSE_Countersignature_Tagged / Internal_Types
; This is defined to make the tool quieter: ; This is defined to make the tool quieter:
Internal_Types = Countersign_structure / COSE_Countersignature0 Internal_Types = Countersign_structure / COSE_Countersignature0
The non-terminal Internal_Types is defined for dealing with the The non-terminal Internal_Types is defined for dealing with the
automated validation tools used during the writing of this document. automated validation tools used during the writing of this document.
It references those non-terminals that are used for security It references those non-terminals that are used for security
computations but are not emitted for transport. computations but are not emitted for transport.
1.3. Document Terminology 1.3. Document Terminology
In this document, we use the following terminology: In this document, we use the following terminology.
"Byte" is a synonym for "octet". "Byte" is a synonym for "octet".
Constrained Application Protocol (CoAP) is a specialized web transfer The Constrained Application Protocol (CoAP) is a specialized web
protocol for use in constrained systems. It is defined in [RFC7252]. transfer protocol for use in constrained systems. It is defined in
[RFC7252].
"Context" is used throughout the document to represent information "Context" is used throughout this document to represent information
that is not part of the COSE message. Information which is part of that is not part of the COSE message. Information that is part of
the context can come from different sources including: protocol the context can come from different sources, including protocol
interactions, associated key structures, and application interactions, associated key structures, and application
configuration. The context to use can be implicit, identified using configuration. The context to use can be implicit, identified using
the "kid context" header parameter defined in [RFC8613], or either the "kid context" header parameter defined in [RFC8613] or a
identified by a protocol-specific identifier. Context should protocol-specific identifier. Context should generally be included
generally be included in the cryptographic construction; for more in the cryptographic construction; for more details, see Section 4.4
details see Section 4.3 of [RFC9052]. of [RFC9052].
The term "byte string" is used for sequences of bytes, while the term The term "byte string" is used for sequences of bytes, while the term
"text string" is used for sequences of characters. "text string" is used for sequences of characters.
2. Countersignature Header Parameters 2. Countersignature Header Parameters
This section defines a set of common header parameters. A summary of This section defines a set of common header parameters. A summary of
these header parameters can be found in Table 1. This table should these header parameters can be found in Table 1. This table should
be consulted to determine the value of label and the type of the be consulted to determine the value of the label and the type of the
value. value.
The set of header parameters defined in this section are: The set of header parameters defined in this section is:
V2 countersignature: This header parameter holds one or more V2 countersignature: This header parameter holds one or more
countersignature values. Countersignatures provide a method of countersignature values. Countersignatures provide a method of
having a second party sign some data. The countersignature header having a second party sign some data. The countersignature header
parameter can occur as an unprotected attribute in any of the parameter can occur as an unprotected attribute in any of the
following structures that are defined in [RFC9052]: COSE_Sign1, following structures that are defined in [RFC9052]: COSE_Sign1,
COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0,
COSE_Mac, and COSE_Mac0. Details of version 2 countersignatures COSE_Mac, and COSE_Mac0. Details of version 2 countersignatures
are found in Section 3. are found in Section 3.
+===========+=====+========================+==========+=============+ +=================+=====+==========================+================+
|Name |Label|Value Type | Value | Description | |Name |Label| Value Type |Description |
| | | | Registry | | +=================+=====+==========================+================+
+===========+=====+========================+==========+=============+ |Countersignature |11 | COSE_Countersignature / |V2 |
|counter |TBD10|COSE_Countersignature / | | V2 counter | |version 2 | | [+ COSE_Countersignature |countersignature|
|signature | |[+ COSE_Countersignature| | signature | | | | ] |attribute |
|version 2 | |] | | attribute | +-----------------+-----+--------------------------+----------------+
+-----------+-----+------------------------+----------+-------------+ |Countersignature0|12 | COSE_Countersignature0 |V2 Abbreviated |
|counter |TBD11|COSE_Countersignature0 | | Abbreviated | |version 2 | | |Countersignature|
|signature 0| | | | Counter | +-----------------+-----+--------------------------+----------------+
|version 2 | | | | signature |
| | | | | vesion 2 |
+-----------+-----+------------------------+----------+-------------+
Table 1: Common Header Parameters Table 1: Common Header Parameters
The CDDL fragment that represents the set of header parameters The CDDL fragment that represents the set of header parameters
defined in this section is given below. Each of the header defined in this section is given below. Each of the header
parameters is tagged as optional because they do not need to be in parameters is tagged as optional because they do not need to be in
every map; however, the header parameters required in specific maps every map; however, the header parameters required in specific maps
are discussed above. are discussed above.
CountersignatureV2_header = ( CountersignatureV2_header = (
TBD10 => COSE_Countersignature / [+COSE_Countersignature] ? 11 => COSE_Countersignature / [+ COSE_Countersignature]
) )
Countersignature0V2_header = ( Countersignature0V2_header = (
TBD11 => COSE_Countersignature0 ? 12 => COSE_Countersignature0
) )
3. Version 2 Countersignatures 3. Version 2 Countersignatures
A countersignature is normally defined as a second signature that A countersignature is normally defined as a second signature that
confirms a primary signature. A normal example of a countersignature confirms a primary signature. A normal example of a countersignature
is the signature that a notary public places on a document as is the signature that a notary public places on a document as
witnessing that you have signed the document. A notary typically witnessing that you have signed the document. A notary typically
includes a timestamp to indicate when notarization occurs; however, includes a timestamp to indicate when notarization occurs; however,
such a timestamp has not yet been defined for COSE. A timestamp, such a timestamp has not yet been defined for COSE. A timestamp,
once defined in a future document, might be included as a protected once defined in a future document, might be included as a protected
header parameter. Thus applying a countersignature to either the header parameter. Thus, applying a countersignature to either the
COSE_Signature or COSE_Sign1 objects match this traditional COSE_Signature or COSE_Sign1 objects matches this traditional
definition. This document extends the context of a countersignature definition. This document extends the context of a countersignature
to allow it to be applied to all of the security structures defined. to allow it to be applied to all of the security structures defined.
The countersignature needs to be treated as a separate operation from The countersignature needs to be treated as a separate operation from
the initial operation even if it is applied by the same user as is the initial operation even if it is applied by the same user, as is
done in [I-D.ietf-core-oscore-groupcomm]. done in [GROUP-OSCORE].
COSE supports two different forms for countersignatures. Full COSE supports two different forms for countersignatures. Full
countersignatures use the structure COSE_Countersignature, which has countersignatures use the structure COSE_Countersignature, which has
the same structure as COSE_Signature. Thus, full countersignatures the same structure as COSE_Signature. Thus, full countersignatures
can have protected and unprotected attributes, including chained can have protected and unprotected attributes, including chained
countersignatures. Abbreviated countersignatures use the structure countersignatures. Abbreviated countersignatures use the structure
COSE_Countersignature0. This structure only contains the signature COSE_Countersignature0. This structure only contains the signature
value and nothing else. The structures cannot be converted between value and nothing else. The structures cannot be converted between
each other; as the signature computation includes a parameter each other; as the signature computation includes a parameter
identifying which structure is being used, the converted structure identifying which structure is being used, the converted structure
will fail signature validation. will fail signature validation.
The version 2 countersignature changes the algorithm used for The version 2 countersignature changes the algorithm used for
computing the signature from the original version that is specified computing the signature from the original version that is specified
Section 4.5 of [RFC8152]. The new version now includes the in Section 4.5 of [RFC8152]. The new version now includes the
cryptographic material generated for all of the structures rather cryptographic material generated for all of the structures rather
than just for a subset. than just for a subset.
COSE was designed for uniformity in how the data structures are COSE was designed for uniformity in how the data structures are
specified. One result of this is that for COSE one can expand the specified. One result of this is that for COSE one can expand the
concept of countersignatures beyond just the idea of signing a concept of countersignatures beyond just the idea of signing a
signature to being able to sign most of the structures without having signature to being able to sign most of the structures without having
to create a new signing layer. When creating a countersignature, one to create a new signing layer. When creating a countersignature, one
needs to be clear about the security properties that result. When needs to be clear about the security properties that result. When
done on a COSE_Signature or COSE_Sign1, the normal countersignature done on a COSE_Signature or COSE_Sign1, the normal countersignature
semantics are preserved. That is, the countersignature makes a semantics are preserved. That is, the countersignature makes a
statement about the existence of a signature and, when used with a statement about the existence of a signature and, when used with a
yet-to-be-specified timestamp, a point in time at which the signature yet-to-be-specified timestamp, a point in time at which the signature
exists. When done on a COSE_Mac or COSE_Mac0, the payload is exists. When done on a COSE_Mac or COSE_Mac0, the payload is
included as well as the MAC value. When done on a COSE_Encrypt or included as well as the MAC value. When done on a COSE_Encrypt or
COSE_Encrypt0, the existence of the encrypted data is attested to. COSE_Encrypt0, the existence of the encrypted data is attested to.
It should be noted that there is a distinction between attesting to It should be noted that there is a distinction between attesting to
the encrypted data as opposed to attesting to the unencrypted data. the encrypted data as opposed to attesting to the unencrypted data.
If the latter is what is desired, then one needs to apply a signature If the latter is what is desired, then one needs to apply a signature
to the data and then encrypt that. It is always possible to to the data and then encrypt that. It is always possible to
construct cases where the use of two different keys will appear to construct cases where the use of two different keys results in
result in a successful decryption (the tag check success), but which successful decryption, where the tag check succeeds, but two
produce two completely different plaintexts. This situation is not completely different plaintexts are produced. This situation is not
detectable by a countersignature on the encrypted data. detectable by a countersignature on the encrypted data.
3.1. Full Countersignatures 3.1. Full Countersignatures
The COSE_Countersignature structure allows for the same set of The COSE_Countersignature structure allows for the same set of
capabilities as a COSE_Signature. This means that all of the capabilities as a COSE_Signature. This means that all of the
capabilities of a signature are duplicated with this structure. capabilities of a signature are duplicated with this structure.
Specifically, the countersigner does not need to be related to the Specifically, the countersigner does not need to be related to the
producer of what is being countersigned as key and algorithm producer of what is being countersigned, as key and algorithm
identification can be placed in the countersignature attributes. identification can be placed in the countersignature attributes.
This also means that the countersignature can itself be This also means that the countersignature can itself be
countersigned. This is a feature required by protocols such as long- countersigned. This is a feature required by protocols such as long-
term archiving services. More information on how countersignatures term archiving services. More information on how countersignatures
are used can be found in the evidence record syntax described in are used can be found in the evidence record syntax described in
[RFC4998]. [RFC4998].
The full countersignature structure can be encoded as either tagged The full countersignature structure can be encoded as either tagged
or untagged depending on the context. A tagged COSE_Countersignature or untagged, depending on the context. A tagged
structure is identified by the CBOR tag TBD0. The countersignature COSE_Countersignature structure is identified by the CBOR tag 19.
structure is the same as that used for a signer on a signed object. The countersignature structure is the same as that used for a signer
The CDDL fragment for full countersignatures is: on a signed object. The CDDL fragment for full countersignatures is:
COSE_Countersignature_Tagged = #6.TBD0(COSE_Countersignature) COSE_Countersignature_Tagged = #6.19(COSE_Countersignature)
COSE_Countersignature = COSE_Signature COSE_Countersignature = COSE_Signature
The details of the fields of a countersignature can be found in The details of the fields of a countersignature can be found in
Section 4.1 of [RFC9052]. Section 4.1 of [RFC9052].
An example of a countersignature on a signature can be found in An example of a countersignature on a signature can be found in
Appendix A.2.1. An example of a countersignature in an encryption Appendix A.1.1. An example of a countersignature in an encryption
object can be found in Appendix A.4.1. object can be found in Appendix A.3.1.
It should be noted that only a signature algorithm with appendix (see It should be noted that only a signature algorithm with appendix (see
Section 8.1 of [RFC9052]) can be used for countersignatures. This is Section 8.1 of [RFC9052]) can be used for countersignatures. This is
because the body should be able to be processed without having to because the body should be able to be processed without having to
evaluate the countersignature, and this is not possible for signature evaluate the countersignature, and this is not possible for signature
schemes with message recovery. schemes with message recovery.
3.2. Abbreviated Countersignatures 3.2. Abbreviated Countersignatures
Abbreviated countersignatures support encrypted group messaging, Abbreviated countersignatures support encrypted group messaging where
where identification of the message originator is required, but there identification of the message originator is required but there is a
is a desire to keep the countersignature as small as possible. For desire to keep the countersignature as small as possible. For
abbreviated countersignatures, there is no provision for any abbreviated countersignatures, there is no provision for any
protected attributes related to the signing operation. That is, the protected attributes related to the signing operation. That is, the
parameters for computing or verifying the abbreviated parameters for computing or verifying the abbreviated
countersignature are provided by the same context used to describe countersignature are provided by the same context used to describe
the encryption, signature, or MAC processing. the encryption, signature, or MAC processing.
The CDDL fragment for the abbreviated countersignatures is: The CDDL fragment for the abbreviated countersignatures is:
COSE_Countersignature0 = bstr COSE_Countersignature0 = bstr
skipping to change at page 8, line 44 skipping to change at line 360
3.3. Signing and Verification Process 3.3. Signing and Verification Process
In order to create a signature, a well-defined byte string is needed. In order to create a signature, a well-defined byte string is needed.
The Countersign_structure is used to create the canonical form. This The Countersign_structure is used to create the canonical form. This
signing and verification process takes in the countersignature target signing and verification process takes in the countersignature target
structure (COSE_Signature, COSE_Sign1, COSE_Sign, COSE_Mac, structure (COSE_Signature, COSE_Sign1, COSE_Sign, COSE_Mac,
COSE_Mac0, COSE_Encrypt, or COSE_Encrypt0), the signer information COSE_Mac0, COSE_Encrypt, or COSE_Encrypt0), the signer information
(COSE_Signature), and the application data (external source). A (COSE_Signature), and the application data (external source). A
Countersign_structure is a CBOR array. The target structure of the Countersign_structure is a CBOR array. The target structure of the
countersignature needs to have all of its cryptographic functions countersignature needs to have all of its cryptographic functions
finalized before the computing the signature. The fields of the finalized before computing the signature. The fields of the
Countersign_structure in order are: Countersign_structure, in order, are:
context: A context text string identifying the context of the context: A context text string identifying the context of the
signature. The context text string is one of the following: signature. The context text string is one of the following:
"CounterSignature" for countersignatures using the * "CounterSignature" for countersignatures using the
COSE_Countersignature structure when other_fields is absent. COSE_Countersignature structure when other_fields is absent.
"CounterSignature0" for countersignatures using the * "CounterSignature0" for countersignatures using the
COSE_Countersignature0 structure when other_fields is absent. COSE_Countersignature0 structure when other_fields is absent.
"CounterSignatureV2" for countersignatures using the * "CounterSignatureV2" for countersignatures using the
COSE_Countersignature structure when other_fields is present. COSE_Countersignature structure when other_fields is present.
"CounterSignature0V2" for countersignatures using the * "CounterSignature0V2" for countersignatures using the
COSE_Countersignature0 structure when other_fields is present. COSE_Countersignature0 structure when other_fields is present.
body_protected: The serialized protected attributes from the target body_protected: The serialized protected attributes from the target
structure encoded in a bstr type. If there are no protected structure, encoded in a bstr type. If there are no protected
attributes, a zero-length byte string is used. attributes, a zero-length byte string is used.
sign_protected: The serialized protected attributes from the signer sign_protected: The serialized protected attributes from the signer
structure encoded in a bstr type. If there are no protected structure, encoded in a bstr type. If there are no protected
attributes, a zero-length byte string is used. This field is attributes, a zero-length byte string is used. This field is
omitted for the Countersignature0V2 attribute. omitted for the Countersignature0V2 attribute.
external_aad: The externally supplied additional authenticated data external_aad: The externally supplied additional authenticated data
(AAD) from the application is encoded in a bstr type. If this (AAD) from the application, encoded in a bstr type. If this field
field is not supplied, it defaults to a zero-length byte string. is not supplied, it defaults to a zero-length byte string. (See
(See Section 4.3 of [RFC9052] for application guidance on Section 4.4 of [RFC9052] for application guidance on constructing
constructing this field.) this field.)
payload: The payload to be signed encoded in a bstr type. The payload: The payload to be signed, encoded in a bstr type. The
payload is placed here independent of how it is transported. payload is placed here independently of how it is transported.
other_fields: If there are only two bstr fields in the target other_fields: Omitted if there are only two bstr fields in the
structure, this field is omitted. The field is an array of all target structure. This field is an array of all bstr fields after
bstr fields after the second. As an example, this would be an the second. As an example, this would be an array of one element
array of one element for the COSE_Sign1 structure containing the for the COSE_Sign1 structure containing the signature value.
signature value.
The CDDL fragment that describes the above text is: The CDDL fragment that describes the above text is:
Countersign_structure = [ Countersign_structure = [
context : "CounterSignature" / "CounterSignature0" / context : "CounterSignature" / "CounterSignature0" /
"CounterSignatureV2" / "CounterSignature0V2" /, "CounterSignatureV2" / "CounterSignature0V2" /,
body_protected : empty_or_serialized_map, body_protected : empty_or_serialized_map,
? sign_protected : empty_or_serialized_map, ? sign_protected : empty_or_serialized_map,
external_aad : bstr, external_aad : bstr,
payload : bstr, payload : bstr,
? other_fields : [ + bstr ] ? other_fields : [+ bstr ]
] ]
How to compute a countersignature: How to compute a countersignature:
1. Create a Countersign_structure and populate it with the 1. Create a Countersign_structure and populate it with the
appropriate fields. appropriate fields.
2. Create the value ToBeSigned by encoding the Countersign_structure 2. Create the value ToBeSigned by encoding the Countersign_structure
to a byte string, using the encoding described in Section 4. to a byte string, using the encoding described in Section 4.
3. Call the signature creation algorithm passing in K (the key to 3. Call the signature creation algorithm passing in K (the key to
sign with), alg (the algorithm to sign with), and ToBeSigned (the sign with), alg (the algorithm to sign with), and ToBeSigned (the
value to sign). value to sign).
4. Place the resulting signature value in the correct location. 4. Place the resulting signature value in the correct location.
This is the "signature" field of the COSE_Countersignature This is the "signature" field of the COSE_Countersignature
structure for full countersignatures (see Section 3.1). This is structure for full countersignatures (see Section 3.1). This is
the value of the Countersignature0 attribute for abbreviated the value of the Countersignature0 attribute for abbreviated
countersignatures (see Section 3.2). countersignatures (see Section 3.2).
The steps for verifying a countersignature are: The steps for verifying a countersignature:
1. Create a Countersign_structure and populate it with the 1. Create a Countersign_structure and populate it with the
appropriate fields. appropriate fields.
2. Create the value ToBeSigned by encoding the Countersign_structure 2. Create the value ToBeSigned by encoding the Countersign_structure
to a byte string, using the encoding described in Section 4. to a byte string, using the encoding described in Section 4.
3. Call the signature verification algorithm passing in K (the key 3. Call the signature verification algorithm passing in K (the key
to verify with), alg (the algorithm used sign with), ToBeSigned to verify with), alg (the algorithm used to sign with),
(the value to sign), and sig (the signature to be verified). ToBeSigned (the value to sign), and sig (the signature to be
verified).
In addition to performing the signature verification, the application In addition to performing the signature verification, the application
performs the appropriate checks to ensure that the key is correctly performs the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the signing identity is paired with the signing identity and that the signing identity is
authorized before performing actions. authorized before performing actions.
4. CBOR Encoding Restrictions 4. CBOR Encoding Restrictions
The deterministic encoding rules are defined in Section 4.2 of The deterministic encoding rules are defined in Section 4.2 of
[RFC8949]. These rules are further narrowed in Section 9 of [RFC8949]. These rules are further narrowed in Section 9 of
[RFC9052]. The narrowed deterministic encoding rules MUST be used to [RFC9052]. The narrowed deterministic encoding rules MUST be used to
ensure that all implementations generate the same byte string for the ensure that all implementations generate the same byte string for the
"to be signed" value. "to be signed" value.
5. IANA Considerations 5. IANA Considerations
The registries and registrations listed below were created during The registries and registrations listed below were created during the
processing of [RFC8152]. The majority of the actions are to update processing of [RFC8152]. The majority of the actions are to update
the references to point to this document. the references to point to this document.
5.1. CBOR Tag Assignment 5.1. CBOR Tags Registry
IANA is requested to assign a new tag for the CounterSignature type
in the "CBOR Tags" registry.
* Tag: TBD0
* Data Item: COSE_Countersignature IANA created a registry titled "CBOR Tags" registry as part of
processing RFC 7049, which was subsequently replaced by [RFC8949].
* Semantics: COSE standalone V2 countersignature IANA has assigned a new tag for the CounterSignature type in the
"CBOR Tags" registry.
* Reference: [[this document]] Tag: 19
Data Item: COSE_Countersignature
Semantics: COSE standalone V2 countersignature
Reference: RFC 9338
5.2. COSE Header Parameters Registry 5.2. COSE Header Parameters Registry
IANA created a registry titled "COSE Header Parameters" as part of IANA created a registry titled "COSE Header Parameters" as part of
processing [RFC8152]. processing [RFC8152].
IANA is requested to register the following new items in the IANA has registered the Countersignature version 2 (label 11) and
registry. For these entries, the Value Registry column will be blank Countersignature0 version 2 (label 12) in the "COSE Header
and the Reference column will be [[This Document]]. Parameters" registry. For these entries, the "Value Type" and
"Description" are shown in Table 1, the "Value Registry" is blank,
and the "Reference" is "RFC 9338".
+===================+=====+========================+================+ +=================+=====+==========================+================+
| Name |Label|Value Type |Description | |Name |Label| Value Type |Description |
+===================+=====+========================+================+ +=================+=====+==========================+================+
| Countersignature |TBD10|COSE_Countersignature / |V2 | |Countersignature |11 | COSE_Countersignature / |V2 |
| version 2 | |[+ COSE_Countersignature|countersignature| |version 2 | | [+ COSE_Countersignature |countersignature|
| | |] |attribute | | | | ] |attribute |
+-------------------+-----+------------------------+----------------+ +-----------------+-----+--------------------------+----------------+
| Countersignature0 |TBD11|COSE_Countersignature0 |V2 Abbreviated | |Countersignature0|12 | COSE_Countersignature0 |V2 Abbreviated |
| version 2 | | |Countersignature| |version 2 | | |Countersignature|
+-------------------+-----+------------------------+----------------+ +-----------------+-----+--------------------------+----------------+
Table 2: New Common Header Parameters Table 2: New Common Header Parameters
IANA is requested to modify the Description field for "counter IANA has modified the existing "Description" field for "counter
signature" and "CounterSignature0" to include the words "(Deprecated signature" (7) and "CounterSignature0" (9) to include the words
by [[This Document]])". "(Deprecated by RFC 9338)".
6. Security Considerations 6. Security Considerations
Please review the Security Consideration in [RFC9052]; these Please review the Security Considerations section in [RFC9052]; these
considerations apply to this document as well, especially the need considerations apply to this document as well, especially the need
for implementations to protect private key material. for implementations to protect private key material.
When either COSE_Encrypt and COSE_Mac is used and more than two When either COSE_Encrypt or COSE_Mac is used and more than two
parties share the key, data origin authentication is not provided. parties share the key, data origin authentication is not provided.
Any party that knows the message-authentication key can compute a Any party that knows the message-authentication key can compute a
valid authentication tag; therefore, the contents could originate valid authentication tag; therefore, the contents could originate
from any one of the parties that share the key. from any one of the parties that share the key.
Countersignatures of COSE_Encrypt and COSE_Mac with short Countersignatures of COSE_Encrypt and COSE_Mac with short
authentication tags do not provide the security properties associated authentication tags do not provide the security properties associated
with the same algorithm used in COSE_Sign. To provide 128-bit with the same algorithm used in COSE_Sign. To provide 128-bit
security against collision attacks, the tag length MUST be at least security against collision attacks, the tag length MUST be at least
256-bits. A countersignature of a COSE_Mac with AES-MAC (using a 256 bits. A countersignature of a COSE_Mac with AES-MAC (using a
128-bit key or larger) provides at most 64 bits of integrity 128-bit key or larger) provides at most 64 bits of integrity
protection. Similarly, a countersignature of a COSE_Encrypt with protection. Similarly, a countersignature of a COSE_Encrypt with
AES-CCM-16-64-128 provides at most 32 bits of integrity protection. AES-CCM-16-64-128 provides at most 32 bits of integrity protection.
7. Implementation Status 7. References
This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
7.1. Author's Versions
There are three different implementations that have been created by
the author of the document both to create the examples that are
included in the document and to validate the structures and
methodology used in the design of COSE.
* Implementation Location: https://github.com/cose-wg
* Primary Maintainer: Jim Schaad
* Languages: There are two different languages that are currently
supported: Java and C#.
* Cryptography: The Java and C# libraries use Bouncy Castle to
provide the required cryptography.
* Coverage: Both implementations can produce and consume both the
old and new countersignatures.
* Testing: All of the examples in the example library are generated
by the C# library and then validated using the Java and C
libraries. Both libraries have tests to allow for the creating of
the same messages that are in the example library followed by
validating them. These are not compared against the example
library. The Java and C# libraries have unit testing included.
Not all of the MUST statements in the document have been
implemented as part of the libraries. One such statement is the
requirement that unique labels be present.
* Licensing: Revised BSD License
7.2. COSE Testing Library
* Implementation Location: https://github.com/cose-wg/Examples
* Primary Maintainer: Jim Schaad
* Description: A set of tests for the COSE library is provided as
part of the implementation effort. Both success and fail tests
have been provided. All of the examples in this document are part
of this example set.
* Coverage: An attempt has been made to have test cases for every
message type and algorithm in the document. However, examples
dealing with countersignatures, and ECDH with Curve25519 and
Goldilocks are missing.
* Licensing: Public Domain
8. References
8.1. Normative References 7.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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>. <https://www.rfc-editor.org/info/rfc9052>.
8.2. Informative References 7.2. Informative References
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[STD90] Turner, S., "EST (Enrollment over Secure Transport) [CBORDIAG] Bormann, C., "CBOR diagnostic utilities", commit 1952a04,
Extensions", RFC 8295, January 2018. September 2022, <https://github.com/cabo/cbor-diag>.
<https://www.rfc-editor.org/info/std90> [GROUP-OSCORE]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and
J. Park, "Group OSCORE - Secure Group Communication for
CoAP", Work in Progress, Internet-Draft, draft-ietf-core-
oscore-groupcomm-16, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-groupcomm-16>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Representation (CBOR)", STD 94, RFC 8949, Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
DOI 10.17487/RFC8949, December 2020, August 2007, <https://www.rfc-editor.org/info/rfc4998>.
<https://www.rfc-editor.org/info/rfc8949>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
Code: The Implementation Status Section", BCP 205, RFC 8152, DOI 10.17487/RFC8152, July 2017,
RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc8152>.
<https://www.rfc-editor.org/info/rfc7942>.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
August 2007, <https://www.rfc-editor.org/info/rfc4998>.
[I-D.ietf-core-oscore-groupcomm] [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., Definition Language (CDDL): A Notational Convention to
and J. Park, "Group OSCORE - Secure Group Communication Express Concise Binary Object Representation (CBOR) and
for CoAP", Work in Progress, Internet-Draft, draft-ietf- JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
core-oscore-groupcomm-15, 5 September 2022, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
<https://www.ietf.org/archive/id/draft-ietf-core-oscore-
groupcomm-15.txt>.
[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>.
[CBORDIAG] Bormann, C., "CBOR diagnostic utilities", [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
<https://github.com/cabo/cbor-diag>. Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017.
<https://www.rfc-editor.org/info/std90>
Appendix A. Examples Appendix A. Examples
This appendix includes a set of examples that show the different This appendix includes a set of examples that show the different
features and message types that have been defined in this document. features and message types that have been defined in this document.
To make the examples easier to read, they are presented using the To make the examples easier to read, they are presented using the
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.
The examples are presented using the CBOR's diagnostic notation. A The examples are presented using the CBOR diagnostic notation. A
Ruby-based tool exists [CBORDIAG] that can convert between the Ruby-based tool exists [CBORDIAG] that can convert between the
diagnostic notation and binary. The referenced webpage includes diagnostic notation and binary. The referenced webpage includes
installation instructions. installation instructions.
The diagnostic notation can be converted into binary files using the The diagnostic notation can be converted into binary files using the
following command line: following command line:
diag2cbor.rb < inputfile > outputfile diag2cbor.rb < inputfile > outputfile
The examples can be extracted from the XML version of this document The examples can be extracted from the XML version of this document
via an XPath expression as all of the sourcecode is tagged with the via an XPath expression, as all of the sourcecode is tagged with the
attribute type="CBORdiag". (Depending on the XPath evaluator one is attribute 'type="cbor-diag"'. (Depending on the XPath evaluator one
using, it may be necessary to deal with &gt; as an entity.) is using, it may be necessary to deal with &gt; as an entity.)
//sourcecode[@type='CDDL']/text() //sourcecode[@type='cbor-diag']/text()
A.1. Use of Early Code Points This appendix uses the following terms:
This section is to be removed before publishing as an RFC. AES-GCM: AES Galois/Counter Mode
The examples in this Appendix use code points proposed for early CEK: content-encryption key
allocation by IANA. When IANA makes the allocation, these examples
will be updated as needed.
A.2. Examples of Signed Messages ECDH: Elliptic Curve Diffie-Hellman
A.2.1. Countersignature ECDH-ES: Elliptic Curve Diffie-Hellman Ephemeral Static
ECDSA: Elliptic Curve Digital Signature Algorithm
EdDSA: Edwards-curve Digital Signature Algorithm
HKDF: HMAC-based Key Derivation Function
HMAC: Hashed Message Authentication Code
A.1. Examples of Signed Messages
A.1.1. Countersignature
This example uses the following: This example uses the following:
* Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 Signature Algorithm: ECDSA with SHA-256, Curve P-256
* The same header parameters are used for both the signature and the The same header parameters are used for both the signature and the
countersignature. countersignature.
The size of the binary file is 180 bytes.
Size of binary file is 180 bytes
98( 98(
[ [
/ protected / h'', / protected / h'',
/ unprotected / { / unprotected / {
/ countersign / 11:[ / countersign / 11:[
/ protected h'a10126' / << { / protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ kid / 4:'11' / kid / 4: '11'
}, },
/ signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4 / signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4
9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e 9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e
8802bb6650cceb2c' 8802bb6650cceb2c'
] ]
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signatures / [ / signatures / [
[ [
/ protected h'a10126' / << { / protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ kid / 4:'11' / kid / 4: '11'
}, },
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b 5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a' 98f53afd2fa0f30a'
] ]
] ]
] ]
) )
A.3. Examples of Signed1 Messages A.2. Examples of Signed1 Messages
A.3.1. Countersignature A.2.1. Countersignature
This example uses the following: This example uses the following:
* Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 Signature Algorithm: ECDSA with SHA-256, Curve P-256
* Countersignature Algorithm: ECDSA w/ SHA-512, Curve P-521 Countersignature Algorithm: ECDSA with SHA-512, Curve P-521
The size of the binary file is 275 bytes.
Size of binary file is 275 bytes
18( 18(
[ [
/ protected h'A201260300' / << { / protected h'A201260300' / << {
/ alg / 1:-7, / ECDSA 256 / / alg / 1:-7, / ECDSA 256 /
/ ctyp / 3:0 / ctyp / 3:0
} >>, } >>,
/ unprotected / { / unprotected / {
/ kid / 4: "11", / kid / 4: '11',
/ countersign / 11: [ / countersign / 11: [
/ protected h'A1013823' / << { / protected h'A1013823' / << {
/ alg / 1:-36 / ECDSA 512 / / alg / 1:-36 / ECDSA 512 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ kid / 4: "bilbo.baggins@hobbiton.example" / kid / 4: 'bilbo.baggins@hobbiton.example'
}, },
/ signature / h'01B1291B0E60A79C459A4A9184A0D393E034B34AF069 / signature / h'01B1291B0E60A79C459A4A9184A0D393E034B34AF069
A1CCA34F5A913AFFFF698002295FA9F8FCBFB6FDFF59132FC0C406E98754A98F1FBF A1CCA34F5A913AFFFF698002295FA9F8FCBFB6FDFF59132FC0C406E98754A98F1FBF
E81C03095F481856BC470170227206FA5BEE3C0431C56A66824E7AAF692985952E31 E81C03095F481856BC470170227206FA5BEE3C0431C56A66824E7AAF692985952E31
271434B2BA2E47A335C658B5E995AEB5D63CF2D0CED367D3E4CC8FFFD53B70D115BA 271434B2BA2E47A335C658B5E995AEB5D63CF2D0CED367D3E4CC8FFFD53B70D115BA
A9E86961FBD1A5CF' A9E86961FBD1A5CF'
] ]
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signature / h'BB587D6B15F47BFD54D2CBFCECEF75451E92B08A514BD439 / signature / h'BB587D6B15F47BFD54D2CBFCECEF75451E92B08A514BD439
FA3AA65C6AC92DF0D7328C4A47529B32ADD3DD1B4E940071C021E9A8F2641F1D8E3B FA3AA65C6AC92DF0D7328C4A47529B32ADD3DD1B4E940071C021E9A8F2641F1D8E3B
053DDD65AE52' 053DDD65AE52'
] ]
) )
A.4. Examples of Enveloped Messages A.3. Examples of Enveloped Messages
A.4.1. Countersignature on Encrypted Content A.3.1. Countersignature on Encrypted Content
This example uses the following: This example uses the following:
* CEK: AES-GCM w/ 128-bit key CEK: AES-GCM with 128-bit key
* Recipient class: ECDH Ephemeral-Static, Curve P-256 Recipient Class: ECDH Ephemeral-Static, Curve P-256
* Countersignature Algorithm: ECDSA w/ SHA-512, Curve P-521 Countersignature Algorithm: ECDSA with SHA-512, Curve P-521
The size of the binary file is 326 bytes.
Size of binary file is 326 bytes
96( 96(
[ [
/ protected h'a10101' / << { / protected h'a10101' / << {
/ alg / 1:1 / AES-GCM 128 / / alg / 1:1 / AES-GCM 128 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ iv / 5:h'c9cf4df2fe6c632bf7886413', / iv / 5:h'c9cf4df2fe6c632bf7886413',
/ countersign / 11:[ / countersign / 11:[
/ protected h'a1013823' / << { / protected h'a1013823' / << {
/ alg / 1:-36 / ES512 / / alg / 1:-36 / ES512 /
} >> , } >>,
/ unprotected / { / unprotected / {
/ kid / 4:'bilbo.baggins@hobbiton.example' / kid / 4: 'bilbo.baggins@hobbiton.example'
}, },
/ signature / h'00929663c8789bb28177ae28467e66377da12302d7f9 / signature / h'00929663c8789bb28177ae28467e66377da12302d7f9
594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f 594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f
cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00 cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00
3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c 3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c
c3430c9d65e7ddff' c3430c9d65e7ddff'
] ]
}, },
/ ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0 / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0', c52a357da7a644b8070a151b0',
/ recipients / [ / recipients / [
[ [
/ 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'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280', bf054e1c7b4d91d6280',
/ y / -3:true / y / -3:true
}, },
/ kid / 4:'meriadoc.brandybuck@buckland.example' / kid / 4: 'meriadoc.brandybuck@buckland.example'
}, },
/ ciphertext / h'' / ciphertext / h''
] ]
] ]
] ]
) )
A.5. Examples of Encrypted Messages A.4. Examples of Encrypted Messages
A.5.1. Countersignature on Encrypted Content
A.4.1. Countersignature on Encrypted Content
This example uses the following: This example uses the following:
* CEK: AES-GCM w/ 128-bit key CEK: AES-GCM with 128-bit key
* Countersignature algorithm: EdDSA with Curve Ed25519 Countersignature Algorithm: EdDSA with Curve Ed25519
Size of binary file is 136 bytes The size of the binary file is 136 bytes.
16( 16(
[ [
/ 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',
/ countersign / 11: [ / countersign / 11: [
/ protected h'A10127' / << { / protected h'A10127' / << {
skipping to change at page 20, line 38 skipping to change at line 814
/ signature / h'E10439154CC75C7A3A5391491F88651E0292FD0FE0E0 / signature / h'E10439154CC75C7A3A5391491F88651E0292FD0FE0E0
2CF740547EAF6677B4A4040B8ECA16DB592881262F77B14C1A086C02268B17171CA1 2CF740547EAF6677B4A4040B8ECA16DB592881262F77B14C1A086C02268B17171CA1
6BE4B8595F8C0A08' 6BE4B8595F8C0A08'
] ]
}, },
/ ciphertext / h'60973A94BB2898009EE52ECFD9AB1DD25867374B162E2C0 / ciphertext / h'60973A94BB2898009EE52ECFD9AB1DD25867374B162E2C0
3568B41F57C3CC16F9166250A' 3568B41F57C3CC16F9166250A'
] ]
) )
A.6. Examples of MACed Messages A.5. Examples of MACed Messages
A.6.1. Countersignature on MAC Content A.5.1. Countersignature on MAC Content
This example uses the following: This example uses the following:
* MAC algorithm: HMAC/SHA-256 with 256-bit key MAC Algorithm: HMAC/SHA-256 with 256-bit key
* Countersignature algorithm: EdDSA with Curve Ed25519 Countersignature Algorithm: EdDSA with Curve Ed25519
The size of the binary file is 159 bytes.
Size of binary file is 159 bytes
97( 97(
[ [
/ protected h'A10105' / << { / protected h'A10105' / << {
/ alg / 1:5 / HS256 / / alg / 1:5 / HS256 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ countersign / 11: [ / countersign / 11: [
/ protected h'A10127' / << { / protected h'A10127' / << {
/ alg / 1:-8 / EdDSA / / alg / 1:-8 / EdDSA /
} >>, } >>,
skipping to change at page 21, line 38 skipping to change at line 860
/ unprotected / { / unprotected / {
/ alg / 1: -6, / direct / / alg / 1: -6, / direct /
/ kid / 4: 'our-secret' / kid / 4: 'our-secret'
}, },
/ ciphertext / h'' / ciphertext / h''
] ]
] ]
] ]
) )
A.7. Examples of MAC0 Messages A.6. Examples of MAC0 Messages
A.7.1. Countersignature on MAC0 Content A.6.1. Countersignature on MAC0 Content
This example uses the following: This example uses the following:
* MAC algorithm: HMAC/SHA-256 with 256-bit key MAC Algorithm: HMAC/SHA-256 with 256-bit key
* Countersignature algorithm: EdDSA with Curve Ed25519 Countersignature Algorithm: EdDSA with Curve Ed25519
The size of the binary file is 159 bytes.
Size of binary file is 159 bytes
17( 17(
[ [
/ protected h'A10105' / << { / protected h'A10105' / << {
/ alg / 1:5 / HS256 / / alg / 1:5 / HS256 /
} >>, } >>,
/ unprotected / { / unprotected / {
/ countersign / 11: [ / countersign / 11: [
/ protected h'A10127' / << { / protected h'A10127' / << {
/ alg / 1:-8 / EdDSA / / alg / 1:-8 / EdDSA /
} >>, } >>,
skipping to change at page 22, line 30 skipping to change at line 898
] ]
}, },
/ payload / 'This is the content.', / payload / 'This is the content.',
/ tag / h'A1A848D3471F9D61EE49018D244C824772F223AD4F935293F1789F / tag / h'A1A848D3471F9D61EE49018D244C824772F223AD4F935293F1789F
C3A08D8C58' C3A08D8C58'
] ]
) )
Acknowledgments Acknowledgments
This document is a product of the COSE working group of the IETF. This document is a product of the COSE Working Group of the IETF.
The initial version of the specification was based to some degree on The initial draft version of the specification was based to some
the outputs of the JOSE and S/MIME working groups. degree on the outputs of the JOSE and S/MIME Working Groups.
Jim Schaad passed on 3 October 2020. This document is primarily his Jim Schaad passed on 3 October 2020. This document is primarily his
work. Russ Housley served as the document editor after Jim's work. Russ Housley served as the document editor after Jim's
untimely death, mostly helping with the approval and publication untimely death, mostly helping with the approval and publication
processes. Jim deserves all credit for the technical content. processes. Jim deserves all credit for the technical content.
Jim Schaad and Jonathan Hammell provided the examples in the Jim Schaad and Jonathan Hammell provided the examples in Appendix A.
Appendix.
The reviews by Carsten Borman, Ben Kaduk, and Elwyn Davies greatly The reviews by Carsten Bormann, Ben Kaduk, and Elwyn Davies greatly
improved the clarity of the document. improved the clarity of the document.
{{{ RFC EDITOR: Please remove Russ Housley as an author of this Author's Address
document at publication. Jim Schaad should be listed as the sole
author. }}}
Authors' Addresses
Jim Schaad Jim Schaad
August Cellars August Cellars
United States of America United States of America
Email: ietf@augustcellars.com
Russ Housley (editor)
Vigil Security, LLC
United States of America
Email: housley@vigilsec.com
 End of changes. 113 change blocks. 
350 lines changed or deleted 279 lines changed or added

This html diff was produced by rfcdiff 1.48.