rfc9338.original.xml		rfc9338.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
			<!-- draft submitted in xml v3 -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<!-- RFC EDITOR		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
	Issue has been raised about countersign vs counter sign.		std" consensus="true" docName="draft-ietf-cose-countersign-10" number="9338" ipr
	The dictionaries seem to favor a single word, but when you did RFC 8152 you left		="trust200902" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" ve
	it as a double word.		rsion="3" updates="9052" obsoletes="">
	I have switched to the single word version except for tables 3 and 4 where it ca
	uses the text file to have long lines.
	<?rfc toc="true"?>
	<?rfc symRefs="true"?>
	<?rfc sortRefs="true"?>
	<?rfc comments="true"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-cose-countersign-10" category="std" submissionType="IETF" xml:lang="en" ve
	rsion="3" consensus="true" updates="9052">
	<front>		<front>
	<title abbrev="COSE Countersignatures">		<title abbrev="COSE Countersignatures">
	CBOR Object Signing&nbsp;and&nbsp;Encryption&nbsp;(COSE): Countersignatures< /title>		CBOR Object Signing&nbsp;and&nbsp;Encryption&nbsp;(COSE): Countersignatures< /title>
			<seriesInfo name="RFC" value="9338"/>
			<seriesInfo name="STD" value="96"/>
	<author initials="J." surname="Schaad" fullname="Jim Schaad">		<author initials="J." surname="Schaad" fullname="Jim Schaad">
	<organization>August Cellars</organization>		<organization>August Cellars</organization>
	<address>		<address>
	<postal>		<postal>
	<country>USA</country>		<country>United States of America</country>
	</postal>
	<email>ietf@augustcellars.com</email>
	</address>
	</author>
	<author initials="R." surname="Housley" fullname="Russ Housley" role="editor
	">
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address>
	<postal>
	<country>USA</country>
	</postal>		</postal>
	<email>housley@vigilsec.com</email>		<email></email>
	</address>		</address>
	</author>		</author>
	<date/>		<date year="2022" month="December" />
	<area>Security</area>
	<workgroup>COSE Working Group</workgroup>		<area>sec</area>
			<workgroup>cose</workgroup>
			<keyword>digital signature</keyword>
	<abstract>		<abstract>
	<t>		<t>
	Concise Binary Object Representation (CBOR) is a data format designed fo r small code size and small message size.		Concise Binary Object Representation (CBOR) is a data format designed fo r small code size and small message size.
	CBOR Object Signing and Encryption (COSE) defines a set of security serv ices for CBOR.		CBOR Object Signing and Encryption (COSE) defines a set of security serv ices for CBOR.
	This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE.		This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE.
	This document updates RFC 9052.		This document updates RFC 9052.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	There has been an increased focus on small, constrained devices that mak e up the Internet of Things (IoT).		There has been an increased focus on small, constrained devices that mak e up the Internet of Things (IoT).
	One of the standards that has come out of this process is "Concise Binar y Object Representation (CBOR)" <xref target="RFC8949"/>.		One of the standards that has come out of this process is "<xref target= "RFC8949" format="title"/>" <xref target="RFC8949" format="default"/>.
	CBOR extended the data model of the JavaScript Object Notation (JSON) <x ref target="STD90"/> by allowing for binary data, among other changes.		CBOR extended the data model of the JavaScript Object Notation (JSON) <x ref target="STD90"/> by allowing for binary data, among other changes.
	CBOR has been adopted by several of the IETF working groups dealing with the IoT world as their method of encoding data structures.		CBOR has been adopted by several of the IETF working groups dealing with the IoT world as their method of encoding data structures.
	CBOR was designed specifically to be small in terms of both messages tra nsported and implementation size and to have a schema-free decoder.		CBOR was designed specifically to be small in terms of both messages tra nsported and implementation size and to have a schema-free decoder.
	A need exists to provide message security services for IoT, and using CB OR as the message-encoding format makes sense.		A need exists to provide message security services for IoT, and using CB OR as the message-encoding format makes sense.
	</t>		</t>
	<t>		<t>
	A countersignature is a second signature that confirms the primary signa ture.		A countersignature is a second signature that confirms the primary signa ture.
	During the process of advancing COSE to Internet Standard, it was notice		During the process of advancing CBOR Object Signing and Encryption (COSE
	d that the description of the security properties of countersignatures was incor		) to Internet Standard, it was noticed that the description of the security prop
	rect for the COSE_Sign1 structure in <relref section="4.5" target="RFC8152"/>.		erties of countersignatures was incorrect for the COSE_Sign1 structure mentioned
	To remedy this situation, the working group decided to remove all of the		in <xref section="4.5" target="RFC8152"/>.
	countersignature text from <xref target="RFC9052"/>, which obsoletes <xref targ		To remedy this situation, the COSE Working Group decided to remove all o
	et="RFC8152"/>.		f the countersignature text from <xref target="RFC9052"/>, which obsoletes <xref
			target="RFC8152"/>.
	This document defines a new countersignature with the desired security p roperties.		This document defines a new countersignature with the desired security p roperties.
	</t>		</t>
	<t>		<t>
	The problem with the previous countersignature algorithm was that the cr yptographically computed value was not always included.		The problem with the previous countersignature algorithm was that the cr yptographically computed value was not always included.
	The initial assumption that the cryptographic value was in the third slo t 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 initial assumption that the cryptographic value was in the third slo t of the array was known not to be true at the time, but in the case of the Mess age Authentication Code (MAC) structures this was not deemed to be an issue.
	The new algorithm defined in this document requires the inclusion of mor e values for the countersignature computation.		The new algorithm defined in this document requires the inclusion of mor e values for the countersignature computation.
	The exception to this is the COSE_Signature structure where there is no cryptographic computed value.		The exception to this is the COSE_Signature structure where there is no cryptographically computed value.
	</t>		</t>
	<t>		<t>
	The new algorithm defined in this document is designed to produce the sa me countersignature value in those cases where the computed cryptographic value was already included.		The new algorithm defined in this document is designed to produce the sa me countersignature value in those cases where the computed cryptographic value was already included.
	This means that for those structures the only thing that would need to b e done is to change the value of the header parameter.		This means that for those structures the only thing that would need to b e done is to change the value of the header parameter.
	</t>		</t>
	<t>		<t>
	With the publication of this document, implementers are encouraged to mi grate uses of the previous countersignature algorithm to the one specified in th is document.		With the publication of this document, implementers are encouraged to mi grate uses of the previous countersignature algorithm to the one specified in th is document.
	In particular, uses of "CounterSignature" will migrate to "CounterSignat ureV2", and uses of "CounterSignature0" will migrate to "CounterSignature0V2".		In particular, uses of "CounterSignature" will migrate to "CounterSignat ureV2", and uses of "CounterSignature0" will migrate to "CounterSignature0V2".
	In addition, verification of "CounterSignature" must be supported by new implementations to remain compatible with senders that adhere to <xref target=" RFC8152"/>, which assumes that all implementations will understand "CounterSigna ture" as header parameter label 7.		In addition, verification of "CounterSignature" must be supported by new implementations to remain compatible with senders that adhere to <xref target=" RFC8152"/>, which assumes that all implementations will understand "CounterSigna ture" as header parameter label 7.
	Likewise, verification of "CounterSignature0" may be supported for furth er compatibility.		Likewise, verification of "CounterSignature0" may be supported for furth er compatibility.
	</t>		</t>
	<section anchor="requirements-terminology">		<section anchor="requirements-terminology">
	<name>Requirements Terminology</name>		<name>Requirements Terminology</name>
			<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	<t>		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "S		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	HOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in		"<bcp14>SHOULD NOT</bcp14>",
	this document are to be interpreted as described in BCP&nbsp;14 <xref target="R		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	FC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capit		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	als, as shown here.		are to be interpreted as described in BCP&nbsp;14
	</t>		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	</section>		</section>
	<section anchor="cbor-grammar">		<section anchor="cbor-grammar">
	<name>CBOR Grammar</name>		<name>CBOR Grammar</name>
	<t>		<t>
	CBOR grammar in this document uses the CBOR Data Definition Language ( CDDL) <xref target="RFC8610"/>.		CBOR grammar in this document uses the Concise Data Definition Languag e (CDDL) <xref target="RFC8610"/>.
	</t>		</t>
	<t>		<t>
	The collected CDDL can be extracted from the XML version of this docum ent via the following XPath expression below. (Depending on the XPath evaluator one is using, it may be necessary to deal with &amp;gt; as an entity.)		The collected CDDL can be extracted from the XML version of this docum ent via the XPath expression below. (Depending on the XPath evaluator one is us ing, it may be necessary to deal with &amp;gt; as an entity.)
	</t>		</t>
	<sourcecode type="XPATH"><![CDATA[		<sourcecode type="xpath"><![CDATA[
	//sourcecode[@type='cddl']/text()		//sourcecode[@type='cddl']/text()
	]]></sourcecode>		]]></sourcecode>
	<t>CDDL expects the initial non-terminal symbol to be the first symbol i n the file. For this reason, the first fragment of CDDL is presented here.</t>		<t>CDDL expects the initial non-terminal symbol to be the first symbol i n the file. For this reason, the first fragment of CDDL is presented here.</t>
	<sourcecode type="CDDL"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	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
	]]></sourcecode>		]]></sourcecode>
	<t>The non-terminal Internal_Types is defined for dealing with the autom ated validation tools used during the writing of this document. It references t hose non-terminals that are used for security computations but are not emitted f or transport. </t>		<t>The non-terminal Internal_Types is defined for dealing with the autom ated validation tools used during the writing of this document. It references t hose non-terminals that are used for security computations but are not emitted f or transport. </t>
	</section>		</section>
	<section>		<section>
	<name>Document Terminology</name>		<name>Document Terminology</name>
	<t>		<t>
	In this document, we use the following terminology:		In this document, we use the following terminology.
	</t>		</t>
	<t>		<t>
	"Byte" is a synonym for "octet".		"Byte" is a synonym for "octet".
	</t>		</t>
	<t>		<t>
	Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use in constrained systems. It is defined in <xref target="RFC7252 "/>.		The Constrained Application Protocol (CoAP) is a specialized web trans fer protocol for use in constrained systems. It is defined in <xref target="RFC 7252"/>.
	</t>		</t>
	<t>		<t>
	"Context" is used throughout the document to represent information tha		"Context" is used throughout this document to represent information th
	t is not part of the COSE message.		at is not part of the COSE message.
	Information which is part of the context can come from different sourc		Information that is part of the context can come from different source
	es including: protocol interactions, associated key structures, and application		s, including protocol interactions, associated key structures, and application c
	configuration.		onfiguration.
	The context to use can be implicit, identified using the "kid context"		The context to use can be implicit, identified using either the "kid c
	header parameter defined in <xref target="RFC8613"/>, or identified by a protoc		ontext" header parameter defined in <xref target="RFC8613"/> or a protocol-speci
	ol-specific identifier.		fic identifier.
	Context should generally be included in the cryptographic construction		Context should generally be included in the cryptographic construction
	; for more details see <relref section="4.3" target="RFC9052"/>.		; for more details, see <xref section="4.4" target="RFC9052"/>.
	</t>		</t>
	<t>		<t>
	The term "byte string" is used for sequences of bytes, while the term "text string" is used for sequences of characters.		The term "byte string" is used for sequences of bytes, while the term "text string" is used for sequences of characters.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section>		<section>
	<name>Countersignature Header Parameters</name>		<name>Countersignature Header Parameters</name>
	<t>This section defines a set of common header parameters. A summary of t		<t>This section defines a set of common header parameters. A summary of t
	hese header parameters can be found in <xref target="Header-Table"/>. This tabl		hese header parameters can be found in <xref target="Header-Table"/>. This tabl
	e should be consulted to determine the value of label and the type of the value.		e should be consulted to determine the value of the label and the type of the va
	</t>		lue.</t>
	<t>The set of header parameters defined in this section are:</t>		<t>The set of header parameters defined in this section is:</t>
	<dl newline="false">		<dl newline="false">
	<dt>V2 countersignature:</dt>		<dt>V2 countersignature:</dt>
	<dd>		<dd>
	This header parameter holds one or more countersignature values.		This header parameter holds one or more countersignature values.
	Countersignatures provide a method of having a second party sign some data.		Countersignatures provide a method of having a second party sign some data.
	The countersignature header parameter can occur as an unprotected attr ibute in any of the following structures that are defined in <xref target="RFC90 52"/>: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0.		The countersignature header parameter can occur as an unprotected attr ibute in any of the following structures that are defined in <xref target="RFC90 52"/>: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0.
	Details of version 2 countersignatures are found in <xref target="coun ter_signatureV2"/>.		Details of version 2 countersignatures are found in <xref target="coun ter_signatureV2"/>.
	</dd>		</dd>
	</dl>		</dl>
	skipping to change at line 166 ¶		skipping to change at line 160 ¶
	<dl newline="false">		<dl newline="false">
	<dt>V2 countersignature:</dt>		<dt>V2 countersignature:</dt>
	<dd>		<dd>
	This header parameter holds one or more countersignature values.		This header parameter holds one or more countersignature values.
	Countersignatures provide a method of having a second party sign some data.		Countersignatures provide a method of having a second party sign some data.
	The countersignature header parameter can occur as an unprotected attr ibute in any of the following structures that are defined in <xref target="RFC90 52"/>: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0.		The countersignature header parameter can occur as an unprotected attr ibute in any of the following structures that are defined in <xref target="RFC90 52"/>: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0.
	Details of version 2 countersignatures are found in <xref target="coun ter_signatureV2"/>.		Details of version 2 countersignatures are found in <xref target="coun ter_signatureV2"/>.
	</dd>		</dd>
	</dl>		</dl>
	<table anchor="Header-Table" align="center">		<table anchor="Header-Table" align="center">
	<name>Common Header Parameters</name>		<name>Common Header Parameters</name>
	<thead>		<thead>
	<tr>		<tr>
	<th>Name</th>		<th>Name</th>
	<th>Label</th>		<th>Label</th>
	<th>Value Type</th>		<th>Value Type</th>
	<th>Value Registry</th>
	<th>Description</th>		<th>Description</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>counter signature version 2</td>		<td>Countersignature version 2</td>
	<td>TBD10</td>		<td>11</td>
	<td>COSE_Countersignature / [+ COSE_Countersignature ]</td>		<td>COSE_Countersignature / [+&nbsp;COSE_Countersignature ]</td>
	<td/>		<td>V2 countersignature attribute</td>
	<td>V2 counter signature attribute</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>counter signature 0 version 2</td>		<td>Countersignature0 version 2</td>
	<td>TBD11</td>		<td>12</td>
	<td>COSE_Countersignature0</td>		<td>COSE_Countersignature0</td>
	<td/>		<td>V2 Abbreviated Countersignature</td>
	<td>Abbreviated Counter signature vesion 2</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>		<t>
	The CDDL fragment that represents the set of header parameters defined i n this section is given below.		The CDDL fragment that represents the set of header parameters defined i n this section is given below.
	Each of the header parameters is tagged as optional because they do not need to be in every map; however, the header parameters required in specific map s are discussed above.		Each of the header parameters is tagged as optional because they do not need to be in every map; however, the header parameters required in specific map s are discussed above.
	</t>		</t>
	<sourcecode type="CDDL"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	CountersignatureV2_header = (		CountersignatureV2_header = (
	TBD10 => COSE_Countersignature / [+COSE_Countersignature]		? 11 => COSE_Countersignature / [+ COSE_Countersignature]
	)		)
	Countersignature0V2_header = (		Countersignature0V2_header = (
	TBD11 => COSE_Countersignature0		? 12 => COSE_Countersignature0
	)		)
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="counter_signatureV2">		<section anchor="counter_signatureV2">
	<name>Version 2 Countersignatures</name>		<name>Version 2 Countersignatures</name>
	<t>		<t>
	A countersignature is normally defined as a second signature that confir ms a primary signature.		A countersignature is normally defined as a second signature that confir ms a primary signature.
	A normal example of a countersignature is the signature that a notary pu blic places on a document as witnessing that you have signed the document.		A normal example of a countersignature is the signature that a notary pu blic places on a document as witnessing that you have signed the document.
	A notary typically includes a timestamp to indicate when notarization oc curs; however, such a timestamp has not yet been defined for COSE.		A notary typically includes a timestamp to indicate when notarization oc curs; however, such a timestamp has not yet been defined for COSE.
	A timestamp, once defined in a future document, might be included as a p rotected header parameter.		A timestamp, once defined in a future document, might be included as a p rotected header parameter.
	Thus applying a countersignature to either the COSE_Signature or COSE_Si gn1 objects match this traditional definition.		Thus, applying a countersignature to either the COSE_Signature or COSE_S ign1 objects matches this traditional definition.
	This document extends the context of a countersignature to allow it to b e applied to all of the security structures defined.		This document extends the context of a countersignature to allow it to b e applied to all of the security structures defined.
	The countersignature needs to be treated as a separate operation from th e initial operation even if it is applied by the same user as is done in <xref t arget="I-D.ietf-core-oscore-groupcomm"/>.		The countersignature needs to be treated as a separate operation from th e initial operation even if it is applied by the same user, as is done in <xref target="GROUP-OSCORE"/>.
	</t>		</t>
	<t>		<t>
	COSE supports two different forms for countersignatures.		COSE supports two different forms for countersignatures.
	Full countersignatures use the structure COSE_Countersignature, which ha s the same structure as COSE_Signature.		Full countersignatures use the structure COSE_Countersignature, which ha s the same structure as COSE_Signature.
	Thus, full countersignatures can have protected and unprotected attribut es, including chained countersignatures.		Thus, full countersignatures can have protected and unprotected attribut es, including chained countersignatures.
	Abbreviated countersignatures use the structure COSE_Countersignature0.		Abbreviated countersignatures use the structure COSE_Countersignature0.
	This structure only contains the signature value and nothing else.		This structure only contains the signature value and nothing else.
	The structures cannot be converted between each other; as the signature computation includes a parameter identifying which structure is being used, the converted structure will fail signature validation.		The structures cannot be converted between each other; as the signature computation includes a parameter identifying which structure is being used, the converted structure will fail signature validation.
	</t>		</t>
	<t>		<t>
	The version 2 countersignature changes the algorithm used for computing the signature from the original version that is specified <relref section="4.5" target="RFC8152"/>.		The version 2 countersignature changes the algorithm used for computing the signature from the original version that is specified in <xref section="4.5" target="RFC8152"/>.
	The new version now includes the cryptographic material generated for al l of the structures rather than just for a subset.		The new version now includes the cryptographic material generated for al l of the structures rather than just for a subset.
	</t>		</t>
	<t>		<t>
	COSE was designed for uniformity in how the data structures are specifie d.		COSE was designed for uniformity in how the data structures are specifie d.
	One result of this is that for COSE one can expand the concept of counte rsignatures beyond just the idea of signing a signature to being able to sign mo st of the structures without having to create a new signing layer.		One result of this is that for COSE one can expand the concept of counte rsignatures beyond just the idea of signing a signature to being able to sign mo st of the structures without having to create a new signing layer.
	When creating a countersignature, one needs to be clear about the securi ty properties that result.		When creating a countersignature, one needs to be clear about the securi ty properties that result.
	When done on a COSE_Signature or COSE_Sign1, the normal countersignature semantics are preserved.		When done on a COSE_Signature or COSE_Sign1, the normal countersignature semantics are preserved.
	That is, the countersignature makes 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 exists.		That is, the countersignature makes 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 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_Mac or COSE_Mac0, the payload is included as well as the MAC value.
	When done on a COSE_Encrypt or COSE_Encrypt0, the existence of the encry pted data is attested to.		When done on a COSE_Encrypt or COSE_Encrypt0, the existence of the encry pted data is attested to.
	It should be noted that there is a distinction between attesting to the encrypted data as opposed to attesting to the unencrypted data.		It should be noted that there is a distinction between attesting to 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 to the data and then encrypt that.		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 construct cases where the use of two different keys will appear to result in a successful decryption (the tag check success), b ut which produce two completely different plaintexts.		It is always possible to construct cases where the use of two different keys results in successful decryption, where the tag check succeeds, but two com pletely different plaintexts are produced.
	This situation is not detectable by a countersignature on the encrypted data.		This situation is not detectable by a countersignature on the encrypted data.
	</t>		</t>
	<section anchor="Full_Countersig">		<section anchor="Full_Countersig">
	<name>Full Countersignatures</name>		<name>Full Countersignatures</name>
	<t>		<t>
	The COSE_Countersignature structure allows for the same set of capabil ities as a COSE_Signature.		The COSE_Countersignature structure allows for the same set of capabil ities as a COSE_Signature.
	This means that all of the capabilities of a signature are duplicated with this structure.		This means that all of the capabilities of a signature are duplicated with this structure.
	Specifically, the countersigner does not need to be related to the pro ducer of what is being countersigned as key and algorithm identification can be placed in the countersignature attributes.		Specifically, the countersigner does not need to be related to the pro ducer of what is being countersigned, as key and algorithm identification can be placed in the countersignature attributes.
	This also means that the countersignature can itself be countersigned.		This also means that the countersignature can itself be countersigned.
	This is a feature required by protocols such as long-term archiving se rvices.		This is a feature required by protocols such as long-term archiving se rvices.
	More information on how countersignatures are used can be found in the evidence record syntax described in <xref target="RFC4998"/>.		More information on how countersignatures are used can be found in the evidence record syntax described in <xref target="RFC4998"/>.
	</t>		</t>
	<t>		<t>
	The full countersignature structure can be encoded as either tagged or		The full countersignature structure can be encoded as either tagged or
	untagged depending on the context.		untagged, depending on the context.
	A tagged COSE_Countersignature structure is identified by the CBOR tag		A tagged COSE_Countersignature structure is identified by the CBOR tag
	TBD0.		19.
	The countersignature structure is the same as that used for a signer o n a signed object.		The countersignature structure is the same as that used for a signer o n a signed object.
	The CDDL fragment for full countersignatures is:		The CDDL fragment for full countersignatures is:
	</t>		</t>
	<sourcecode type="CDDL"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	COSE_Countersignature_Tagged = #6.TBD0(COSE_Countersignature)		COSE_Countersignature_Tagged = #6.19(COSE_Countersignature)
	COSE_Countersignature = COSE_Signature		COSE_Countersignature = COSE_Signature
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The details of the fields of a countersignature can be found in <relre f section="4.1" target="RFC9052"/>.		The details of the fields of a countersignature can be found in <xref section="4.1" target="RFC9052"/>.
	</t>		</t>
	<t>		<t>
	An example of a countersignature on a signature can be found in <xref target="Appendix_A_1_1"/>.		An example of a countersignature on a signature can be found in <xref target="Appendix_A_1_1"/>.
	An example of a countersignature in an encryption object can be found in <xref target="Appendix_A_2_1"/>.		An example of a countersignature in an encryption object can be found in <xref target="Appendix_A_2_1"/>.
	</t>		</t>
	<t>		<t>
	It should be noted that only a signature algorithm with appendix (see <relref section="8.1" target="RFC9052"/>) can be used for countersignatures.		It should be noted that only a signature algorithm with appendix (see <xref section="8.1" target="RFC9052"/>) can be used for countersignatures.
	This is because the body should be able to be processed without having to evaluate the countersignature, and this is not possible for signature scheme s with message recovery.		This is because the body should be able to be processed without having to evaluate the countersignature, and this is not possible for signature scheme s with message recovery.
	</t>		</t>
	</section>		</section>
	<section anchor="Abbrev_Countersig">		<section anchor="Abbrev_Countersig">
	<name>Abbreviated Countersignatures</name>		<name>Abbreviated Countersignatures</name>
	<t>		<t>
	Abbreviated countersignatures support encrypted group messaging, where identification of the message originator is required, but there is a desire to keep the countersignature as small as possible.		Abbreviated countersignatures support encrypted group messaging where identification of the message originator is required but there is a desire to ke ep the countersignature as small as possible.
	For abbreviated countersignatures, there is no provision for any prote cted attributes related to the signing operation.		For abbreviated countersignatures, there is no provision for any prote cted attributes related to the signing operation.
	That is, the parameters for computing or verifying the abbreviated cou ntersignature are provided by the same context used to describe the encryption, signature, or MAC processing.		That is, the parameters for computing or verifying the abbreviated cou ntersignature are provided by the same context used to describe the encryption, signature, or MAC processing.
	</t>		</t>
	<t>		<t>
	The CDDL fragment for the abbreviated countersignatures is:		The CDDL fragment for the abbreviated countersignatures is:
	</t>		</t>
	<sourcecode type="CDDL"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	COSE_Countersignature0 = bstr		COSE_Countersignature0 = bstr
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The byte string representing the signature value is placed in the Coun tersignature0 attribute.		The byte string representing the signature value is placed in the Coun tersignature0 attribute.
	This attribute is then encoded as an unprotected header parameter.		This attribute is then encoded as an unprotected header parameter.
	</t>		</t>
	</section>		</section>
	<section anchor="CountersignV2_verify">		<section anchor="CountersignV2_verify">
	<name>Signing and Verification Process</name>		<name>Signing and Verification Process</name>
	<t>		<t>
	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.		The Countersign_structure is used to create the canonical form.
	This signing and verification process takes in the countersignature ta rget structure (COSE_Signature, COSE_Sign1, COSE_Sign, COSE_Mac, COSE_Mac0, COSE _Encrypt, or COSE_Encrypt0), the signer information (COSE_Signature), and the ap plication data (external source).		This signing and verification process takes in the countersignature ta rget structure (COSE_Signature, COSE_Sign1, COSE_Sign, COSE_Mac, COSE_Mac0, COSE _Encrypt, or COSE_Encrypt0), the signer information (COSE_Signature), and the ap plication data (external source).
	A Countersign_structure is a CBOR array.		A Countersign_structure is a CBOR array.
	The target structure of the countersignature needs to have all of its		The target structure of the countersignature needs to have all of its
	cryptographic functions finalized before the computing the signature.		cryptographic functions finalized before computing the signature.
	The fields of the Countersign_structure in order are:		The fields of the Countersign_structure, in order, are:
	</t>		</t>
	<dl>		<dl>
	<dt>context:</dt>		<dt>context:</dt>
	<dd>		<dd><t>
	A context text string identifying the context of the signature. The		A context text string identifying the context of the signature. The
	context text string is one of the following:		context text string is one of the following:</t>
	</dd>		<ul>
	</dl>		<li>"CounterSignature" for countersignatures using the COSE_Countersi
			gnature structure when other_fields is absent.</li>
	<ul empty="true">		<li>"CounterSignature0" for countersignatures using the COSE_Counters
	<li>		ignature0 structure when other_fields is absent.</li>
	"CounterSignature" for countersignatures using the COSE_Counters		<li>"CounterSignatureV2" for countersignatures using the COSE_Counter
	ignature structure when other_fields is absent.		signature structure when other_fields is present.</li>
	</li>		<li>"CounterSignature0V2" for countersignatures using the COSE_Counte
	<li>		rsignature0 structure when other_fields is present.</li>
	"CounterSignature0" for countersignatures using the COSE_Counter		</ul>
	signature0 structure when other_fields is absent.		</dd>
	</li>
	<li>
	"CounterSignatureV2" for countersignatures using the COSE_Counte
	rsignature structure when other_fields is present.
	</li>
	<li>
	"CounterSignature0V2" for countersignatures using the COSE_Count
	ersignature0 structure when other_fields is present.
	</li>
	</ul>
	<dl>
	<dt>body_protected:</dt>		<dt>body_protected:</dt>
	<dd>		<dd>
	The serialized protected attributes from the target structure encode d in a bstr type.		The serialized protected attributes from the target structure, encod ed in a bstr type.
	If there are no protected attributes, a zero-length byte string is u sed.		If there are no protected attributes, a zero-length byte string is u sed.
	</dd>		</dd>
	<dt>sign_protected:</dt>		<dt>sign_protected:</dt>
	<dd>		<dd>
	The serialized protected attributes from the signer structure encode d in a bstr type.		The serialized protected attributes from the signer structure, encod ed in a bstr type.
	If there are no protected attributes, a zero-length byte string is u sed.		If there are no protected attributes, a zero-length byte string is u sed.
	This field is omitted for the Countersignature0V2 attribute.		This field is omitted for the Countersignature0V2 attribute.
	</dd>		</dd>
	<dt>external_aad:</dt>		<dt>external_aad:</dt>
	<dd>		<dd>
	The externally supplied additional authenticated data (AAD) from the application is encoded in a bstr type.		The externally supplied additional authenticated data (AAD) from the application, encoded in a bstr type.
	If this field is not supplied, it defaults to a zero-length byte str ing.		If this field is not supplied, it defaults to a zero-length byte str ing.
	(See <relref section="4.3" target="RFC9052"/> for application guidan ce on constructing this field.)		(See <xref section="4.4" target="RFC9052"/> for application guidance on constructing this field.)
	</dd>		</dd>
	<dt>payload:</dt>		<dt>payload:</dt>
	<dd>		<dd>
	The payload to be signed encoded in a bstr type.		The payload to be signed, encoded in a bstr type.
	The payload is placed here independent of how it is transported.		The payload is placed here independently of how it is transported.
	</dd>		</dd>
	<dt>other_fields:</dt>		<dt>other_fields:</dt>
	<dd>		<dd>
	If there are only two bstr fields in the target structure, this fiel		Omitted if there are only two bstr fields in the target structure.
	d is omitted.		This field is an array of all bstr fields after the second.
	The field is an array of all bstr fields after the second.
	As an example, this would be an array of one element for the COSE_Si gn1 structure containing the signature value.		As an example, this would be an array of one element for the COSE_Si gn1 structure containing the signature value.
	</dd>		</dd>
	</dl>		</dl>
	<t>The CDDL fragment that describes the above text is: </t>		<t>The CDDL fragment that describes the above text is: </t>
	<sourcecode type="CDDL"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	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 ]
	]		]
	]]></sourcecode>		]]></sourcecode>
	<t>How to compute a countersignature:		<t>How to compute a countersignature:
	</t>		</t>
	<ol type="1">		<ol type="1">
	<li>Create a Countersign_structure and populate it with the appropriat e fields. </li>		<li>Create a Countersign_structure and populate it with the appropriat e fields. </li>
	<li>Create the value ToBeSigned by encoding the Countersign_structure to a byte string, using the encoding described in <xref target="CBOR-Canonical"/ >. </li>		<li>Create the value ToBeSigned by encoding the Countersign_structure to a byte string, using the encoding described in <xref target="CBOR-Canonical"/ >. </li>
	<li>Call the signature creation algorithm passing in K (the key to sig n with), alg (the algorithm to sign with), and ToBeSigned (the value to sign). </li>		<li>Call the signature creation algorithm passing in K (the key to sig n with), alg (the algorithm to sign with), and ToBeSigned (the value to sign). </li>
	<li>		<li>
	Place the resulting signature value in the correct location.		Place the resulting signature value in the correct location.
	This is the "signature" field of the COSE_Countersignature structure for full countersignatures (see <xref target="Full_Countersig"/>).		This is the "signature" field of the COSE_Countersignature structure for full countersignatures (see <xref target="Full_Countersig"/>).
	This is the value of the Countersignature0 attribute for abbreviated countersignatures (see <xref target="Abbrev_Countersig"/>).		This is the value of the Countersignature0 attribute for abbreviated countersignatures (see <xref target="Abbrev_Countersig"/>).
	</li>		</li>
	</ol>		</ol>
	<t>The steps for verifying a countersignature are:		<t>The steps for verifying a countersignature:
	</t>		</t>
	<ol type="1">		<ol type="1">
	<li>Create a Countersign_structure and populate it with the appropriat e fields. </li>		<li>Create a Countersign_structure and populate it with the appropriat e fields. </li>
	<li>Create the value ToBeSigned by encoding the Countersign_structure to a byte string, using the encoding described in <xref target="CBOR-Canonical"/ >. </li>		<li>Create the value ToBeSigned by encoding the Countersign_structure to a byte string, using the encoding described in <xref target="CBOR-Canonical"/ >. </li>
	<li>Call the signature verification algorithm passing in K (the key to verify with), alg (the algorithm used sign with), ToBeSigned (the value to sign ), and sig (the signature to be verified). </li>		<li>Call the signature verification algorithm passing in K (the key to verify with), alg (the algorithm used to sign with), ToBeSigned (the value to s ign), and sig (the signature to be verified). </li>
	</ol>		</ol>
	<t>		<t>
	In addition to performing the signature verification, the application performs the appropriate checks to ensure that the key is correctly paired with the signing identity and that the signing identity is authorized before performi ng actions.		In addition to performing the signature verification, the application performs the appropriate checks to ensure that the key is correctly paired with the signing identity and that the signing identity is authorized before performi ng actions.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="CBOR-Canonical">		<section anchor="CBOR-Canonical">
	<name>CBOR Encoding Restrictions</name>		<name>CBOR Encoding Restrictions</name>
	<t>		<t>
	The deterministic encoding rules are defined in <relref section="4.2" ta		The deterministic encoding rules are defined in <xref section="4.2" targ
	rget="RFC8949"/>.		et="RFC8949"/>.
	These rules are further narrowed in <relref section="9" target="RFC9052"		These rules are further narrowed in <xref section="9" target="RFC9052"/>
	/>.		.
	The narrowed deterministic encoding rules MUST be used to ensure that al		The narrowed deterministic encoding rules <bcp14>MUST</bcp14> be used to
	l implementations generate the same byte string for the "to be signed" value.		ensure that all implementations generate the same byte string for the "to be si
			gned" value.
	</t>		</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	The registries and registrations listed below were created during proces		The registries and registrations listed below were created during the pr
	sing of <xref target="RFC8152"/>.		ocessing of <xref target="RFC8152"/>.
	The majority of the actions are to update the references to point to thi s document.		The majority of the actions are to update the references to point to thi s document.
	</t>		</t>
	<section anchor="cbor-tag-assignment">		<section anchor="cbor-tag-assignment">
	<name>CBOR Tag Assignment</name>		<name>CBOR Tags Registry</name>
			<t>IANA created a registry titled "CBOR Tags" registry as part of
			processing RFC 7049, which was subsequently replaced by
			<xref target="RFC8949"/>.</t>
	<t>		<t>
	IANA is requested to assign a new tag for the CounterSignature type i n the "CBOR Tags" registry.		IANA has assigned a new tag for the CounterSignature type in the "CBOR Tags" registry.
	</t>		</t>
	<ul>		<dl newline="false" spacing="compact">
	<li>Tag: TBD0</li>		<dt>Tag:</dt><dd>19</dd>
	<li>Data Item: COSE_Countersignature</li>		<dt>Data Item:</dt><dd> COSE_Countersignature</dd>
	<li>Semantics: COSE standalone V2 countersignature </li>		<dt>Semantics:</dt><dd>COSE standalone V2 countersignature</dd>
	<li>Reference: [[this document]]</li>		<dt>Reference:</dt><dd>RFC 9338</dd>
	</ul>		</dl>
	</section>		</section>
	<section anchor="cose-header-key-table">		<section anchor="cose-header-key-table">
	<name>COSE Header Parameters Registry</name>		<name>COSE Header Parameters Registry</name>
	<t>		<t>
	IANA created a registry titled "COSE Header Parameters" as part of pro cessing <xref target="RFC8152"/>.		IANA created a registry titled "COSE Header Parameters" as part of pro cessing <xref target="RFC8152"/>.
	</t>		</t>
	<t>		<t>
	IANA is requested to register the following new items in the registry.		IANA has registered the Countersignature version 2 (label 11) and
	For these entries, the Value Registry column will be blank and the Reference co		Countersignature0 version 2 (label 12) in the "COSE Header
	lumn 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".
	</t>		</t>
	<table>		<table>
	<name>New Common Header Parameters</name>		<name>New Common Header Parameters</name>
	<thead>		<thead>
	<tr>		<tr>
	<th>Name</th>		<th>Name</th>
	<th>Label</th>		<th>Label</th>
	<th>Value Type</th>		<th>Value Type</th>
	<th>Description</th>		<th>Description</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>Countersignature version 2</td>		<td>Countersignature version 2</td>
	<td>TBD10</td>		<td>11</td>
	<td>COSE_Countersignature / [+ COSE_Countersignature ]</td>		<td>COSE_Countersignature / [+&nbsp;COSE_Countersignature ]</td>
	<td>V2 countersignature attribute</td>		<td>V2 countersignature attribute</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>Countersignature0 version 2</td>		<td>Countersignature0 version 2</td>
	<td>TBD11</td>		<td>12</td>
	<td>COSE_Countersignature0</td>		<td>COSE_Countersignature0</td>
	<td>V2 Abbreviated Countersignature</td>		<td>V2 Abbreviated Countersignature</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>		<t>
	IANA is requested to modify the Description field for "counter signatu		IANA has modified the existing "Description" field for "counter signat
	re" and "CounterSignature0" to include the words "(Deprecated by [[This Document		ure" (7)
	]])".		and "CounterSignature0" (9) to include the words "(Deprecated by
			RFC 9338)".
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="security-considerations">		<section anchor="security-considerations">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	Please review the Security Consideration in <xref target="RFC9052"/>; th ese considerations apply to this document as well, especially the need for imple mentations to protect private key material.		Please review the Security Considerations section in <xref target="RFC90 52"/>; these considerations apply to this document as well, especially the need for implementations to protect private key material.
	</t>		</t>
	<t>		<t>
	When either COSE_Encrypt and COSE_Mac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore , the contents could originate from any one of the parties that share the key.		When either COSE_Encrypt or COSE_Mac is used and more than two parties s hare the key, data origin authentication is not provided. Any party that knows t he message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key.
	</t>		</t>
	<t>		<t>
	Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign.		Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign.
	To provide 128-bit security against collision attacks, the tag length MU ST be at least 256-bits.		To provide 128-bit security against collision attacks, the tag length <b cp14>MUST</bcp14> be at least 256 bits.
	A countersignature of a COSE_Mac with AES-MAC (using a 128-bit key or la rger) provides at most 64 bits of integrity protection.		A countersignature of a COSE_Mac with AES-MAC (using a 128-bit key or la rger) provides at most 64 bits of integrity protection.
	Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 p rovides at most 32 bits of integrity protection.		Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 p rovides at most 32 bits of integrity protection.
	</t>		</t>
	</section>		</section>
	<section removeInRFC="true">
	<name>Implementation Status</name>
	<!-- RFC Editor - Please remove this section and reference RFC7942 prior
	to publication -->
	<t>
	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 <xref targe
	t="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.
	</t>
	<t>
	According to <xref target="RFC7942"/>, "this will allow reviewers and wo
	rking
	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".
	</t>
	<section>
	<name>Author's Versions</name>
	<t>
	There are three different implementations that have been created by th
	e author of the document both to create the examples that are included in the do
	cument and to validate the structures and methodology used in the design of COSE
	.
	</t>
	<ul>
	<li>Implementation Location: https://github.com/cose-wg</li>
	<li>Primary Maintainer: Jim Schaad</li>
	<li>
	Languages:
	There are two different languages that are currently supported: J
	ava and C#.
	</li>
	<li>
	Cryptography: The Java and C# libraries use Bouncy Castle to provi
	de the required cryptography.
	</li>
	<li>
	Coverage:
	Both implementations can produce and consume both the old and new co
	untersignatures.
	</li>
	<li>
	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 me
	ssages 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 <bcp14>MUST</bcp14> statements in the document have
	been implemented as part of the libraries.
	One such statement is the requirement that unique labels be presen
	t.
	</li>
	<li>Licensing: Revised BSD License </li>
	</ul>
	</section>
	<section>
	<name>COSE Testing Library</name>
	<ul>
	<li>Implementation Location: https://github.com/cose-wg/Examples</li>
	<li>Primary Maintainer: Jim Schaad</li>
	<li>
	Description: A set of tests for the COSE library is provided as pa
	rt 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.
	</li>
	<li>
	Coverage: An attempt has been made to have test cases for every m
	essage type and algorithm in the document.
	However, examples dealing with countersignatures, and ECDH with Cu
	rve25519 and Goldilocks are missing.
	</li>
	<li>Licensing: Public Domain</li>
	</ul>
	</section>
	</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.2119.xml"/>		FC.2119.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.8174.xml"/>		FC.8174.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.9052.xml"/>		FC.9052.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.8610.xml"/>		FC.8610.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.8152.xml"/>		FC.8152.xml"/>
	<referencegroup anchor="STD90" target="https://www.rfc-editor.org/info/s td90">		<referencegroup anchor="STD90" target="https://www.rfc-editor.org/info/s td90">
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref erence.RFC.8295.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference .RFC.8259.xml"/>
	</referencegroup>		</referencegroup>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.8949.xml"/>		FC.8949.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.7252.xml"/>		FC.7252.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	ence.RFC.7942.xml"/>		FC.4998.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	ence.RFC.4998.xml"/>		<!-- draft-ietf-core-oscore-groupcomm (Waiting for writeup)
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe		"Long way", to fix John Preuss Mattsson's initial (shouldn't include "P") -->
	rence.I-D.ietf-core-oscore-groupcomm.xml"/>		<reference anchor="GROUP-OSCORE">
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<front>
	ence.RFC.8613.xml"/>		<title>Group OSCORE - Secure Group Communication for CoAP</title>
			<author initials="M" surname="Tiloca" fullname="Marco Tiloca">
			<organization>RISE AB</organization>
			</author>
			<author initials="G" surname="Selander" fullname="Göran Selander">
			<organization>Ericsson AB</organization>
			</author>
			<author initials="F" surname="Palombini" fullname="Francesca Palombini">
			<organization>Ericsson AB</organization>
			</author>
			<author initials="J" surname="Mattsson" fullname="John Preuss Mattsson">
			<organization>Ericsson AB</organization>
			</author>
			<author initials="J" surname="Park" fullname="Jiye Park">
			<organization>Universitaet Duisburg-Essen</organization>
			</author>
			<date day="24" month="October" year="2022"/>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-16"/
			>
			</reference>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8613.xml"/>
	<reference anchor="CBORDIAG" target="https://github.com/cabo/cbor-diag">		<reference anchor="CBORDIAG" target="https://github.com/cabo/cbor-diag">
	<front>		<front>
	<title>CBOR diagnostic utilities</title>		<title>CBOR diagnostic utilities</title>
	<author fullname="C. Bormann" initials="C." surname="Bormann"/>		<author fullname="C. Bormann" initials="C." surname="Bormann"/>
			<date month="September" year="2022"/>
	</front>		</front>
			<refcontent> commit 1952a04</refcontent>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="examples">		<section anchor="examples">
	<name>Examples</name>		<name>Examples</name>
	<t>This appendix includes a set of examples that show the different featur es and message types that have been defined in this document. To make the examp les easier to read, they are presented using the extended CBOR diagnostic notati on (defined in <xref target="RFC8610"/>) rather than as a binary dump.		<t>This appendix includes a set of examples that show the different featur es and message types that have been defined in this document. To make the examp les easier to read, they are presented using the extended CBOR diagnostic notati on (defined in <xref target="RFC8610"/>) rather than as a binary dump.
	</t>		</t>
	<t>The examples are presented using the CBOR's diagnostic notation. A Rub y-based tool exists <xref target="CBORDIAG"/> that can convert between the diagn ostic notation and binary. The referenced webpage includes installation instruc tions.		<t>The examples are presented using the CBOR diagnostic notation. A Ruby- based tool exists <xref target="CBORDIAG"/> that can convert between the diagnos tic notation and binary. The referenced webpage includes installation instructi ons.
	</t>		</t>
	<t>The diagnostic notation can be converted into binary files using the fo llowing command line:		<t>The diagnostic notation can be converted into binary files using the fo llowing command line:
	</t>		</t>
	<sourcecode type=""><![CDATA[diag2cbor.rb < inputfile > outputfile		<sourcecode type=""><![CDATA[diag2cbor.rb < inputfile > outputfile
	]]></sourcecode>		]]></sourcecode>
	<t>The examples can be extracted from the XML version of this document via		<t>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 attribute type=		an XPath expression, as all of the sourcecode is tagged with the attribute 'typ
	"CBORdiag". (Depending on the XPath evaluator one is using, it may be necessary		e="cbor-diag"'. (Depending on the XPath evaluator one is using, it may be neces
	to deal with &amp;gt; as an entity.)		sary to deal with &amp;gt; as an entity.)</t>
	</t>
	<sourcecode type="XPATH"><![CDATA[//sourcecode[@type='CDDL']/text()]]></so		<sourcecode type="xpath"><![CDATA[//sourcecode[@type='cbor-diag']/text()
	urcecode>		]]></sourcecode>
	<section removeInRFC="true">
	<name>Use of Early Code Points</name>		<t>This appendix uses the following terms:</t>
	<!-- RFC Editor - Please remove this section prior to publication -->
	<t>The examples in this Appendix use code points proposed for early alloc		<dl newline="false">
	ation by IANA. When IANA makes the allocation, these examples will be updated a		<dt>AES-GCM:</dt><dd>AES Galois/Counter Mode</dd>
	s needed.</t>		<dt>CEK:</dt><dd>content-encryption key</dd>
	</section>		<dt>ECDH:</dt><dd>Elliptic Curve Diffie-Hellman</dd>
			<dt>ECDH-ES:</dt><dd>Elliptic Curve Diffie-Hellman Ephemeral Static</dd>
			<dt>ECDSA:</dt><dd>Elliptic Curve Digital Signature Algorithm</dd>
			<dt>EdDSA:</dt><dd>Edwards-curve Digital Signature Algorithm</dd>
			<dt>HKDF:</dt><dd>HMAC-based Key Derivation Function</dd>
			<dt>HMAC:</dt><dd>Hashed Message Authentication Code</dd>
			</dl>
	<section anchor="SignedExamples">		<section anchor="SignedExamples">
	<name>Examples of Signed Messages</name>		<name>Examples of Signed Messages</name>
	<section anchor="Appendix_A_1_1">		<section anchor="Appendix_A_1_1">
	<name>Countersignature</name>		<name>Countersignature</name>
	<t>This example uses the following:		<t>This example uses the following:
	</t>		</t>
	<ul>		<dl newline="false">
	<li>Signature Algorithm: ECDSA w/ SHA-256, Curve P-256</li>		<dt>Signature Algorithm:</dt><dd>ECDSA with SHA-256, Curve P-256</
	<li>The same header parameters are used for both the signature and		dd>
	the countersignature.</li>		</dl>
	</ul>		<t>The same header parameters are used for both the signature and the
	<t>Size of binary file is 180 bytes</t>		countersignature.</t>
	<sourcecode type="CBORdiag"><![CDATA[		<t>The size of the binary file is 180 bytes.</t>
			<sourcecode type="cbor-diag"><![CDATA[
	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'
	]		]
	]		]
	]		]
	)		)
	]]>		]]>
	</sourcecode>		</sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="Signed1Examples">		<section anchor="Signed1Examples">
	<name>Examples of Signed1 Messages</name>		<name>Examples of Signed1 Messages</name>
	<section anchor="Appendix_B_2_3">		<section anchor="Appendix_B_2_3">
	<name>Countersignature</name>		<name>Countersignature</name>
	<t>This example uses the following:		<t>This example uses the following:
	</t>		</t>
	<ul>		<dl newline="false">
	<li>Signature Algorithm: ECDSA w/ SHA-256, Curve P-256</li>		<dt>Signature Algorithm:</dt><dd>ECDSA with SHA-256, Curve P-256</
	<li>Countersignature Algorithm: ECDSA w/ SHA-512, Curve P-521</li>		dd>
	</ul>		<dt>Countersignature Algorithm:</dt><dd>ECDSA with SHA-512, Curve
	<t>Size of binary file is 275 bytes</t>		P-521</dd>
	<sourcecode type="CBORdiag"><![CDATA[		</dl>
			<t>The size of the binary file is 275 bytes.</t>
			<sourcecode type="cbor-diag"><![CDATA[
	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
	skipping to change at line 731 ¶		skipping to change at line 681 ¶
	)		)
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="EnvelopedExamples">		<section anchor="EnvelopedExamples">
	<name>Examples of Enveloped Messages</name>		<name>Examples of Enveloped Messages</name>
	<section anchor="Appendix_A_2_1">		<section anchor="Appendix_A_2_1">
	<name>Countersignature on Encrypted Content</name>		<name>Countersignature on Encrypted Content</name>
	<t>This example uses the following:		<t>This example uses the following:
	</t>		</t>
	<ul>		<dl newline="false">
	<li>CEK: AES-GCM w/ 128-bit key</li>		<dt>CEK:</dt><dd>AES-GCM with 128-bit key</dd>
	<li>Recipient class: ECDH Ephemeral-Static, Curve P-256</li>		<dt>Recipient Class:</dt><dd>ECDH Ephemeral-Static, Curve P-256</d
	<li>Countersignature Algorithm: ECDSA w/ SHA-512, Curve P-521</li>		d>
	</ul>		<dt>Countersignature Algorithm:</dt><dd>ECDSA with SHA-512, Curve
	<t>Size of binary file is 326 bytes</t>		P-521</dd>
	<sourcecode type="CBORdiag"><![CDATA[		</dl>
			<t>The size of the binary file is 326 bytes.</t>
			<sourcecode type="cbor-diag"><![CDATA[
	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''
	]		]
	]		]
	]		]
	)		)
	]]>		]]>
	</sourcecode>		</sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="EncryptExamples">		<section anchor="EncryptExamples">
	<name>Examples of Encrypted Messages</name>		<name>Examples of Encrypted Messages</name>
	<section anchor="Appendix_B_4_3">		<section anchor="Appendix_B_4_3">
	<name>Countersignature on Encrypted Content</name>		<name>Countersignature on Encrypted Content</name>
	<t>This example uses the following:		<t>This example uses the following:
	</t>		</t>
	<ul>		<dl newline="false">
	<li>CEK: AES-GCM w/ 128-bit key</li>		<dt>CEK:</dt><dd>AES-GCM with 128-bit key</dd>
	<li>Countersignature algorithm: EdDSA with Curve Ed25519</li>		<dt>Countersignature Algorithm:</dt><dd>EdDSA with Curve Ed25519</
	</ul>		dd>
	<t>Size of binary file is 136 bytes</t>		</dl>
	<sourcecode type="CBORdiag"><![CDATA[		<t>The size of the binary file is 136 bytes.</t>
			<sourcecode type="cbor-diag"><![CDATA[
	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' / << {
	/ alg / 1:-8 / EdDSA with Ed25519 /		/ alg / 1:-8 / EdDSA with Ed25519 /
	skipping to change at line 829 ¶		skipping to change at line 779 ¶
	)		)
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="MacExamples">		<section anchor="MacExamples">
	<name>Examples of MACed Messages</name>		<name>Examples of MACed Messages</name>
	<section anchor="Appendix_B_5_3">		<section anchor="Appendix_B_5_3">
	<name>Countersignature on MAC Content</name>		<name>Countersignature on MAC Content</name>
	<t>This example uses the following:		<t>This example uses the following:
	</t>		</t>
	<ul>		<dl newline="false">
	<li>MAC algorithm: HMAC/SHA-256 with 256-bit key</li>		<dt>MAC Algorithm:</dt><dd>HMAC/SHA-256 with 256-bit key</dd>
	<li>Countersignature algorithm: EdDSA with Curve Ed25519</li>		<dt>Countersignature Algorithm:</dt><dd>EdDSA with Curve Ed25519</
	</ul>		dd>
	<t>Size of binary file is 159 bytes</t>		</dl>
	<sourcecode type="CBORdiag"><![CDATA[		<t>The size of the binary file is 159 bytes.</t>
			<sourcecode type="cbor-diag"><![CDATA[
	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 line 877 ¶		skipping to change at line 827 ¶
	)		)
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="Mac0Examples">		<section anchor="Mac0Examples">
	<name>Examples of MAC0 Messages</name>		<name>Examples of MAC0 Messages</name>
	<section anchor="Appendix_B_6_3">		<section anchor="Appendix_B_6_3">
	<name>Countersignature on MAC0 Content</name>		<name>Countersignature on MAC0 Content</name>
	<t>This example uses the following:		<t>This example uses the following:
	</t>		</t>
	<ul>		<dl newline="false">
	<li>MAC algorithm: HMAC/SHA-256 with 256-bit key</li>		<dt>MAC Algorithm:</dt><dd>HMAC/SHA-256 with 256-bit key</dd>
	<li>Countersignature algorithm: EdDSA with Curve Ed25519</li>		<dt>Countersignature Algorithm:</dt><dd>EdDSA with Curve Ed25519</
	</ul>		dd>
	<t>Size of binary file is 159 bytes</t>		</dl>
	<sourcecode type="CBORdiag"><![CDATA[		<t>The size of the binary file is 159 bytes.</t>
			<sourcecode type="cbor-diag"><![CDATA[
	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 line 912 ¶		skipping to change at line 862 ¶
	/ tag / h'A1A848D3471F9D61EE49018D244C824772F223AD4F935293F1789F		/ tag / h'A1A848D3471F9D61EE49018D244C824772F223AD4F935293F1789F
	C3A08D8C58'		C3A08D8C58'
	]		]
	)		)
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section numbered="false">		<section numbered="false">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>This document is a product of the COSE working group of the IETF.</t>		<t>This document is a product of the COSE Working Group of the IETF.</t>
	<t>The initial version of the specification was based to some degree on th		<t>The initial draft version of the specification was based to some degree
	e outputs of the JOSE and S/MIME working groups.</t>		on the outputs of the JOSE and S/MIME Working Groups.</t>
	<t>Jim Schaad passed on 3 October 2020. This document is primarily his wo		<t><contact fullname="Jim Schaad"/> passed on 3 October 2020. This docume
	rk. Russ Housley served as the document editor after Jim's untimely death, most		nt is primarily his work. <contact fullname="Russ Housley"/> served as the docu
	ly helping with the approval and publication processes. Jim deserves all credit		ment editor after Jim's untimely death, mostly helping with the approval and pub
	for the technical content.</t>		lication processes. Jim deserves all credit for the technical content.</t>
	<t>Jim Schaad and Jonathan Hammell provided the examples in the Appendix.<		<t><contact fullname="Jim Schaad"/> and <contact fullname="Jonathan Hammel
	/t>		l"/> provided the examples in <xref target="examples"/>.</t>
	<t>The reviews by Carsten Borman, Ben Kaduk, and Elwyn Davies greatly impr		<t>The reviews by <contact fullname="Carsten Bormann"/>, <contact fullname
	oved the clarity of the document.</t>		="Ben Kaduk"/>, and <contact fullname="Elwyn Davies"/> greatly improved the clar
	<!-- RFC EDITOR - Please remove this note before publishing -->		ity of the document.</t>
	<t>{{{ RFC EDITOR: Please remove Russ Housley as an author of this documen
	t at publication. Jim Schaad should be listed as the sole author. }}}</t>
	<!--
	<t>
	The following individuals provided input into the final form of the docu
	ment: Carsten Bormann.
	</t>
	-->
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 91 change blocks.
	364 lines changed or deleted		287 lines changed or added
This html diff was produced by rfcdiff 1.48.