<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!-- draft submitted in xml v3 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!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) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-cose-aes-ctr-and-cbc-06" number="9459" submissionType="IETF" category="std" consensus="true"submissionType="IETF"tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 3.17.1 --> <front> <title abbrev="AES-CTR and AES-CBC with COSE">CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC</title> <seriesInfoname="Internet-Draft" value="draft-ietf-cose-aes-ctr-and-cbc-06"/>name="RFC" value="9459"/> <author initials="R." surname="Housley" fullname="Russ Housley"> <organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <email>housley@vigilsec.com</email> </address> </author> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig"><organization>Arm Limited</organization><address><email>hannes.tschofenig@arm.com</email><email>hannes.tschofenig@gmx.net</email> </address> </author> <date year="2023"month="May" day="25"/> <area>Security</area> <workgroup>COSE</workgroup> <keyword>Internet-Draft</keyword>month="September"/> <area>sec</area> <workgroup>cose</workgroup> <abstract> <t>The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC asContent Encryptioncontent encryption algorithms with COSE.</t> </abstract> </front> <middle> <section anchor="intro"> <name>Introduction</name> <t>This document specifies the conventions for using AES-CTR and AES-CBC asContent Encryptioncontent encryption algorithms with the CBOR Object Signing and Encryption (COSE) <xref target="RFC9052"/> syntax.EncryptionToday, encryption with COSEtodayuses Authenticated Encryption with Associated Data (AEAD) algorithms <xreftarget="RFC5116"/> algorithms,target="RFC5116"/>, which provide both confidentiality and integrity protection. However, there are situations where another mechanism, such as a digital signature, is used to provide 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 example where a digital signature is always present.</t> </section> <section anchor="conventions-and-terminology"> <name>Conventions and Terminology</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="aes-alg"> <name>AES Modes of Operation</name> <t>NIST has defined several modes of operation for the Advanced Encryption Standard(AES)<xref target="AES"/> <xref target="MODES"/>. AES supports three key sizes: 128 bits, 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: CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter).</t> <t>Only AES Countermode(AES-CTR) mode and AES Cipher Block Chaining (AES-CBC) are discussed in this document.</t> </section> <section anchor="aes-ctr"> <name>AES Counter Mode</name> <t>When AES-CTR is used as a COSEContent Encryptioncontent encryption algorithm, the encryptor generates a unique value that is communicated to the decryptor. This value is called aninitialization vector (IV)"Initialization Vector" (or "IV") in this document. The same IV and AES key combination <bcp14>MUST NOT</bcp14> be used more 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> <t>When using AES-CTR, each AES encrypt operation generates 128 bits of key 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 ciphertext. If the generated key stream is longer than the plaintext or 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 block size.</t> <t>AES-CTR has many properties that make it an attractive COSEContent Encryptioncontent encryption 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 encrypting sequential IV block values, calledcounter blocks. The"counter blocks", where:</t> <ul><li>The first block of the key stream is the AES encryption of theIV, theIV.</li> <li>The second block of the key stream is the AES encryption of (IV + 1) mod2^128, the2<sup>128</sup>.</li> <li>The third block of the key stream is the AES encryption of (IV + 2) mod2^128,2<sup>128</sup>, and soon. AES-CTRon.</li></ul><t>AES-CTR is easy to implement,and AES-CTRcan be pipelined andparallelized. AES-CTR alsoparallelized, 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> <t>When used correctly, AES-CTR provides a high level of confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. Being a stream cipher, reuse of the IV with the same key is catastrophic. An IV collision immediately leaks information about the plaintext. For this reason, it is inappropriate to use AES-CTR with static keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, 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 recipient structure. Implementations encrypting and decrypting <bcp14>MUST</bcp14> validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.</t> <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 use AES-CTR without a companion authentication and integrity mechanism. Implementations <bcp14>MUST</bcp14> use AES-CTR in conjunction with an authentication and integrity mechanism, such as a digital signature.</t> <t>The instructions inSection 5.4 of<xreftarget="RFC9052"/>target="RFC9052" sectionFormat="of" section="5.4"/> are followed for AES-CTR. Since AES-CTR cannot provide integrity protection for external additional authenticated data, the decryptor <bcp14>MUST</bcp14> ensure that no external additional authenticated data was supplied. See <xref target="impl-cons"/>.</t> <t>The 'protected' header <bcp14>MUST</bcp14> be a zero-length byte string.</t> <section anchor="aes-ctr-key"> <name>AES-CTR COSE Key</name> <t>When using a COSE key for the AES-CTR algorithm, the following checks are made:</t> <ul spacing="normal"> <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 AES-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 'decrypt' when decrypting.</li> </ul><t>In addition, the 'protected' header parameters encoded value <bcp14>MUST</bcp14> be a zero-length byte string.</t></section> <section anchor="aes-ctr-alg"> <name>AES-CTR COSE Algorithm Identifiers</name> <t>The following table defines the COSE AES-CTR algorithm values. Note that these algorithms are being registered as "Deprecated" to avoid accidental use without a companion integrity protection mechanism.</t> <table> <thead> <tr> <th align="left">Name</th> <th align="center">Value</th> <th align="center">Key Size</th> <th align="center">Description</th> <th align="right">Recommended</th> </tr> </thead> <tbody> <tr> <td align="left">A128CTR</td> <tdalign="center">TBD1</td>align="center">-65534</td> <td align="center">128</td> <td align="center">AES-CTR w/ 128-bit key</td> <td align="right">Deprecated</td> </tr> <tr> <td align="left">A192CTR</td> <tdalign="center">TBD2</td>align="center">-65533</td> <td align="center">192</td> <td align="center">AES-CTR w/ 192-bit key</td> <td align="right">Deprecated</td> </tr> <tr> <td align="left">A256CTR</td> <tdalign="center">TBD3</td>align="center">-65532</td> <td align="center">256</td> <td align="center">AES-CTR w/ 256-bit key</td> <td align="right">Deprecated</td> </tr> </tbody> </table> </section> </section> <section anchor="aes-cbc"> <name>AES Cipher Block Chaining Mode</name> <t>AES-CBC mode requiresan 16 octet Initialization Vector (IV).a 16-octet IV. Use of a randomly orpseudo-randomlypseudorandomly generated IV ensures that the encryption of the same plaintext will yield different ciphertext.</t> <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 the previous ciphertext block with the current plaintext before it is encrypted.</t> <t>AES-CBC requires padding of the plaintext; the padding algorithm specified inSection 6.3 of<xreftarget="RFC5652"/>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 remove the padding.</t> <t>The simplicity of AES-CBC makes it an attractive COSEContent Encryptioncontent encryption 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 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 preferred.</t> <t>AES-CBC does not provide integrity protection. Thus, an attacker can introduce undetectable errors if AES-CBC is used without a companion authentication and integrity mechanism. Implementations <bcp14>MUST</bcp14> use AES-CBC in conjunction with an authentication and integrity mechanism, such as a digital signature.</t> <t>The instructions inSection 5.4 of<xreftarget="RFC9052"/>target="RFC9052" sectionFormat="of" section="5.4"/> are followed for AES-CBC. Since AES-CBC cannot provide integrity protection for external additional authenticated data, the decryptor <bcp14>MUST</bcp14> ensure that no external additional authenticated data was supplied. See <xref target="impl-cons"/>.</t> <t>The 'protected' header <bcp14>MUST</bcp14> be a zero-length byte string.</t> <section anchor="aes-cbc-key"> <name>AES-CBC COSE Key</name> <t>When using a COSE key for the AES-CBC algorithm, the following checks are made:</t> <ul spacing="normal"> <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 AES-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 'decrypt' when decrypting.</li> </ul><t>In addition, the 'protected' header parameters encoded value <bcp14>MUST</bcp14> be a zero-length byte string.</t></section> <section anchor="aes-cbc-alg"> <name>AES-CBC COSEAlgoritmAlgorithm Identifiers</name> <t>The following table defines the COSE AES-CBC algorithm values. Note that these algorithms are being registered as "Deprecated" to avoid accidental use without a companion integrity protection mechanism.</t> <table> <thead> <tr> <th align="left">Name</th> <th align="center">Value</th> <th align="center">Key Size</th> <th align="center">Description</th> <th align="right">Recommended</th> </tr> </thead> <tbody> <tr> <td align="left">A128CBC</td> <tdalign="center">TBD4</td>align="center">-65531</td> <td align="center">128</td> <td align="center">AES-CBC w/ 128-bit key</td> <td align="right">Deprecated</td> </tr> <tr> <td align="left">A192CBC</td> <tdalign="center">TBD5</td>align="center">-65530</td> <td align="center">192</td> <td align="center">AES-CBC w/ 192-bit key</td> <td align="right">Deprecated</td> </tr> <tr> <td align="left">A256CBC</td> <tdalign="center">TBD6</td>align="center">-65529</td> <td align="center">256</td> <td align="center">AES-CBC w/ 256-bit key</td> <td align="right">Deprecated</td> </tr> </tbody> </table> </section> </section> <section anchor="impl-cons"> <name>Implementation Considerations</name> <t>COSE libraries that support either AES-CTR or AES-CBC and accept Additional Authenticated Data (AAD) as input <bcp14>MUST</bcp14> return an error if one of these non-AEAD content encryptionalgorithmalgorithms is selected. This ensures that a caller does not expect the AAD to be protected when the cryptographic algorithm is unable to do so.</t> </section> <section anchor="iana-cons"> <name>IANA Considerations</name> <t>IANAis requested to registerhas registered six COSE algorithm identifiers for AES-CTR and AES-CBC in theCOSE Algorithms Registry"COSE Algorithms" registry <xreftarget="IANA"/>.</t>target="IANA-COSE"/>.</t> <t>The information for the six COSE algorithm identifiers is provided in Sections <xreftarget="aes-ctr-alg"/>target="aes-ctr-alg" format="counter"/> and <xreftarget="aes-cbc-alg"/>.target="aes-cbc-alg" format="counter"/>. Also, for all six entries, the "Capabilities" columnshould containcontains "[kty]", the "Change Controller" columnshould contain "IESG",contains "IETF", and the "Reference" columnshould containcontains a reference to this document.</t><t>Ideally, the six values will be assigned in the -65534 to -261 range.</t></section> <section anchor="sec-cons"> <name>Security Considerations</name> <t>This document specifies AES-CTR and AES-CBC for COSE, which are notauthenticated encryption with additional data (AEAD)AEAD ciphers. The use of the ciphers is limited to special usecasescases, such as firmware encryption, where integrity and authentication is provided by anothermechanism, such as firmware encryption.</t>mechanism.</t> <t>Since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after2^642<sup>64</sup> blocks are encrypted with a single key. Implementations should change the key before reaching this limit.</t> <t>To avoid cross-protocol concerns, implementations <bcp14>MUST NOT</bcp14> use the same keying material with more than one mode. For example, the same keying material must not be used with AES-CTR and AES-CBC.</t> <t>There are fairly generic precomputation attacks against all block cipher 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 with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES-CTR and AES-CBCareis limited to2^(n/2)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 to precomputation attacks.</t> <t>When used properly, AES-CTR mode provides strong confidentiality. Unfortunately, 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 will be used to encrypt both plaintexts, and the confidentiality guarantees are voided.</t> <t>What happens if the encryptor XORs the same key stream with two different 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 ciphertexts are:</t> <artwork><![CDATA[ (P1 XOR K1), (P2 XOR K2), (P3 XOR K3) (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3) ]]></artwork> <t>If both of these two ciphertext streams are exposed to an attacker, then a catastrophic failure of confidentiality results, since:</t> <artwork><![CDATA[ (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1 (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2 (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3 ]]></artwork> <t>Once the attacker obtains the two plaintexts XORed together, it is relatively straightforward to separate them. Thus, using any stream cipher, including AES-CTR, to encrypt two plaintexts under the same key stream leaks the plaintext.</t> <t>Data forgery is trivial with AES-CTR mode. The demonstration of this attack 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 attacker can replace the plaintext with one ofhisits own choosing. The ciphertext is:</t> <artwork><![CDATA[ (P1 XOR K1), (P2 XOR K2), (P3 XOR K3) ]]></artwork> <t>The attacker simply XORs a selected sequence Q1, Q2, Q3 with the ciphertext to obtain:</t> <artwork><![CDATA[ (Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3)) ]]></artwork> <t>Which is the same as:</t> <artwork><![CDATA[ ((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3) ]]></artwork> <t>Decryption of the attacker-generated ciphertext will yield exactly what the attacker intended:</t> <artwork><![CDATA[ (Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3) ]]></artwork> <t>AES-CBC does not provide integrity protection. Thus, an attacker can introduce undetectable errors if AES-CBC is used without a companion authentication mechanism.</t> <t>If an attacker is able to strip the authentication and integrity mechanism, 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 an Authenticated Encryption with Associated Data (AEAD) algorithm <xreftarget="RFC5116"/> algorithm.target="RFC5116"/>. Of course, neither AES-CTR nor AES-CBC is an AEAD. Thus, an implementation should provide integrity protection for thekid'kid' field to prevent undetected stripping of the authentication and integrity mechanism; this prevents an attacker from altering thekid'kid' to trick the recipient into using a different key.</t> <t>With AES-CBC mode, implementers should perform integrity checks prior to decryption to avoid padding oracle vulnerabilities <xref target="Vaudenay"/>.</t> <t>With the assignment of COSE algorithm identifiers for AES-CTR and AES-CBC in the COSE Algorithms Registry, an attacker can replace the COSE algorithm identifiers with one of these identifiers. Then, the attacker might be able to manipulate the ciphertext to learn some of the plaintext or extract the keying material used for authentication and integrity.</t> <t>Since AES-CCM <xref target="RFC3610"/> and AES-GCM <xref target="GCMMODE"/> use AES-CTR for encryption, an attacker can switch the algorithm identifier toAES-CTR,AES-CTR and then strip the authentication tag to bypass the authentication and integrity, allowing the attacker to manipulate the ciphertext.</t> <t>An attacker can switch the algorithm identifier from AES-GCM to AES-CBC,guess ofguessing 16 bytes of plaintext at a time, andchecking each guess with padding oracle as discussed above.</t> </section> <section anchor="acknowledgements"> <name>Acknowledgements</name> <t>Many thanks to David Brown for raising the need for non-AEAD algorithms to support encryption withinsee if theSUIT manifest. Many thanks to David Brown, Ilari Liusvaara, Scott Arciszewski, John Preuß Mattsson, Laurence Lundblade, Paul Wouters, Roman Danyliw, and John Scudder forrecipient accepts thereview and thoughtful comments.</t>padding. Padding oracle vulnerabilities are discussed further in <xref target="Vaudenay" format="default"/>.</t> </section> </middle> <back> <displayreference target="I-D.ietf-suit-manifest" to="SUIT-MANIFEST"/> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"> <organization/> </author> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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/rfc8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <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 protocol specifications. This document aims to reduce the ambiguity by clarifying that 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/rfc4107"> <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 requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. 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="107"/> <seriesInfo name="RFC" value="4107"/> <seriesInfo name="DOI" value="10.17487/RFC4107"/> </reference> <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652"> <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 arbitrary 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/rfc9052"> <front> <title>CBOR Object Signing and Encryption (COSE): Structures and Process</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 designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4107.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/> <reference anchor="AES"> <front> <title>Advanced Encryption Standard (AES)</title> <author> <organization>National Institute of Standards and Technology (NIST)</organization> </author> <dateyear="2001" month="November"/>year="2023" month="May"/> </front> <seriesInfoname="FIPS Publication"name="NIST FIPS" value="197"/> <seriesInfo name='DOI' value="10.6028/NIST.FIPS.197-upd1" /> </reference> <reference anchor="MODES"> <front> <title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title> <author initials="M." surname="Dworkin" fullname="Morris Dworkin"> <organization>National Institute of Standards and Technology (NIST)</organization> </author> <date year="2001" month="December"/> </front> <seriesInfo name="NIST Special Publication" value="800-38A"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A "/> </reference> </references> <references> <name>Informative References</name><reference anchor="RFC3610" target="https://www.rfc-editor.org/info/rfc3610"> <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 encryption 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/rfc5116"> <front> <title>An Interface and Algorithms for Authenticated Encryption</title> <author fullname="D. McGrew" initials="D." surname="McGrew"> <organization/> </author> <date month="January" year="2008"/> <abstract> <t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5116"/> <seriesInfo name="DOI" value="10.17487/RFC5116"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"/> <!-- [I-D.ietf-suit-manifest] IESG state AD Evaluation::Revised I-D Needed - Used 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 Format 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="O."initials="Ø." surname="Rønningstad"> <organization>Nordic Semiconductor</organization> </author> <date day="27" month="February" year="2023"/><abstract> <t> This specification describes the format of a manifest. A manifest 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> </abstract></front> <seriesInfo name="Internet-Draft" value="draft-ietf-suit-manifest-22"/> </reference> <reference anchor="GCMMODE"> <front> <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title> <author initials="M." surname="Dworkin" fullname="Morris Dworkin"> <organization>National Institute of Standards and Technology (NIST)</organization> </author> <date year="2007" month="November"/> </front> <seriesInfo name="NIST Special Publication" value="800-38D"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D "/> </reference> <referenceanchor="IANA" target="https://www.iana.org/assignments/cose/cose.xhtml">anchor="IANA-COSE" target="https://www.iana.org/assignments/cose"> <front><title>IANA Registry for CBOR<title>CBOR Object Signing and Encryption (COSE)</title> <author><organization/><organization>IANA</organization> </author><date>n.d.</date></front> </reference> <reference anchor="Vaudenay" target="https://www.iacr.org/cryptodb/archive/2002/EUROCRYPT/2850/2850.pdf"> <front> <title>Security Flaws Induced by CBC Padding -- Applications to SSL, IPSEC, WTLS...</title> <author initials="S." surname="Vaudenay" fullname="Serge Vaudenay"> <organization>Swiss Federal Institute of Technology (EPFL)</organization> </author> <date year="2002"/> </front> <seriesInfo name="EUROCRYPT" value="2002"/> </reference> </references> </references> <section anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>Many thanks to <contact fullname="David Brown"/> for raising the need for 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"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Scott Fluhrer"/>, <contact fullname="Brendan Moran"/>, and <contact fullname="John Scudder"/> for the review and thoughtful comments.</t> </section> </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= --></rfc>