Diff: rfc9459.original.xml

	rfc9459.original.xml	rfc9459.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>

		<!-- draft submitted in xml v3 -->

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.26 (Ruby 2.3.7) -->	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.26 (Ruby 2.3.7) -->

	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-cose-aes-ctr-and-cbc-06" category="std" consensus="true" submissionType="I	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	ETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">	-ietf-cose-aes-ctr-and-cbc-06" number="9459" submissionType="IETF" category="std
		" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"
		updates="" obsoletes="" xml:lang="en" version="3">

	<!-- xml2rfc v2v3 conversion 3.17.1 -->	<!-- xml2rfc v2v3 conversion 3.17.1 -->
	<front>	<front>
	<title abbrev="AES-CTR and AES-CBC with COSE">CBOR Object Signing and Encryp tion (COSE): AES-CTR and AES-CBC</title>	<title abbrev="AES-CTR and AES-CBC with COSE">CBOR Object Signing and Encryp tion (COSE): AES-CTR and AES-CBC</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-cose-aes-ctr-and-cbc-06" />	<seriesInfo name="RFC" value="9459"/>
	<author initials="R." surname="Housley" fullname="Russ Housley">	<author initials="R." surname="Housley" fullname="Russ Housley">
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address>	<address>
	<email>housley@vigilsec.com</email>	<email>housley@vigilsec.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">	<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">

	<organization>Arm Limited</organization>
	<address>	<address>

	<email>hannes.tschofenig@arm.com</email>	<email>hannes.tschofenig@gmx.net</email>
	</address>	</address>
	</author>	</author>

	<date year="2023" month="May" day="25"/>	<date year="2023" month="September"/>
	<area>Security</area>	<area>sec</area>
	<workgroup>COSE</workgroup>	<workgroup>cose</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>	<abstract>
	<t>The Concise Binary Object Representation (CBOR) data format is designed	<t>The Concise Binary Object Representation (CBOR) data format is 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) is specified in RFC 9052 to provide basic	Encryption (COSE) is specified in RFC 9052 to provide basic
	security services using the CBOR data format. This document specifies the	security services using the CBOR data format. This document specifies the

	conventions for using AES-CTR and AES-CBC as Content Encryption	conventions for using AES-CTR and AES-CBC as content encryption
	algorithms with COSE.</t>	algorithms with COSE.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>
	<section anchor="intro">	<section anchor="intro">
	<name>Introduction</name>	<name>Introduction</name>
	<t>This document specifies the conventions for using AES-CTR and AES-CBC	<t>This document specifies the conventions for using AES-CTR and AES-CBC

	as Content Encryption algorithms with the CBOR Object Signing and Encryption	as content encryption algorithms with the CBOR Object Signing and Encryption
	(COSE) <xref target="RFC9052"/> syntax. Encryption with COSE today uses Authent	(COSE) <xref target="RFC9052"/> syntax. Today, encryption with COSE uses Authen
	icated	ticated
	Encryption with Associated Data (AEAD) <xref target="RFC5116"/> algorithms, whic	Encryption with Associated Data (AEAD) algorithms <xref target="RFC5116"/>, whic
	h provide	h provide
	both confidentiality and integrity protection. However, there are situations	both confidentiality and integrity protection. However, there are situations
	where another mechanism, such as a digital signature, is used to provide	where another mechanism, such as a digital signature, is used to provide
	integrity. In these cases, an AEAD algorithm is not needed. The software	integrity. In these cases, an AEAD algorithm is not needed. The software
	manifest being defined by the IETF SUIT WG <xref target="I-D.ietf-suit-manifest" /> is one	manifest being defined by the IETF SUIT WG <xref target="I-D.ietf-suit-manifest" /> is one
	example where a digital signature is always present.</t>	example where a digital signature is always present.</t>
	</section>	</section>
	<section anchor="conventions-and-terminology">	<section anchor="conventions-and-terminology">
	<name>Conventions and Terminology</name>	<name>Conventions and Terminology</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14	<t>
	>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	nterpreted as	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	only when, they	be
	appear in all capitals, as shown here.</t>	interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>
	</section>	</section>
	<section anchor="aes-alg">	<section anchor="aes-alg">
	<name>AES Modes of Operation</name>	<name>AES Modes of Operation</name>

	<t>NIST has defined several modes of operation for Advanced Encryption	<t>NIST has defined several modes of operation for the Advanced Encryption
	Standard (AES) <xref target="AES"/> <xref target="MODES"/>. AES supports three	Standard <xref target="AES"/> <xref target="MODES"/>. AES supports three key si
	key sizes: 128 bits,	zes: 128 bits,
	192 bits, and 256 bits. AES has a block size of 128 bits (16 octets).	192 bits, and 256 bits. AES has a block size of 128 bits (16 octets).
	Each of these modes has different characteristics. The modes include:	Each of these modes has different characteristics. The modes include:
	CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack),	CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack),
	and CTR (Counter).</t>	and CTR (Counter).</t>

	<t>Only AES Counter mode (AES-CTR) and AES Cipher Block Chaining (AES-CBC) are	<t>Only AES Counter (AES-CTR) mode and AES Cipher Block Chaining (AES-CBC) are
	discussed in this document.</t>	discussed in this document.</t>
	</section>	</section>
	<section anchor="aes-ctr">	<section anchor="aes-ctr">
	<name>AES Counter Mode</name>	<name>AES Counter Mode</name>

	<t>When AES-CTR is used as a COSE Content Encryption algorithm, the	<t>When AES-CTR is used as a COSE content encryption algorithm, the
	encryptor generates a unique value that is communicated to the	encryptor generates a unique value that is communicated to the

	decryptor. This value is called an initialization vector (IV) in this	decryptor. This value is called an "Initialization Vector" (or "IV") in this
	document. The same IV and AES key combination <bcp14>MUST NOT</bcp14> be used m ore	document. The same IV and AES key combination <bcp14>MUST NOT</bcp14> be used m ore
	than once. The encryptor can generate the IV in any manner that ensures	than once. The encryptor can generate the IV in any manner that ensures
	the same IV value is not used more than once with the same AES key.</t>	the same IV value is not used more than once with the same AES key.</t>
	<t>When using AES-CTR, each AES encrypt operation generates 128 bits of ke y	<t>When using AES-CTR, each AES encrypt operation generates 128 bits of ke y
	stream. AES-CTR encryption is the XOR of the key stream with the	stream. AES-CTR encryption is the XOR of the key stream with the
	plaintext. AES-CTR decryption is the XOR of the key stream with the	plaintext. AES-CTR decryption is the XOR of the key stream with the
	ciphertext. If the generated key stream is longer than the plaintext or	ciphertext. If the generated key stream is longer than the plaintext or
	ciphertext, the extra key stream bits are simply discarded. For this reason,	ciphertext, the extra key stream bits are simply discarded. For this reason,
	AES-CTR does not require the plaintext to be padded to a multiple of the	AES-CTR does not require the plaintext to be padded to a multiple of the

	block size.</t>	block size.</t>
	<t>AES-CTR has many properties that make it an attractive COSE Content Enc
	ryption	<t>AES-CTR has many properties that make it an attractive COSE content enc
		ryption
	algorithm. AES-CTR uses the AES block cipher to create a stream cipher. Data	algorithm. AES-CTR uses the AES block cipher to create a stream cipher. Data
	is encrypted and decrypted by XORing with the key stream produced by AES	is encrypted and decrypted by XORing with the key stream produced by AES

	encrypting sequential IV block values, called counter blocks. The first	encrypting sequential IV block values, called "counter blocks", where:</t>
	block of the key stream is the AES encryption of the IV, the second block of	<ul><li>The first
	the key stream is the AES encryption of (IV + 1) mod 2^128, the third block of	block of the key stream is the AES encryption of the IV.</li>
	the key stream is the AES encryption of (IV + 2) mod 2^128, and so on. AES-CTR	<li>The second block of
	is easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR	the key stream is the AES encryption of (IV + 1) mod 2<sup>128</sup>.</li>
	also supports key stream precomputation. Sending of the IV is the only	<li>The third block of
		the key stream is the AES encryption of (IV + 2) mod 2<sup>128</sup>, and so on.
		</li></ul><t>AES-CTR
		is easy to implement, can be pipelined and parallelized, and supports key stream
		precomputation. Sending of the IV is the only
	source of expansion because the plaintext and ciphertext are the same size.</t>	source of expansion because the plaintext and ciphertext are the same size.</t>
	<t>When used correctly, AES-CTR provides a high level of confidentiality.	<t>When used correctly, AES-CTR provides a high level of confidentiality.
	Unfortunately, AES-CTR is easy to use incorrectly. Being a stream	Unfortunately, AES-CTR is easy to use incorrectly. Being a stream
	cipher, reuse of the IV with the same key is catastrophic. An IV	cipher, reuse of the IV with the same key is catastrophic. An IV
	collision immediately leaks information about the plaintext. For	collision immediately leaks information about the plaintext. For
	this reason, it is inappropriate to use AES-CTR with static	this reason, it is inappropriate to use AES-CTR with static
	keys. Extraordinary measures would be needed to prevent reuse of an	keys. Extraordinary measures would be needed to prevent reuse of an
	IV value with the static key across power cycles. To be safe,	IV value with the static key across power cycles. To be safe,
	implementations <bcp14>MUST</bcp14> use fresh keys with AES-CTR.</t>	implementations <bcp14>MUST</bcp14> use fresh keys with AES-CTR.</t>
	<t>AES-CTR keys may be obtained either from a key structure or from a reci pient	<t>AES-CTR keys may be obtained either from a key structure or from a reci pient
	structure. Implementations encrypting and decrypting <bcp14>MUST</bcp14> valida te that the	structure. Implementations encrypting and decrypting <bcp14>MUST</bcp14> valida te that the
	key type, key length, and algorithm are correct and appropriate for the	key type, key length, and algorithm are correct and appropriate for the
	entities involved.</t>	entities involved.</t>
	<t>With AES-CTR, it is trivial to use a valid ciphertext to forge other	<t>With AES-CTR, it is trivial to use a valid ciphertext to forge other
	(valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to	(valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to
	use AES-CTR without a companion authentication and integrity	use AES-CTR without a companion authentication and integrity
	mechanism. Implementations <bcp14>MUST</bcp14> use AES-CTR in conjunction with an	mechanism. Implementations <bcp14>MUST</bcp14> use AES-CTR in conjunction with an
	authentication and integrity mechanism, such as a digital signature.</t>	authentication and integrity mechanism, such as a digital signature.</t>

	<t>The instructions in Section 5.4 of <xref target="RFC9052"/> are followe d for AES-CTR.	<t>The instructions in <xref target="RFC9052" sectionFormat="of" section=" 5.4"/> are followed for AES-CTR.
	Since AES-CTR cannot provide integrity protection for external additional	Since AES-CTR cannot provide integrity protection for external additional
	authenticated data, the decryptor <bcp14>MUST</bcp14> ensure that no external ad ditional	authenticated data, the decryptor <bcp14>MUST</bcp14> ensure that no external ad ditional

	authenticated data was supplied. See <xref target="impl-cons"/>.</t>	authenticated data was supplied. See <xref target="impl-cons"/>.</t>

		<t>The 'protected' header <bcp14>MUST</bcp14> be a zero-length byt
		e string.</t>
	<section anchor="aes-ctr-key">	<section anchor="aes-ctr-key">
	<name>AES-CTR COSE Key</name>	<name>AES-CTR COSE Key</name>
	<t>When using a COSE key for the AES-CTR algorithm, the following checks are made:</t>	<t>When using a COSE key for the AES-CTR algorithm, the following checks are made:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li>	<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li>
	<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S-CTR algorithm being used.</li>	<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S-CTR algorithm being used.</li>
	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' when encrypting.</li>	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' when encrypting.</li>
	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' when decrypting.</li>	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' when decrypting.</li>
	</ul>	</ul>

	<t>In addition, the 'protected' header parameters encoded value <bcp14>M UST</bcp14> be a zero-length byte string.</t>
	</section>	</section>
	<section anchor="aes-ctr-alg">	<section anchor="aes-ctr-alg">
	<name>AES-CTR COSE Algorithm Identifiers</name>	<name>AES-CTR COSE Algorithm Identifiers</name>
	<t>The following table defines the COSE AES-CTR algorithm values. Note that	<t>The following table defines the COSE AES-CTR algorithm values. Note that
	these algorithms are being registered as "Deprecated" to avoid accidental	these algorithms are being registered as "Deprecated" to avoid accidental
	use without a companion integrity protection mechanism.</t>	use without a companion integrity protection mechanism.</t>
	<table>	<table>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Name</th>	<th align="left">Name</th>
	<th align="center">Value</th>	<th align="center">Value</th>
	<th align="center">Key Size</th>	<th align="center">Key Size</th>
	<th align="center">Description</th>	<th align="center">Description</th>
	<th align="right">Recommended</th>	<th align="right">Recommended</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">A128CTR</td>	<td align="left">A128CTR</td>

	<td align="center">TBD1</td>	<td align="center">-65534</td>
	<td align="center">128</td>	<td align="center">128</td>
	<td align="center">AES-CTR w/ 128-bit key</td>	<td align="center">AES-CTR w/ 128-bit key</td>
	<td align="right">Deprecated</td>	<td align="right">Deprecated</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">A192CTR</td>	<td align="left">A192CTR</td>

	<td align="center">TBD2</td>	<td align="center">-65533</td>
	<td align="center">192</td>	<td align="center">192</td>
	<td align="center">AES-CTR w/ 192-bit key</td>	<td align="center">AES-CTR w/ 192-bit key</td>
	<td align="right">Deprecated</td>	<td align="right">Deprecated</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">A256CTR</td>	<td align="left">A256CTR</td>

	<td align="center">TBD3</td>	<td align="center">-65532</td>
	<td align="center">256</td>	<td align="center">256</td>
	<td align="center">AES-CTR w/ 256-bit key</td>	<td align="center">AES-CTR w/ 256-bit key</td>
	<td align="right">Deprecated</td>	<td align="right">Deprecated</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	</section>	</section>
	<section anchor="aes-cbc">	<section anchor="aes-cbc">
	<name>AES Cipher Block Chaining Mode</name>	<name>AES Cipher Block Chaining Mode</name>

	<t>AES-CBC mode requires an 16 octet Initialization Vector (IV). Use of a	<t>AES-CBC mode requires a 16-octet IV. Use of a
	randomly or pseudo-randomly generated IV ensures that the encryption of the	randomly or pseudorandomly generated IV ensures that the encryption of the
	same plaintext will yield different ciphertext.</t>	same plaintext will yield different ciphertext.</t>
	<t>AES-CBC performs an XOR of the IV with the first plaintext block before it	<t>AES-CBC performs an XOR of the IV with the first plaintext block before it

	is encrypted. For successive blocks, AES-CBC performs an XOR of previous	is encrypted. For successive blocks, AES-CBC performs an XOR of the previous
	ciphertext block with the current plaintext before it is encrypted.</t>	ciphertext block with the current plaintext before it is encrypted.</t>
	<t>AES-CBC requires padding of the plaintext; the padding algorithm specif ied	<t>AES-CBC requires padding of the plaintext; the padding algorithm specif ied

	in Section 6.3 of <xref target="RFC5652"/> <bcp14>MUST</bcp14> be used prior to encrypting the	in <xref target="RFC5652" sectionFormat="of" section="6.3"/> <bcp14>MUST</bcp14> be used prior to encrypting the
	plaintext. This padding algorithm allows the decryptor to unambiguously	plaintext. This padding algorithm allows the decryptor to unambiguously
	remove the padding.</t>	remove the padding.</t>

	<t>The simplicity of AES-CBC makes it an attractive COSE Content Encryptio n	<t>The simplicity of AES-CBC makes it an attractive COSE content encryptio n
	algorithm. The need to carry an IV and the need for padding lead to an	algorithm. The need to carry an IV and the need for padding lead to an
	increase in the overhead (when compared to AES-CTR). AES-CBC is much safer	increase in the overhead (when compared to AES-CTR). AES-CBC is much safer
	for use with static keys than AES-CTR. That said, as described in <xref target= "RFC4107"/>,	for use with static keys than AES-CTR. That said, as described in <xref target= "RFC4107"/>,
	the use of automated key management to generate fresh keys is greatly	the use of automated key management to generate fresh keys is greatly
	preferred.</t>	preferred.</t>
	<t>AES-CBC does not provide integrity protection. Thus, an attacker	<t>AES-CBC does not provide integrity protection. Thus, an attacker
	can introduce undetectable errors if AES-CBC is used without a companion	can introduce undetectable errors if AES-CBC is used without a companion
	authentication and integrity mechanism. Implementations <bcp14>MUST</bcp14> use AES-CBC	authentication and integrity mechanism. Implementations <bcp14>MUST</bcp14> use AES-CBC
	in conjunction with an authentication and integrity mechanism, such as a	in conjunction with an authentication and integrity mechanism, such as a
	digital signature.</t>	digital signature.</t>

	<t>The instructions in Section 5.4 of <xref target="RFC9052"/> are followe d for AES-CBC.	<t>The instructions in <xref target="RFC9052" sectionFormat="of" section=" 5.4"/> are followed for AES-CBC.
	Since AES-CBC cannot provide integrity protection for external additional	Since AES-CBC cannot provide integrity protection for external additional
	authenticated data, the decryptor <bcp14>MUST</bcp14> ensure that no external ad ditional	authenticated data, the decryptor <bcp14>MUST</bcp14> ensure that no external ad ditional

	authenticated data was supplied. See <xref target="impl-cons"/>.</t>	authenticated data was supplied. See <xref target="impl-cons"/>.</t>

		<t>The 'protected' header <bcp14>MUST</bcp14> be a zero-length byt
		e string.</t>
	<section anchor="aes-cbc-key">	<section anchor="aes-cbc-key">
	<name>AES-CBC COSE Key</name>	<name>AES-CBC COSE Key</name>
	<t>When using a COSE key for the AES-CBC algorithm, the following checks are made:</t>	<t>When using a COSE key for the AES-CBC algorithm, the following checks are made:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li>	<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li>
	<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S-CBC algorithm being used.</li>	<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S-CBC algorithm being used.</li>
	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' when encrypting.</li>	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' when encrypting.</li>
	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' when decrypting.</li>	<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' when decrypting.</li>
	</ul>	</ul>

	<t>In addition, the 'protected' header parameters encoded value <bcp14>M UST</bcp14> be a zero-length byte string.</t>
	</section>	</section>
	<section anchor="aes-cbc-alg">	<section anchor="aes-cbc-alg">

	<name>AES-CBC COSE Algoritm Identifiers</name>	<name>AES-CBC COSE Algorithm Identifiers</name>
	<t>The following table defines the COSE AES-CBC algorithm values. Note t hat	<t>The following table defines the COSE AES-CBC algorithm values. Note t hat
	these algorithms are being registered as "Deprecated" to avoid accidental	these algorithms are being registered as "Deprecated" to avoid accidental
	use without a companion integrity protection mechanism.</t>	use without a companion integrity protection mechanism.</t>
	<table>	<table>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Name</th>	<th align="left">Name</th>
	<th align="center">Value</th>	<th align="center">Value</th>
	<th align="center">Key Size</th>	<th align="center">Key Size</th>
	<th align="center">Description</th>	<th align="center">Description</th>
	<th align="right">Recommended</th>	<th align="right">Recommended</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">A128CBC</td>	<td align="left">A128CBC</td>

	<td align="center">TBD4</td>	<td align="center">-65531</td>
	<td align="center">128</td>	<td align="center">128</td>
	<td align="center">AES-CBC w/ 128-bit key</td>	<td align="center">AES-CBC w/ 128-bit key</td>
	<td align="right">Deprecated</td>	<td align="right">Deprecated</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">A192CBC</td>	<td align="left">A192CBC</td>

	<td align="center">TBD5</td>	<td align="center">-65530</td>
	<td align="center">192</td>	<td align="center">192</td>
	<td align="center">AES-CBC w/ 192-bit key</td>	<td align="center">AES-CBC w/ 192-bit key</td>
	<td align="right">Deprecated</td>	<td align="right">Deprecated</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">A256CBC</td>	<td align="left">A256CBC</td>

	<td align="center">TBD6</td>	<td align="center">-65529</td>
	<td align="center">256</td>	<td align="center">256</td>
	<td align="center">AES-CBC w/ 256-bit key</td>	<td align="center">AES-CBC w/ 256-bit key</td>
	<td align="right">Deprecated</td>	<td align="right">Deprecated</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	</section>	</section>
	<section anchor="impl-cons">	<section anchor="impl-cons">
	<name>Implementation Considerations</name>	<name>Implementation Considerations</name>
	<t>COSE libraries that support either AES-CTR or AES-CBC and accept	<t>COSE libraries that support either AES-CTR or AES-CBC and accept
	Additional Authenticated Data (AAD) as input <bcp14>MUST</bcp14> return an	Additional Authenticated Data (AAD) as input <bcp14>MUST</bcp14> return an

	error if one of these non-AEAD content encryption algorithm is	error if one of these non-AEAD content encryption algorithms is
	selected. This ensures that a caller does not expect the AAD	selected. This ensures that a caller does not expect the AAD
	to be protected when the cryptographic algorithm is unable to do so.</t>	to be protected when the cryptographic algorithm is unable to do so.</t>
	</section>	</section>
	<section anchor="iana-cons">	<section anchor="iana-cons">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>IANA is requested to register six COSE algorithm identifiers for AES-CT
	R and	<t>IANA has registered six COSE algorithm identifiers for AES-CTR and
	AES-CBC in the COSE Algorithms Registry <xref target="IANA"/>.</t>	AES-CBC in the "COSE Algorithms" registry <xref target="IANA-COSE"/>.</t>
	<t>The information for the six COSE algorithm identifiers is provided in	<t>The information for the six COSE algorithm identifiers is provided in

	<xref target="aes-ctr-alg"/> and <xref target="aes-cbc-alg"/>. Also, for all si	Sections <xref target="aes-ctr-alg" format="counter"/> and <xref target="aes-cbc
	x entries, the	-alg" format="counter"/>. Also, for all six entries, the
	"Capabilities" column should contain "[kty]", the "Change Controller"	"Capabilities" column contains "[kty]", the "Change Controller"
	column should contain "IESG", and the "Reference" column should contain	column contains "IETF", and the "Reference" column contains
	a reference to this document.</t>	a reference to this document.</t>

	<t>Ideally, the six values will be assigned in the -65534 to -261 range.</ t>
	</section>	</section>
	<section anchor="sec-cons">	<section anchor="sec-cons">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>This document specifies AES-CTR and AES-CBC for COSE, which are not	<t>This document specifies AES-CTR and AES-CBC for COSE, which are not

	authenticated encryption with additional data (AEAD) ciphers. The use	AEAD ciphers. The use of the ciphers is limited to special use cases, such as f
	of the ciphers is limited to special use cases where integrity and	irmware encryption, where integrity and authentication is provided by another me
	authentication is provided by another mechanism, such as firmware	chanism.</t>
	encryption.</t>
	<t>Since AES has a 128-bit block size, regardless of the mode	<t>Since AES has a 128-bit block size, regardless of the mode
	employed, the ciphertext generated by AES encryption becomes	employed, the ciphertext generated by AES encryption becomes

	distinguishable from random values after 2^64 blocks are encrypted	distinguishable from random values after 2<sup>64</sup> blocks are encrypted
	with a single key. Implementations should change the key before	with a single key. Implementations should change the key before
	reaching this limit.</t>	reaching this limit.</t>
	<t>To avoid cross-protocol concerns, implementations <bcp14>MUST NOT</bcp1 4> use the same	<t>To avoid cross-protocol concerns, implementations <bcp14>MUST NOT</bcp1 4> use the same
	keying material with more than one mode. For example, the same keying	keying material with more than one mode. For example, the same keying
	material must not be used with AES-CTR and AES-CBC.</t>	material must not be used with AES-CTR and AES-CBC.</t>
	<t>There are fairly generic precomputation attacks against all block ciphe r	<t>There are fairly generic precomputation attacks against all block ciphe r
	modes that allow a meet-in-the-middle attack against the key. These attacks	modes that allow a meet-in-the-middle attack against the key. These attacks
	require the creation and searching of huge tables of ciphertext associated	require the creation and searching of huge tables of ciphertext associated
	with known plaintext and known keys. Assuming that the memory and processor	with known plaintext and known keys. Assuming that the memory and processor
	resources are available for a precomputation attack, then the theoretical	resources are available for a precomputation attack, then the theoretical

	strength of AES-CTR and AES-CBC are limited to 2^(n/2) bits, where n is the	strength of AES-CTR and AES-CBC is limited to 2<sup>(n/2)</sup> bits, where n is the
	number of bits in the key. The use of long keys is the best countermeasure	number of bits in the key. The use of long keys is the best countermeasure
	to precomputation attacks.</t>	to precomputation attacks.</t>
	<t>When used properly, AES-CTR mode provides strong confidentiality. Unfor tunately,	<t>When used properly, AES-CTR mode provides strong confidentiality. Unfor tunately,
	it is very easy to misuse this counter mode. If counter block values are ever	it is very easy to misuse this counter mode. If counter block values are ever
	used for more than one plaintext with the same key, then the same key stream	used for more than one plaintext with the same key, then the same key stream
	will be used to encrypt both plaintexts, and the confidentiality guarantees are	will be used to encrypt both plaintexts, and the confidentiality guarantees are
	voided.</t>	voided.</t>
	<t>What happens if the encryptor XORs the same key stream with two differe nt	<t>What happens if the encryptor XORs the same key stream with two differe nt
	plaintexts? Suppose two plaintext octet sequences P1, P2, P3 and Q1, Q2, Q3	plaintexts? Suppose two plaintext octet sequences P1, P2, P3 and Q1, Q2, Q3
	are both encrypted with key stream K1, K2, K3. The two corresponding	are both encrypted with key stream K1, K2, K3. The two corresponding

	skipping to change at line 319 ¶	skipping to change at line 334 ¶
	(P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2	(P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
	(P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3	(P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3
	]]></artwork>	]]></artwork>
	<t>Once the attacker obtains the two plaintexts XORed together, it is rela tively	<t>Once the attacker obtains the two plaintexts XORed together, it is rela tively
	straightforward to separate them. Thus, using any stream cipher, including	straightforward to separate them. Thus, using any stream cipher, including
	AES-CTR, to encrypt two plaintexts under the same key stream leaks the	AES-CTR, to encrypt two plaintexts under the same key stream leaks the
	plaintext.</t>	plaintext.</t>
	<t>Data forgery is trivial with AES-CTR mode. The demonstration of this at tack	<t>Data forgery is trivial with AES-CTR mode. The demonstration of this at tack
	is similar to the key stream reuse discussion above. If a known plaintext	is similar to the key stream reuse discussion above. If a known plaintext
	octet sequence P1, P2, P3 is encrypted with key stream K1, K2, K3, then the	octet sequence P1, P2, P3 is encrypted with key stream K1, K2, K3, then the

	attacker can replace the plaintext with one of his own choosing. The	attacker can replace the plaintext with one of its own choosing. The
	ciphertext is:</t>	ciphertext is:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)	(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
	]]></artwork>	]]></artwork>
	<t>The attacker simply XORs a selected sequence Q1, Q2, Q3 with the	<t>The attacker simply XORs a selected sequence Q1, Q2, Q3 with the
	ciphertext to obtain:</t>	ciphertext to obtain:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))	(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
	]]></artwork>	]]></artwork>
	<t>Which is the same as:</t>	<t>Which is the same as:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)	((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)
	]]></artwork>	]]></artwork>
	<t>Decryption of the attacker-generated ciphertext will yield exactly what	<t>Decryption of the attacker-generated ciphertext will yield exactly what
	the attacker intended:</t>	the attacker intended:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	(Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)	(Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)
	]]></artwork>	]]></artwork>
	<t>AES-CBC does not provide integrity protection. Thus, an attacker	<t>AES-CBC does not provide integrity protection. Thus, an attacker
	can introduce undetectable errors if AES-CBC is used without a companion	can introduce undetectable errors if AES-CBC is used without a companion

	authentication mechanism.</t>	authentication mechanism.</t>

	<t>If an attacker is able to strip the authentication and integrity mechan ism,	<t>If an attacker is able to strip the authentication and integrity mechan ism,
	then the attacker can replace it with one of their own creation, even	then the attacker can replace it with one of their own creation, even
	without knowing the plaintext. The usual defense against such an attack is	without knowing the plaintext. The usual defense against such an attack is

	an Authenticated Encryption with Associated Data (AEAD) <xref target="RFC5116"/>	an Authenticated Encryption with Associated Data (AEAD) algorithm <xref target="
	algorithm. Of course, neither AES-CTR nor AES-CBC is an AEAD. Thus,	RFC5116"/>. Of course, neither AES-CTR nor AES-CBC is an AEAD. Thus,
	an implementation should provide integrity protection for the kid field	an implementation should provide integrity protection for the 'kid' field
	to prevent undetected stripping of the authentication and integrity	to prevent undetected stripping of the authentication and integrity

	mechanism; this prevents an attacker from altering the kid to trick the	mechanism; this prevents an attacker from altering the 'kid' to trick the
	recipient into using a different key.</t>	recipient into using a different key.</t>
	<t>With AES-CBC mode, implementers should perform integrity checks prior t o	<t>With AES-CBC mode, implementers should perform integrity checks prior t o
	decryption to avoid padding oracle vulnerabilities <xref target="Vaudenay"/>.</t >	decryption to avoid padding oracle vulnerabilities <xref target="Vaudenay"/>.</t >
	<t>With the assignment of COSE algorithm identifiers for AES-CTR and	<t>With the assignment of COSE algorithm identifiers for AES-CTR and
	AES-CBC in the COSE Algorithms Registry, an attacker can replace the	AES-CBC in the COSE Algorithms Registry, an attacker can replace the
	COSE algorithm identifiers with one of these identifiers. Then, the	COSE algorithm identifiers with one of these identifiers. Then, the
	attacker might be able to manipulate the ciphertext to learn some of the	attacker might be able to manipulate the ciphertext to learn some of the
	plaintext or extract the keying material used for authentication and	plaintext or extract the keying material used for authentication and
	integrity.</t>	integrity.</t>
	<t>Since AES-CCM <xref target="RFC3610"/> and AES-GCM <xref target="GCMMOD E"/> use AES-CTR for encryption,	<t>Since AES-CCM <xref target="RFC3610"/> and AES-GCM <xref target="GCMMOD E"/> use AES-CTR for encryption,

	an attacker can switch the algorithm identifier to AES-CTR, and then strip the	an attacker can switch the algorithm identifier to AES-CTR and then strip the
	authentication tag to bypass the authentication and integrity, allowing the	authentication tag to bypass the authentication and integrity, allowing the

	attacker to manipulate the ciphertext.</t>	attacker to manipulate the ciphertext.</t>

	<t>An attacker can switch the algorithm identifier from AES-GCM to AES-CBC ,	<t>An attacker can switch the algorithm identifier from AES-GCM to AES-CBC ,

	guess of 16 bytes of plaintext at a time, and checking each guess with	guessing 16 bytes of plaintext at a time, and see if the recipient
	padding oracle as discussed above.</t>	accepts the padding. Padding oracle vulnerabilities are discussed
	</section>	further in <xref target="Vaudenay" format="default"/>.</t>
	<section anchor="acknowledgements">
	<name>Acknowledgements</name>
	<t>Many thanks to David Brown for raising the need for non-AEAD algorithms
	to support encryption within the SUIT manifest. Many thanks to
	David Brown,
	Ilari Liusvaara,
	Scott Arciszewski,
	John Preuß Mattsson,
	Laurence Lundblade,
	Paul Wouters,
	Roman Danyliw, and
	John Scudder
	for the review and thoughtful comments.</t>
	</section>	</section>


	</middle>	</middle>
	<back>	<back>


		<displayreference target="I-D.ietf-suit-manifest" to="SUIT-MANIFEST"/>

	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	119">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	<front>	/>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
	le>	/>
	<author fullname="S. Bradner" initials="S." surname="Bradner">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4107.xml"
	<organization/>	/>
	</author>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"
	<date month="March" year="1997"/>	/>
	<abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"
	<t>In many standards track documents several words are used to sig	/>
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba">
	<organization/>
	</author>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC4107" target="https://www.rfc-editor.org/info/rfc4
	107">
	<front>
	<title>Guidelines for Cryptographic Key Management</title>
	<author fullname="S. Bellovin" initials="S." surname="Bellovin">
	<organization/>
	</author>
	<author fullname="R. Housley" initials="R." surname="Housley">
	<organization/>
	</author>
	<date month="June" year="2005"/>
	<abstract>
	<t>The question often arises of whether a given security system re
	quires some form of automated key management, or whether manual keying is suffic
	ient. This memo provides guidelines for making such decisions. When symmetric c
	ryptographic mechanisms are used in a protocol, the presumption is that automate
	d key management is generally but not always needed. If manual keying is propos
	ed, the burden of proving that automated key management is not required falls to
	the proposer. This document specifies an Internet Best Current Practices for t
	he Internet Community, and requests discussion and suggestions for improvements.
	</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="107"/>
	<seriesInfo name="RFC" value="4107"/>
	<seriesInfo name="DOI" value="10.17487/RFC4107"/>
	</reference>
	<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5
	652">
	<front>
	<title>Cryptographic Message Syntax (CMS)</title>
	<author fullname="R. Housley" initials="R." surname="Housley">
	<organization/>
	</author>
	<date month="September" year="2009"/>
	<abstract>
	<t>This document describes the Cryptographic Message Syntax (CMS).
	This syntax is used to digitally sign, digest, authenticate, or encrypt arbitr
	ary message content. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="70"/>
	<seriesInfo name="RFC" value="5652"/>
	<seriesInfo name="DOI" value="10.17487/RFC5652"/>
	</reference>
	<reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rfc9
	052">
	<front>
	<title>CBOR Object Signing and Encryption (COSE): Structures and Pro
	cess</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad">
	<organization/>
	</author>
	<date month="August" year="2022"/>
	<abstract>
	<t>Concise Binary Object Representation (CBOR) is a data format de
	signed for small code size and small message size. There is a need to be able t
	o define basic security services for this data format. This document defines th
	e CBOR Object Signing and Encryption (COSE) protocol. This specification descri
	bes how to create and process signatures, message authentication codes, and encr
	yption using CBOR for serialization. This specification additionally describes
	how to represent cryptographic keys using CBOR. </t>
	<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="96"/>
	<seriesInfo name="RFC" value="9052"/>
	<seriesInfo name="DOI" value="10.17487/RFC9052"/>
	</reference>
	<reference anchor="AES">	<reference anchor="AES">
	<front>	<front>
	<title>Advanced Encryption Standard (AES)</title>	<title>Advanced Encryption Standard (AES)</title>
	<author>	<author>
	<organization>National Institute of Standards and Technology (NIST )</organization>	<organization>National Institute of Standards and Technology (NIST )</organization>
	</author>	</author>

	<date year="2001" month="November"/>	<date year="2023" month="May"/>
	</front>	</front>

	<seriesInfo name="FIPS Publication" value="197"/>	<seriesInfo name="NIST FIPS" value="197"/>
		<seriesInfo name='DOI' value="10.6028/NIST.FIPS.197-upd1" />
	</reference>	</reference>


	<reference anchor="MODES">	<reference anchor="MODES">
	<front>	<front>
	<title>Recommendation for Block Cipher Modes of Operation: Methods a nd Techniques</title>	<title>Recommendation for Block Cipher Modes of Operation: Methods a nd Techniques</title>
	<author initials="M." surname="Dworkin" fullname="Morris Dworkin">	<author initials="M." surname="Dworkin" fullname="Morris Dworkin">
	<organization>National Institute of Standards and Technology (NIST )</organization>	<organization>National Institute of Standards and Technology (NIST )</organization>
	</author>	</author>
	<date year="2001" month="December"/>	<date year="2001" month="December"/>
	</front>	</front>
	<seriesInfo name="NIST Special Publication" value="800-38A"/>	<seriesInfo name="NIST Special Publication" value="800-38A"/>

		<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A "/>
	</reference>	</reference>
	</references>	</references>
	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="RFC3610" target="https://www.rfc-editor.org/info/rfc3
	610">
	<front>
	<title>Counter with CBC-MAC (CCM)</title>
	<author fullname="D. Whiting" initials="D." surname="Whiting">
	<organization/>
	</author>
	<author fullname="R. Housley" initials="R." surname="Housley">
	<organization/>
	</author>
	<author fullname="N. Ferguson" initials="N." surname="Ferguson">
	<organization/>
	</author>
	<date month="September" year="2003"/>
	<abstract>
	<t>Counter with CBC-MAC (CCM) is a generic authenticated encryptio
	n block cipher mode. CCM is defined for use with 128-bit block ciphers, such as
	the Advanced Encryption Standard (AES).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3610"/>
	<seriesInfo name="DOI" value="10.17487/RFC3610"/>
	</reference>
	<reference anchor="RFC5116" target="https://www.rfc-editor.org/info/rfc5
	116">
	<front>
	<title>An Interface and Algorithms for Authenticated Encryption</tit
	le>
	<author fullname="D. McGrew" initials="D." surname="McGrew">
	<organization/>
	</author>
	<date month="January" year="2008"/>
	<abstract>
	<t>This document defines algorithms for Authenticated Encryption w
	ith Associated Data (AEAD), and defines a uniform interface and a registry for s
	uch algorithms. The interface and registry can be used as an application-indepe
	ndent set of cryptoalgorithm suites. This approach provides advantages in effic
	iency and security, and promotes the reuse of crypto implementations. [STANDARD
	S-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5116"/>
	<seriesInfo name="DOI" value="10.17487/RFC5116"/>
	</reference>
	<reference anchor="I-D.ietf-suit-manifest" target="https://datatracker.i
	etf.org/doc/html/draft-ietf-suit-manifest-22">
	<front>
	<title>A Concise Binary Object Representation (CBOR)-based Serializa
	tion Format for the Software Updates for Internet of Things (SUIT) Manifest</tit
	le>
	<author fullname="Brendan Moran" initials="B." surname="Moran">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofen
	ig">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
	<organization>Fraunhofer SIT</organization>
	</author>
	<author fullname="Koen Zandberg" initials="K." surname="Zandberg">
	<organization>Inria</organization>
	</author>
	<author fullname="Øyvind Rønningstad" initials="O." surname="Rønning
	stad">
	<organization>Nordic Semiconductor</organization>
	</author>
	<date day="27" month="February" year="2023"/>
	<abstract>
	<t> This specification describes the format of a manifest. A ma
	nifest is
	a bundle of metadata about code/data obtained by a recipient (chiefly
	the firmware for an IoT device), where to find the that code/data,
	the devices to which it applies, and cryptographic information
	protecting the manifest. Software updates and Trusted Invocation
	both tend to use sequences of common operations, so the manifest
	encodes those sequences of operations, rather than declaring the
	metadata.


	</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3610.xml"
	</abstract>	/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"
	<seriesInfo name="Internet-Draft" value="draft-ietf-suit-manifest-22"/	/>
	>
	</reference>	<!-- [I-D.ietf-suit-manifest] IESG state AD Evaluation::Revised I-D Needed - Use
		d Long Way to capture non-ASCII initial-->

		<reference anchor="I-D.ietf-suit-manifest" target="https://datatracker.ietf.org/
		doc/html/draft-ietf-suit-manifest-22">
		<front>
		<title>A Concise Binary Object Representation (CBOR)-based Serialization For
		mat for the Software Updates for Internet of Things (SUIT) Manifest</title>
		<author fullname="Brendan Moran" initials="B." surname="Moran">
		<organization>Arm Limited</organization>
		</author>
		<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
		<organization>Arm Limited</organization>
		</author>
		<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
		<organization>Fraunhofer SIT</organization>
		</author>
		<author fullname="Koen Zandberg" initials="K." surname="Zandberg">
		<organization>Inria</organization>
		</author>
		<author fullname="Øyvind Rønningstad" initials="Ø." surname="Rønningstad">
		<organization>Nordic Semiconductor</organization>
		</author>
		<date day="27" month="February" year="2023"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-suit-manifest-22"/>
		</reference>

	<reference anchor="GCMMODE">	<reference anchor="GCMMODE">
	<front>	<front>
	<title>Recommendation for Block Cipher Modes of Operation: Galois/Co unter Mode (GCM) and GMAC</title>	<title>Recommendation for Block Cipher Modes of Operation: Galois/Co unter Mode (GCM) and GMAC</title>
	<author initials="M." surname="Dworkin" fullname="Morris Dworkin">	<author initials="M." surname="Dworkin" fullname="Morris Dworkin">
	<organization>National Institute of Standards and Technology (NIST )</organization>	<organization>National Institute of Standards and Technology (NIST )</organization>
	</author>	</author>
	<date year="2007" month="November"/>	<date year="2007" month="November"/>
	</front>	</front>
	<seriesInfo name="NIST Special Publication" value="800-38D"/>	<seriesInfo name="NIST Special Publication" value="800-38D"/>

		<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D "/>
	</reference>	</reference>

	<reference anchor="IANA" target="https://www.iana.org/assignments/cose/c
	ose.xhtml">	<reference anchor="IANA-COSE" target="https://www.iana.org/assignments/c
		ose">
	<front>	<front>

	<title>IANA Registry for CBOR Object Signing and Encryption (COSE)</ title>	<title>CBOR Object Signing and Encryption (COSE)</title>
	<author>	<author>

	<organization/>	<organization>IANA</organization>
	</author>	</author>

	<date>n.d.</date>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="Vaudenay" target="https://www.iacr.org/cryptodb/archi ve/2002/EUROCRYPT/2850/2850.pdf">	<reference anchor="Vaudenay" target="https://www.iacr.org/cryptodb/archi ve/2002/EUROCRYPT/2850/2850.pdf">
	<front>	<front>

	<title>Security Flaws Induced by CBC Padding Applications to SSL, IP SEC, WTLS...</title>	<title>Security Flaws Induced by CBC Padding -- Applications to SSL, IPSEC, WTLS...</title>
	<author initials="S." surname="Vaudenay" fullname="Serge Vaudenay">	<author initials="S." surname="Vaudenay" fullname="Serge Vaudenay">
	<organization>Swiss Federal Institute of Technology (EPFL)</organi zation>	<organization>Swiss Federal Institute of Technology (EPFL)</organi zation>
	</author>	</author>
	<date year="2002"/>	<date year="2002"/>
	</front>	</front>
	<seriesInfo name="EUROCRYPT" value="2002"/>	<seriesInfo name="EUROCRYPT" value="2002"/>
	</reference>	</reference>
	</references>	</references>
	</references>	</references>

	</back>
	<!-- ##markdown-source:
	H4sIAKB/b2QAA+1b63IbR3b+jyq8Qy/9Q+IGgEhIoi1uNlkSpGTGpEgRlLwu
	x95qDBpAL+eCnZ4hBUvyqyTPkrxYvnP6Mj0gRMnObtUmtayyBcyl+/S5fueC
	fr/f7VS6StW+2Bodnl+K88mfVVKJsZ7nOp8LmU/FcZ6Uq2Wli1w8HJ2Pj7f3
	xcHxuD+6uuTb/PlwtNXtyMmkVDcb74pbXS0Evd3tTIsklxl2nJZyVvW1qmb9
	pDCqL5XpJ1XZx3v9ZJL0d/bwsKzw5HBn+Li/87Q/fNrtJLgyL8rVvjDVtNvp
	dvSy3BdVWZtquLPzbGfY7Zh6kmljQHG1WuL1k+Or5yCvVHJfjFVSl7padTu3
	RXk9L4t6ue8Iu1YrXJvi+bxSZa6q/hFRSHuYCkT9SaZFrngv1e0s9b74viqS
	njBFWZVqZvBpldGHH+gVWVeLotzvdgR4LPCnc7MvLgfi66I2qVrZi5YTl7Ux
	7etFOd8Xb/Rcp4Hinjg9Hdm7ntPtB+w9lUmd7ouFXe0PN/SIUckgKbI1Wr4e
	iCuTLIqZyvU8JudrmefK3LkJmmSuf5KkCpBymYlTnelKTdsb88uDKrz8B1lm
	dvduJy/KDO/fKOKLuHw+Gu7uPvOfv9r98on//GR350v/+ene06H//GzHfYZi
	7dt9vf4eTG9knqiWwo5JbrKciod4fnvLcS9IRgRWv+RTyRSyN1iwrpQoZuF1
	w7p8pZJFXqTFfCUevjwZX23bFbyK7uz2d3ftJaNKrYzOZ0XYZev5ycVYXNST
	VCe81xZI3n32JdN0dn505ziXCjzLFPbnk8yKUhymRXItRnq5UKU4K6aQEYg8
	X6rSyeRM4WQxtfovtTKbj80qcDYQR2QHOveXrQacFWWpzfq9vyanhh/nFL0h
	xkuVaOyyxrGvdnb6j7862GLDx1tr6vR4b3cnqM3u7h5/PukfDdjLmFpX/Qw6
	PFOm4lsvRmfE+78C61/AOWjzaFTU5Dz4EfEQy28zQ16cHYz+/sTw5b0K+2kx
	HPGRTg5eHrQZSFfEpZprU5UrZt9nxxa3jiznqoIvqaql2X/06Pb2dqBlLgc4
	+iMJzz7PIZ7KPKK4wf8bvF1UWUpvv5H1VOVytSZT7yTF81TeGnBtWpOvmKwE
	hacLOZ0STQfLpT+mEVUhxuPTnoDhHo964tur0/FgMLhHjONB2L0tx7HCee7c
	YzmObxGpxHM1hSatCTMW3/HF89N18d1jQsevL89Hl99dXJGw6NGt+xiblMxY
	FkUxnTySZbKAUT2iFx+FpR4Nv3q6w/8bLKczMsB+v49QBCHLhKPk1UKJUZEn
	2ihxqHMJ4TuZX6plqQxEJp2soQ/bdBIprA0LqDmMCoKlcEIqYzKZpiIhOzL6
	J8XqYq9lyhg5t5cHH1OtbueObtEehvR5piF5nZOTEBRQSNLLsrjR2GsijU4Q
	8L26gLs3OoG514ZWruiItGNEO8Logsgvkpq0Muxh6GkAliK/wWVWKTqYXWgT
	SJKG2FfRGg3xQBIp8A7wU2YaGDXw/M/0dJoq+vYF4ZaygF7zmd99oenrByuY
	j9InPp88ULKJQLFOX+DRvQbf7TipvHvn4vqHDwBQUJG3AxEvH84MMU3lCgSC
	8gOYH1FNaLAta378wJgCfgv3xBEJCuH/4MhtRXEBWzVU98TtQicLrwLdzqTA
	EuDLDN+wh0xJEYh6cFTNWS3wbKWY0SD26+JW3aiyRycvoakl6WZVWzcCoGmv
	5gXdhvYmgEjaZICLNXYFT6WYAqVVsH8yAFnVpeqRsuKk00g3KeK5/bHpSU7b
	wdISCYb0sL6gQzbnohWwp8gVnMsUb5B5mmJW3YLAbsfHQTFRJJypmuncOkSS
	H0FmMX59ciW+fQG2bQ6h4CL2ACbudtRbmS1TJdxZ7x6InpTprVwZ4VzBwCrt
	KNI/G7TKTFu3530KgLkgZG7E1tnr8dVWz/4rXp7z58vjV69PLo+P6PP464PT
	0/Ch454Yf33++vSo+dS8OTo/Ozt+eWRfxlXRutTZOjv4bqvHdG2dX1ydnL88
	ON0i11G1LIokDjlNFGtIiQOS5knTgUtLSj2x7uZwdPFf/7n7BOz8jUO+YKD9
	QtAXX8C93O5W5OnKfYU4Vh25XCpZ0irsFeWSuEtSh0tbFLe5IL4POp3ffk+c
	+WFf/PMkWe4++Rd3gQ7cuuh51rrIPLt75c7LlokbLm3YJnCzdX2N0216D75r
	ffd8jy5azYFf2gDF4PgokYQZsOtjFLOQJii4IVOFZmb+zSK8Se5vQxbR7bTT
	CMgM/7DsGLh/+DDgfAT2vFwiFyS/WiqrthSjgAx2h1+Jia5Mr9vZfTa0H1nO
	w6d7/M2tsGBvMGGwyVEP9Pl3xcPdPVEklarMNmznWMJ54LZ1AvY0fE49m0EX
	oJXwMxSZAQ8AKhLjPIB9UudJCjQCxECe/aEDtg7lLqQmh73dE6Pnh+Hmc/iR
	Q5lc4/I5XT6vq2VdRZcRH3AiihoPHQzeZhs/J12m03lwnDE4diFm28cYsZEI
	99zhaFuw25pqkyBbthbVssJBoxUtFG71IalK1odvYVMhunkfy1znEHNfeOvZ
	eK7sLejKXOWkOorerjnXEjcyxf+rhUU0lEbgBgcpchD8/lS591kgeMq+Q4/D
	tomaHGfTHHdssi1uEGqw38OTN9v+2FxHsed2nh1IU5y8Cdwk7cP+E+AwXsO7
	AfJSfOisIH6C1BzeJlFumeZ0CW74E9qY8Ib9T74SGeX4pT2myg3cu6GVGiLC
	kSgAhd1E2KwBCvyGo3cQBNQCIT2hSNfpIUddZLONDIKdwCiuqY4CYKpkZi2L
	xa0aoWoLfv4IlGJtyForvxGI63aWqSSP/raKVnHy+wWrJKzYbpkT+6Cnexq/
	gvXSIp9b1nJ8F4ECpAvxSqyMAh9KGa/ADLAABPF4Jchc4Lg4/j8vSmsxeNIU
	Oew1HKlQVlSl+kutS7W2sw1tS+RIVo2lyOq00hTv7bEBmYLLYiH6hckhZaQx
	gDAQWWVBJ7Qmk9fQj4p0XVacQCDh+JgJRhA4kgPjQCKUFMPub9lDJCY4Y0VA
	xPHF3sHbBAcBpIxXBra3qReqBUCQJ6lf0NGIv0sG2PYx7Bu8AT1vwDyLF8kE
	LEVsCPD1zrQT55j4pvfIM12ayrPwrh7p5pSRArvnTt5YRUC+UuAYfg1rjZ+z
	CHyK+Cexu01OWQx/hBHZBaEo5a9fb9haj1O3QjBWdtKzIpBmRcIiVVXkynpN
	vgEBkwMivdNLlXLopptLxDSwEq6RdTosBzRUNAG4JTGq5iBSSYfWxyrnXD9w
	0B+GMBe8RlGXCSu2eruUOVWRQUUioW5rZkHkNAZpQaD3aMESnDtj2ZcgpUpX
	vXBCB+wpfiz0fCFSYJOUtl5LPrDSayp2VTWcuYpXiLhIBCKs+11w0kNG9t4G
	vPfowcrp2eb8bWdMvONgVEm8WCyRGxGjczxJyWyaauaJzjI11UwO6JbXhClc
	PY6C5qQANmjxy3og0qTGBZEL0PQm8C22KjXHGnsWf0SmzpD4Eq7Rk9kck99D
	RmCLDBkWoxiEJKFOp6QzNuexuZOi9KI5s4Q7CRGqOTmvz2eXSVkYZClI6hAE
	V0mq2FDZBxo5U/CbQWFdpYhjK60/AxULWsWlwu4MLZ/IdzMkslivmFSSVVtp
	Tg5nZZGJ4NCRyVPmVITrkKxeauzLwc3eppCyRk7kkyLfRl+ZUBxdT21Ql5V1
	37Qh9Up6vHWq8nm1sMbYpJOk30677J1IZDMOLQyOKs1eXuc3RXoDG2UjiHjh
	ZV6V+oZcpZO2tGTFBoU7WHcOBhBvup2H9gmLo0SAUdvRO9al1sZvAo8Mb7Fq
	KTMW6HbWFYy0VRJegsmz/jb1Bf4aJ//InX0Ov4H5QReCieZkzn+u86SpT5AS
	3rfFZ1YJBj5D1rnVB6YAG45tbUI8HTwhnY9LLCTGGawY6j21GU/Q0bEmaBa5
	X4IEvjC2qfbB74PtqqRKNNVQbVG6dThsQ8WyXltqlk8WPFpFzIvPXUrcUtpb
	U62Wg8AYyda7d2SUfXDaIB/jVOCLcBTGFd9As0Mu0Ieef1iDmy4FIAtw+tyU
	wVo5gOMfvZMsFAI5MzWTnE91O7+1Yf3BdbV6gOCu4JL4sBTLbOnDmhZU1F9/
	MF7BncIkkgcDt4TDiQ+wtV9Fm2YB/zL8bbLYTKur7FDwWV8UZ/xTsTT3Lewy
	RPHAeZMHXI6IfMv/Zk2nBm7NxkHxmid5kL9l9wOncWr6QCwU2FwyDADDVMne
	riBnbz2656gUP6my6FtXBrRWkY8v/RbrunEQeHbCURdHwMqNtvhqwlVL+JWc
	pMoVFiyEsIvdEYRFgdDUl4VzuwyoyO01tVPSISuxklsnSOI5M906ouI5a/8W
	o++bAl5QJgkDBLIQ8jabnNhGk218Fx3ovXhJMR9/78UbZuB7NpQxFR/eiyOu
	X1lwF/29F6FFBhrfY5n9vvtzn/abK9HH9t/++/Y3ouYAgJF4915cHR7t0k6U
	1rlNg8N+RFf7yHXYWIlMzyEh3DLPhmGZIS/zbLhpmWfDe5cZPt0Lyzymd6le
	c3cZXP34MqEosbG8EZcoJsmHABQOR7ZM4jIyqo0KX/8RJ+3ywJumPAAde+1w
	TrdTwssUGcIfbi6NqqdFP1xq8k+AIZfDB0BwN9EA4CA9acDvrU5TsWJLjypO
	TaIbHwSZHyFDPkOUK8fIk3OgaHmbeEzUjMoGumpnbC6XRWBMlDGUONp8qifu
	2ZGAoC5qEyfRbptARVKXfI6IDk+BaBEQny5IaOmaiO54YZHf2a/ubuMVQi+K
	CvshZO8NHoeQTZMPCNnep3EaAcRVcIobobw7tQquK93dUZLnMmuBmABYLrOJ
	ntc0MwJ4U6qsuFEx1QFocFlBJ+RTQGTQVGTz5lem87QqwXXO2mVZUqfF17Eq
	f4/isT8Okg1bhciJb5Toc+JjU7gbVVKEEA85sLArLO3avtzok0aQDR5lBK4I
	1Ze26+hdaZQQGFuM8TCJKIaVGKmnXH5vlfhZajS78uFDz+bMPuuoqyIL5Z5M
	5nLOoJEoC0W2KHsAaXMqYZA4oLmgr1xTu1CzuQ+gBThsBSOTazpowhVG2ysE
	hXDi9DgHM+xTIPLpWcwk1rsNAeZzMewnUfLhiE1gA0y+F4hvRMlUIv6bweTD
	URsmgz//X2AyjrIOkyfJL4HJ1MD+vwKTY1r/AZM/CZO9bjiYvBElQ1l+OUpu
	ycGj5H+A5M8ByWAdw9Inm0AyTdx+Hkj2yzzdBJLdMp8Bkv0ye5tAsl3mkyC5
	HSMIOBg9dX0eUrPGc9HzrESpnpSyDF0FV//11TSP0BvvbQtXgI1LKNdB8J7t
	cRI/MkITI5LiBLU52WBKhXCSM/LgQElxsshV04bNi7zPUxiJQz1qQx9RUPfO
	qJRN1YO1FgSXtl9QNkFevV1S3Y0d2MERDMO2ZLzBWwfBEJbjxryUXOpqDYMA
	5ZEl4tVpIUzh+qU8rHeX10AoDa/5Ga7a0jypa2Z6A0ScfWtNOtot8g9RjckO
	ZgVkkUfeoDHxMDj47h3t68KUDd9NgdmHnk9szu6VIzPhhm7n3bs4pf/A+uCu
	OQfGzfzUFD3egqYtaAusSGrmWsBbI7mUE51yqXMLwk7rLKdBDCo/k+iBxMXW
	v3+P0PbDlnXOW8j48jnPxwF4kXC3uJq+6cWT4/ELN3XCr14qzq8S9ZGtEPxF
	6Z+x9dH1vjgcNhVCe4Fn1tnaNI7igLGzd14o/b2nTx8/obX6w71dURLtTmHC
	JOUdpTEqaXTmYzNnmybLeEQUQvSTWOTlofXroEatTXk18MfiHTflZfM7312D
	3+92XErm7nCf1Y6u0wmNm3Gt/TCVm2JqIgOr7RoSjTVrsrpvvAu5bWZnrpoD
	MC8DkHRzH95fN81U6tXMZTlNkef6vJLKAlgKzrBYqWkvOhhnrE1ib1uUMdcm
	FJCoVz+lkZB8XmuzYJ/A/QVbG/CaIWdk28Mf95647JqlElLgbseKQBAmTLlr
	tAHmez21uu97iDappjxTJgubv3qJWFv38Zs7MX3ycgUUn9Q9AfCl6v6mdIKG
	G3yXjqoV3Nag5SnxKknCTHI8iWC56eoJboat12qF4X2alXMLZLWp2B/7bDzu
	8sQq7X2WGwecSV36ogvccrsn6TIzMHguKUNhpxM3tEEAD+3Y2EC4ilrwSlV9
	nfdBbN8Ogbp1wjKO3dYOjL9tiO9Nl58b5T6zMopHf20NY1GTyEg9WPXiTmeY
	rnRacJ3TCFq7M2qvuX7dgTF1ZiXtKkyZghzsVCXkS3Uc6g0iAnL71SqbvJE6
	tfpJrngz21hcuetZK8iWLDS10x8Man2dYn3YFhtETmD448P80XDbjWZZB+AH
	PLqdvM4msAYsxQMWzkkG5vosn4Y3Qv5OT0xowNI1/V2XkmP3ZgVYaxjbmYm4
	28sVwdA0poYW5VZrvWLRbhUjs+bi1Y0Cu32vONPGWgoPKTVTWXY+pTWlEPwB
	Wf8NKSMTRxJpW1JcG1zrJ0cyCi1m35T2EcgPu/oRHx7CDWuaJhyuD+bOayQ5
	eMjS2O2Q5/B9R9K2Bc1O5lzTiEqbIP+P55dmE02O/tuiqWxG1TXzr2JMMJPY
	h0ei+RwuzdohENLgi92euBjiv8dM+it8fYWvrx7zT9Hs+ZohFGtHDQ3f4PFv
	8Pg3jwesYbQXd1/NsuD5hbiOySfnpPrnn3/mSf+HF7tc+Pxmd7uHL0P7Zchf
	Htsvj7fpBXr2Vfzsq/jZV9GzvDSQxMySHjAvU9Y4B0u/05e3xCdXrQsFKKcN
	kn/L17Rl4SNTbnffGX9AEDR1SjpgKGJ+7KD8b3QY8Xvhbr7adc+Gs7lnm+94
	1n55NXTPhqO7Z5vvvxfuJsnSseWcoddChVO63r7VsJamGHqXuTJXFQ9kWAst
	Vco/Zkrt7JrU80UFM7ulwVOCKYqyeTuLl4XCnqvJ5Kv2pFPPFRFYUULnPTKv
	NYqoCFhuNAY727FWYaYTH7lfQMzJsUQN/VZItE7liktaWUHlN9l0FWgknLnF
	5X0DZ5zK0vf3IxLs7Iab/HTTJTfOV8n14AOw1zLE2A5bY18ft7jGXcFUvTip
	aFoqbJOszwHxQi4NpDMROcmiKEgyNj60eg7a/BpLdWp2FWuYm/FjPwYg5jLK
	5uSNy9k4jEictkraJshZUERY5BciCiMHEZHa0PotY3kd+Vi5dnS/1YUzXssD
	v9WFM1PLDL/VhTPImCtHaq1dFXjUb+BwdPCoeQXQR9NSiPiu3tSwl8RLtZuN
	3LmIneVF7CwvIsL+nov17RoXmVIenR0a5YoFVA9cWqZ+Xi2e2Zi3nWFsPbpt
	MnhOl9ZoHBbtEdDILbakU5CF+x9ftbtcBBtqSv+Q/eYEcR30tamXPw8XXKiF
	08omf/lvhtqNq3MGSqVBwpCvFZzyqOKkjf9pjpcv09LOYHyi9MkuAntGZEZc
	PPZQkgfcvGaQAyCJLaNW5GdOM/3O+mS3omkphJ1ASykPcpK4drNYSGiurWsJ
	42m0ehHaBU1/OMx4hxDh2txRRkf5ueeG7eJG3HB9BN8DDcP0dKpQ9Q192FIm
	UOGbOiUX4Ms1EKj/IaYrLX3r4Wrzy1Ji3N+gpNUy7fWI4kqam3dcMxjqeDZ3
	rSnkvbWIlRGA4OKOs2T63dayTv08fzsSIM6X0MMia4a649lzO2qehKyylVeH
	jOCuosU/WmvVPPqj0Zk1LvrRtivF0fUXfN39MhvX41k6bqQFu7WW1OKnAaNc
	o2cTI6NGcEgo8sbD3fGRlZzz9PtqCd34pCn1bHIeOvKBsvt4b5u6v/AYbI2e
	Wf5MhyMwZF67UtHuHrdz+HOUmVNMqHSm7PHZnohe/oWFfZdUDbJvGxH/sMj/
	8sbCLzfZkpB3TtXU9rMNXT0jOEp54TX/iPpIwqeJw5JcPAkQyDb8ljZ090Pl
	vGn2sHsLJf22t3aGxr9Q9D9HhBm0dyaMGrYGb04AL7U41bW5kYDSuDJOiqoS
	B2WizU/q1lxrXPu3YpGLC2DO//4PrFdVxv5W4lTWtr56Ck87SeWUBoEvZJ2K
	bxGjYIX4elmAFpw3X6X6tmfVn5cbJ/V06mcMiHAaRlG3TgWLmpB+nQrbLqqo
	EPA/VAZazptFAAA=



		<section anchor="acknowledgements" numbered="false">
		<name>Acknowledgements</name>
		<t>Many thanks to <contact fullname="David Brown"/> for raising the need f
		or non-AEAD algorithms
		to support encryption within the SUIT manifest. Many thanks to
		<contact fullname="Ilari Liusvaara"/>,
		<contact fullname="Scott Arciszewski"/>,
		<contact fullname="John Preuß Mattsson"/>,
		<contact fullname="Laurence Lundblade"/>,
		<contact fullname="Paul Wouters"/>,
		<contact fullname="Roman Danyliw"/>,
		<contact fullname="Sophie Schmieg"/>, <contact fullname="Stephen Farrell"/>, <co
		ntact fullname="Carsten Bormann"/>, <contact fullname="Scott Fluhrer"/>, <contac
		t fullname="Brendan Moran"/>, and
		<contact fullname="John Scudder"/>
		for the review and thoughtful comments.</t>
		</section>
		</back>
	</rfc>	</rfc>

End of changes. 65 change blocks.
	439 lines changed or deleted	186 lines changed or added
This html diff was produced by rfcdiff 1.48.