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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?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&nbsp;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.