draft-ietf-cose-countersign-01.txt   draft-ietf-cose-countersign-02.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Intended status: Standards Track R. Housley, Ed. Intended status: Standards Track R. Housley, Ed.
Expires: 10 April 2021 Vigil Security Expires: 19 June 2021 Vigil Security
7 October 2020 16 December 2020
CBOR Object Signing and Encryption (COSE): Countersignatures CBOR Object Signing and Encryption (COSE): Countersignatures
draft-ietf-cose-countersign-01 draft-ietf-cose-countersign-02
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. header parameters and CBOR tags for COSE.
Contributing to this document Contributing to this document
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 April 2021. This Internet-Draft will expire on 19 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4
1.2. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4 1.2. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4
2. Countersignature Header Parameters . . . . . . . . . . . . . 5 2. Countersignature Header Parameters . . . . . . . . . . . . . 5
3. Version 2 Countersignatures . . . . . . . . . . . . . . . . . 6 3. Version 2 Countersignatures . . . . . . . . . . . . . . . . . 6
3.1. Full Countersignatures . . . . . . . . . . . . . . . . . 7 3.1. Full Countersignatures . . . . . . . . . . . . . . . . . 7
3.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 8 3.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 8
3.3. Signing and Verification Process . . . . . . . . . . . . 8 3.3. Signing and Verification Process . . . . . . . . . . . . 8
4. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 10 4. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . . 10 5.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . . 10
5.2. COSE Header Parameters Registry . . . . . . . . . . . . . 11 5.2. COSE Header Parameters Registry . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
7.1. Author's Versions . . . . . . . . . . . . . . . . . . . . 14 7.1. Author's Versions . . . . . . . . . . . . . . . . . . . . 13
7.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 14 7.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16
A.1. Examples of Signed Messages . . . . . . . . . . . . . . . 17 A.1. Use of Early Code Points . . . . . . . . . . . . . . . . 17
A.1.1. Countersignature . . . . . . . . . . . . . . . . . . 17 A.2. Examples of Signed Messages . . . . . . . . . . . . . . . 17
A.2. Examples of Enveloped Messages . . . . . . . . . . . . . 18 A.2.1. Countersignature . . . . . . . . . . . . . . . . . . 17
A.2.1. Countersignature on Encrypted Content . . . . . . . . 18 A.3. Examples of Signed1 Messages . . . . . . . . . . . . . . 18
A.3. Examples of Encrypted Messages . . . . . . . . . . . . . 19 A.3.1. Countersignature . . . . . . . . . . . . . . . . . . 18
A.4. Examples of MACed Messages . . . . . . . . . . . . . . . 19 A.4. Examples of Enveloped Messages . . . . . . . . . . . . . 19
A.5. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 20 A.4.1. Countersignature on Encrypted Content . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.5. Examples of Encrypted Messages . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 A.5.1. Countersignature on Encrypted Content . . . . . . . . 21
A.6. Examples of MACed Messages . . . . . . . . . . . . . . . 21
A.6.1. Countersignature on MAC Content . . . . . . . . . . . 21
A.7. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 22
A.7.1. Countersignature on MAC0 Content . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the (CBOR)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the
JavaScript Object Notation (JSON) [STD90] by allowing for binary JavaScript Object Notation (JSON) [STD90] by allowing for binary
data, among other changes. CBOR has been adopted by several of the data, among other changes. CBOR has been adopted by several of the
IETF working groups dealing with the IoT world as their encoding of IETF working groups dealing with the IoT world as their encoding of
skipping to change at page 7, line 38 skipping to change at page 7, line 44
The countersignature structure is the same as that used for a signer The countersignature structure is the same as that used for a signer
on a signed object. The CDDL fragment for full countersignatures is: on a signed object. The CDDL fragment for full countersignatures is:
COSE_Countersignature_Tagged = #6.9999(COSE_Countersignature) COSE_Countersignature_Tagged = #6.9999(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 [I-D.ietf-cose-rfc8152bis-struct]. Section 4.1 of [I-D.ietf-cose-rfc8152bis-struct].
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.1.1. An example of a countersignature in an encryption Appendix A.2.1. An example of a countersignature in an encryption
object can be found in Appendix A.2.1. object can be found in Appendix A.4.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 of [I-D.ietf-cose-rfc8152bis-struct]) can be used for Section 8 of [I-D.ietf-cose-rfc8152bis-struct]) can be used for
countersignatures. This is because the body should be able to be countersignatures. This is because the body should be able to be
processed without having to evaluate the countersignature, and this processed without having to evaluate the countersignature, and this
is not possible for signature schemes with message recovery. is not possible for signature schemes with message recovery.
3.2. Abbreviated Countersignatures 3.2. Abbreviated Countersignatures
Abbreviated countersignatures were designed primarily to deal with Abbreviated countersignatures were designed primarily to deal with
skipping to change at page 11, line 11 skipping to change at page 11, line 11
* Semantics: COSE standalone V2 countersignature * Semantics: COSE standalone V2 countersignature
* Reference: [[this document]] * Reference: [[this document]]
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 is requested to register the following new items in the
registry. registry. For these entries, the Value Registry column will be blank
and the Reference column will be [[This Document]].
+=================+=====+======================+========+================+ +===================+=====+========================+================+
|Name |Label|Value Type |Value |Description | | Name |Label|Value Type |Description |
| | | |Registry| | +===================+=====+========================+================+
+=================+=====+======================+========+================+ | counter signature |TBD10|COSE_Countersignature / |V2 |
|counter signature|TBD10|COSE_Countersignature | |V2 | | version 2 | |[+ COSE_Countersignature|countersignature|
|version 2 | |/ [+ | |countersignature| | | |] |attribute |
| | |COSE_Countersignature | |attribute | +-------------------+-----+------------------------+----------------+
| | |] | | | | Countersignature0 |TBD11|COSE_Countersignature0 |Abbreviated |
+-----------------+-----+----------------------+--------+----------------+ | version 2 | | |Counter |
|Countersignature0|TBD11|COSE_Countersignature0| |Abbreviated | | | | |signature vesion|
|version 2 | | | |Counter | | | | |2 |
| | | | |signature vesion| +-------------------+-----+------------------------+----------------+
| | | | |2 |
+-----------------+-----+----------------------+--------+----------------+
Table 2: New Common Header Parameters Table 2: New Common Header Parameters
IANA is requested to modify the Description field for "counter IANA is requested to modify the Description field for "counter
signature" and "CounterSignature0" to include the words "(Deprecated signature" and "CounterSignature0" to include the words "(Deprecated
by [[This Document]]". by [[This Document]]".
6. Security Considerations 6. Security Considerations
TODO - review and trim as needed.
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 any Implementations need to protect the private key material for any
individuals. There are some cases that need to be highlighted on individuals. There are some cases that need to be highlighted on
this issue. this issue.
* Using the same key for two different algorithms can leak * Using the same key for two different algorithms can leak
skipping to change at page 12, line 30 skipping to change at page 12, line 26
using the same CEK and send it to the first recipient; the first using the same CEK and send it to the first recipient; the first
recipient would, for either static-static ECDH or direct plus KDF, recipient would, for either static-static ECDH or direct plus KDF,
make an assumption that the CEK could be used for proof of origin make an assumption that the CEK could be used for proof of origin
even though it is from the wrong entity. If the key wrap step is even though it is from the wrong entity. If the key wrap step is
added, then no proof of origin is implied and this is not an issue. added, then no proof of origin is implied and this is not an issue.
Although it has been mentioned before, the use of a single key for Although it has been mentioned before, the use of a single key for
multiple algorithms has been demonstrated in some cases to leak multiple algorithms has been demonstrated in some cases to leak
information about that key, provide the opportunity for attackers to information about that key, provide the opportunity for attackers to
forge integrity tags, or gain information about encrypted content. forge integrity tags, or gain information about encrypted content.
Binding a key to a single algorithm prevents these problems. Key Binding a key to a single algorithm prevents these problems.
creators and key consumers are strongly encouraged not only to create
new keys for each different algorithm, but to include that selection Key creators and key consumers are strongly encouraged not only to
of algorithm in any distribution of key material and strictly enforce create new keys for each different algorithm, but to include that
the matching of algorithms in the key structure to algorithms in the selection of algorithm in any distribution of key material and
message structure. In addition to checking that algorithms are strictly enforce the matching of algorithms in the key structure to
correct, the key form needs to be checked as well. Do not use an algorithms in the message structure. In addition to checking that
'EC2' key where an 'OKP' key is expected. algorithms are correct, the key form needs to be 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 of the ones that are highlighted here
are: are:
* What are the permissions associated with the key owner? * What are the permissions associated with the key owner?
skipping to change at page 13, line 12 skipping to change at page 13, line 9
* 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 Analysis of the size of encrypted messages can provide information
encrypted messages based on the length of the message. This about the plaintext messages. This specification does not provide a
specification does not provide for a uniform method of providing uniform method for padding messages prior to encryption. An observer
padding as part of the message structure. An observer can can distinguish between two different messages (for example, 'YES'
distinguish between two different messages (for example, 'YES' and and 'NO') based on the length for all of the content encryption
'NO') based on the length for all of the content encryption algorithms that are defined in [I-D.ietf-cose-rfc8152bis-algs]. This
algorithms that are defined in [I-D.ietf-cose-rfc8152bis-algs] means that it is up to the applications to specify how content
document. This means that it is up to the applications to document padding is to be done to prevent or discourage such analysis. (For
how content padding is to be done in order to prevent or discourage example, the text strings could be defined as 'YES' and 'NO '.)
such analysis. (For example, the text strings could be defined as
'YES' and 'NO '.)
7. Implementation Status 7. Implementation Status
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
skipping to change at page 16, line 23 skipping to change at page 16, line 9
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
August 2007, <https://www.rfc-editor.org/info/rfc4998>. August 2007, <https://www.rfc-editor.org/info/rfc4998>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
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-
01, 13 July 2020, <https://tools.ietf.org/html/draft-ietf- 02, 2 November 2020, <https://tools.ietf.org/html/draft-
core-groupcomm-bis-01>. ietf-core-groupcomm-bis-02>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-13, 4 September 2020, draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
struct-13>. struct-14>.
[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>.
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.
A GitHub project has been created at <https://github.com/cose-wg/ The examples are presented using the CBOR's diagnostic notation. A
Examples> that contains not only the examples presented in this Ruby-based tool exists that can convert between the diagnostic
document, but a more complete set of testing examples as well. Each notation and binary. This tool can be installed with the command
example is found in a JSON file that contains the inputs used to line:
create the example, some of the intermediate values that can be used
in debugging the example and the output of the example presented both
as a hex dump and in CBOR diagnostic notation format. Some of the
examples at the site are designed failure testing cases; 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 updated,
and a note to that effect will be placed in the JSON file.
As noted, the examples are presented using the CBOR's diagnostic
notation. A Ruby-based tool exists that can convert between the
diagnostic notation and binary. This tool can be installed with the
command line:
gem install cbor-diag gem install cbor-diag
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='CBORdiag'. (Depending on the XPath evaluator one is
using, it may be necessary to deal with &gt; as an entity.) using, it may be necessary to deal with &gt; as an entity.)
//sourcecode[@type='CDDL']/text() //sourcecode[@type='CDDL']/text()
A.1. Examples of Signed Messages A.1. Use of Early Code Points
A.1.1. Countersignature This section is to be removed before publishing as an RFC.
The examples in this Appendix use code points proposed for early
allocation by IANA. When IANA makes the allocation, these examples
will be updated as needed.
A.2. Examples of Signed Messages
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 w/ 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.
Size of binary file is 180 bytes Size of binary file is 180 bytes
98( 98(
[ [
/ protected / h'', / protected / h'',
/ unprotected / { / unprotected / {
/ countersign / 7:[ / 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'
] ]
skipping to change at page 18, line 37 skipping to change at page 18, line 37
/ kid / 4:'11' / kid / 4:'11'
}, },
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b 5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a' 98f53afd2fa0f30a'
] ]
] ]
] ]
) )
A.2. Examples of Enveloped Messages A.3. Examples of Signed1 Messages
A.2.1. Countersignature on Encrypted Content A.3.1. Countersignature
This example uses the following:
* Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
* Countersignature Algorithm: ECDSA w/ SHA-512, Curve P-521
Size of binary file is 275 bytes
18(
[
/ protected h'A201260300' / << {
/ alg / 1:-7, / ECDSA 256 /
/ ctyp / 3:0
} >>,
/ unprotected / {
/ kid / 4: "11",
/ countersign / 11: [
/ protected h'A1013823' / << {
/ alg / 1:-36 / ECDSA 512 /
} >>,
/ unprotected / {
/ kid / 4: "bilbo.baggins@hobbiton.example"
},
/ signature / h'01B1291B0E60A79C459A4A9184A0D393E034B34AF069
A1CCA34F5A913AFFFF698002295FA9F8FCBFB6FDFF59132FC0C406E98754A98F1FBF
E81C03095F481856BC470170227206FA5BEE3C0431C56A66824E7AAF692985952E31
271434B2BA2E47A335C658B5E995AEB5D63CF2D0CED367D3E4CC8FFFD53B70D115BA
A9E86961FBD1A5CF'
]
},
/ payload / 'This is the content.',
/ signature / h'BB587D6B15F47BFD54D2CBFCECEF75451E92B08A514BD439
FA3AA65C6AC92DF0D7328C4A47529B32ADD3DD1B4E940071C021E9A8F2641F1D8E3B
053DDD65AE52'
]
)
A.4. Examples of Enveloped Messages
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 w/ 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
Size of 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 / 7:[ / countersign / 11:[
/ protected / h'a1013823' / { / protected h'a1013823' / << {
\ alg \ 1:-36 / 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'
] ]
}, },
skipping to change at page 19, line 48 skipping to change at page 20, line 48
/ y / -3:true / y / -3:true
}, },
/ kid / 4:'meriadoc.brandybuck@buckland.example' / kid / 4:'meriadoc.brandybuck@buckland.example'
}, },
/ ciphertext / h'' / ciphertext / h''
] ]
] ]
] ]
) )
A.3. Examples of Encrypted Messages A.5. Examples of Encrypted Messages
A.5.1. Countersignature on Encrypted Content
A.4. Examples of MACed Messages This example uses the following:
A.5. Examples of MAC0 Messages
* CEK: AES-GCM w/ 128-bit key
* Countersignature algorithm: EdDSA with Curve Ed25519
Size of binary file is 136 bytes
16(
[
/ protected h'A10101' / << {
/ alg / 1:1 / AES-GCM 128 /
} >>,
/ unprotected / {
/ iv / 5: h'02D1F7E6F26C43D4868D87CE',
/ countersign / 11: [
/ protected h'A10127' / << {
/ alg / 1:-8 / EdDSA with Ed25519 /
} >>,
/ unprotected / {
/ kid / 4: '11'
},
/ signature / h'E10439154CC75C7A3A5391491F88651E0292FD0FE0E0
2CF740547EAF6677B4A4040B8ECA16DB592881262F77B14C1A086C02268B17171CA1
6BE4B8595F8C0A08'
]
},
/ ciphertext / h'60973A94BB2898009EE52ECFD9AB1DD25867374B162E2C0
3568B41F57C3CC16F9166250A'
]
)
A.6. Examples of MACed Messages
A.6.1. Countersignature on MAC Content
This example uses the following:
* MAC algorithm: HMAC/SHA-256 with 256-bit key
* Countersignature algorithm: EdDSA with Curve Ed25519
Size of binary file is 159 bytes
97(
[
/ protected h'A10105' / << {
/ alg / 1:5 / HS256 /
} >>,
/ unprotected / {
/ countersign / 11: [
/ protected h'A10127' / << {
/ alg / 1:-8 / EdDSA /
} >>,
/ unprotected / {
/ kid / 4: '11'
},
/ signature / h'602566F4A311DC860740D2DF54D4864555E85BC036EA
5A6CF7905B96E499C5F66B01C4997F6A20C37C37543ADEA1D705347D38A5B13594B2
9583DD741F455101'
]
},
/ payload / 'This is the content.',
/ tag / h'2BDCC89F058216B8A208DDC6D8B54AA91F48BD63484986565105C9
AD5A6682F6',
/ recipients / [
[
/ protected / h'',
/ unprotected / {
/ alg / 1: -6, / direct /
/ kid / 4: 'our-secret'
},
/ ciphertext / h''
]
]
]
)
A.7. Examples of MAC0 Messages
A.7.1. Countersignature on MAC0 Content
This example uses the following:
* MAC algorithm: HMAC/SHA-256 with 256-bit key
* Countersignature algorithm: EdDSA with Curve Ed25519
Size of binary file is 159 bytes
17(
[
/ protected h'A10105' / << {
/ alg / 1:5 / HS256 /
} >>,
/ unprotected / {
/ countersign / 11: [
/ protected h'A10127' / << {
/ alg / 1:-8 / EdDSA /
} >>,
/ unprotected / {
/ kid / 4: '11'
},
/ signature / h'968A315DF6B4F26362E11F4CFD2F2F4E76232F39657B
F1598837FF9332CDDD7581E248116549451F81EF823DA5974F885B681D3D6E38FC41
42D8F8E9E7DC8F0D'
]
},
/ payload / 'This is the content.',
/ tag / h'A1A848D3471F9D61EE49018D244C824772F223AD4F935293F1789F
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 version of the specification was based to some degree on
the outputs of the JOSE and S/MIME working groups. 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
Appendix.
{{{ RFC EDITOR: Please remove Russ Housley as an author of this {{{ RFC EDITOR: Please remove Russ Housley as an author of this
document at publication. Jim Schaad should be listed as the sole document at publication. Jim Schaad should be listed as the sole
author. }}} author. }}}
Authors' Addresses Authors' Addresses
Jim Schaad Jim Schaad
August Cellars August Cellars
Email: ietf@augustcellars.com Email: ietf@augustcellars.com
Russ Housley (editor) Russ Housley (editor)
Vigil Security, LLC Vigil Security, LLC
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 28 change blocks. 
88 lines changed or deleted 241 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/