< 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/