<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.12 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>
<?rfc toc_levels="4"?>

<rfc ipr="trust200902" docName="draft-moran-suit-mti-01" category="std">

  <front>
    <title abbrev="MTI SUIT Algorithms">Mandatory-to-Implement Algorithms for Creators and Consumers of Software Update for the Internet of Things manifests</title>

    <author initials="B." surname="Moran" fullname="Brendan Moran">
      <organization>Arm Limited</organization>
      <address>
        <email>brendan.moran.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2022" month="July" day="27"/>

    <area>Security</area>
    <workgroup>SUIT</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document specifies algorithm profiles for SUIT manifest parsers and authors to ensure better interoperability.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t>Mandatory algorithms may change over time due to an evolving threat landscape. Algorithms are grouped into algorithm profiles to account for this. Profiles may be deprecated over time. SUIT will define three choices of MTI profile:</t>

<t><list style="symbols">
  <t>One Symmetric MTI profile</t>
  <t>One "Current" Asymmetric MTI profile</t>
  <t>One "Future" Asymmetric MTI profile</t>
</list></t>

<t>Devices MAY choose which MTI profile they wish to implement. It is RECOMMENDED thaty they implement the "Future" Asymmetric MTI profile.</t>

<t>Devices MAY implement any number of other profiles.</t>

<t>MTI algorithms must be FIPS qualified.</t>

</section>
<section anchor="algorithms"><name>Algorithms</name>

<t>The algorithms that form a part of the profiles defined in this document are grouped into:</t>

<t><list style="symbols">
  <t>Digest Algorithms</t>
  <t>Authentication Algorithms</t>
  <t>Key Exchange Algorithms</t>
  <t>Encryption Algorithms</t>
</list></t>

<section anchor="digest-algorithms"><name>Digest Algorithms</name>

<t><list style="symbols">
  <t>SHA-256 (-16)</t>
  <t>SHAKE128 (-18)</t>
  <t>SHA-384 (-43)</t>
  <t>SHA-512 (-44)</t>
  <t>SHAKE256 (-45)</t>
</list></t>

</section>
<section anchor="authentication-algorithms"><name>Authentication Algorithms</name>

<t>Authentication Algorithms are divided into three categories:</t>

<section anchor="symmetric-authentication-algorithm"><name>Symmetric Authentication Algorithm</name>

<t><list style="symbols">
  <t>HMAC-256 (5)</t>
  <t>HMAC-384 (6)</t>
  <t>HMAC-512 (7)</t>
</list></t>

</section>
<section anchor="asymmetric-classical-authentication-algorithms"><name>Asymmetric Classical Authentication Algorithms</name>

<t><list style="symbols">
  <t>ES256 (-7)</t>
  <t>EdDSA (-8)</t>
  <t>ES384 (-35)</t>
  <t>ES512 (-36)</t>
</list></t>

</section>
<section anchor="asymmetric-post-quantum-authentication-algorithms"><name>Asymmetric Post-Quantum Authentication Algorithms</name>

<t><list style="symbols">
  <t>HSS-LMS (-46) <xref target="RFC8778"/></t>
  <t>XMSS (TBD)</t>
  <t>Falcon-512 (TBD)</t>
  <t>SPHINCS+ (TBD)</t>
  <t>Crystals-Dilithium (TBD)</t>
</list></t>

</section>
</section>
<section anchor="key-exchange-algorithms"><name>Key Exchange Algorithms</name>

<t>Key Exchange Algorithms are divided into two three groups: Symmetric, Classical Asymmetric, and Post-Quantum Asymmetric</t>

<section anchor="symmetric"><name>Symmetric</name>

<t><list style="symbols">
  <t>A128 (-3)</t>
  <t>A192 (-4)</t>
  <t>A256 (-5)</t>
</list></t>

</section>
<section anchor="classical-asymmetric"><name>Classical Asymmetric</name>

<t><list style="symbols">
  <t>HPKE (TBD)</t>
  <t>ECDH-ES + HKDF-256 (-25)</t>
  <t>ECDH-ES + HKDF-512 (-26)</t>
  <t>ECDH-ES + A128KW (-29)</t>
  <t>ECDH-ES + A192KW (-30)</t>
  <t>ECDH-ES + A256KW (-31)</t>
</list></t>

</section>
<section anchor="post-quantum-asymmetric"><name>Post-Quantum Asymmetric</name>

<t><list style="symbols">
  <t>CRYSTALS-KYBER (TBD)</t>
</list></t>

</section>
</section>
<section anchor="encryption-algorithms"><name>Encryption Algorithms</name>

<t><list style="symbols">
  <t>A128GCM (1)</t>
  <t>A192GCM (2)</t>
  <t>A256GCM (3)</t>
  <t>ChaCha20/Poly1305 (24)</t>
  <t>AES-MAC 128/128 (25)</t>
  <t>AES-MAC 256/128 (26)</t>
  <t>AES-CCM-16-128-128 (30)</t>
  <t>AES-CCM-16-128-256 (31)</t>
  <t>AES-CCM-64-128-128 (32)</t>
  <t>AES-CCM-64-128-256 (33)</t>
</list></t>

</section>
</section>
<section anchor="profiles"><name>Profiles</name>

<t>Recognized profiles are defined below.</t>

<section anchor="symmetric-mti-profile-suit-sha256-hmac-a128-ccm"><name> Symmetric MTI profile: suit-sha256-hmac-a128-ccm</name>

<t>This profile requires the following algorithms:</t>

<t><list style="symbols">
  <t>SHA-256</t>
  <t>HMAC-256</t>
  <t>A128W Key Wrap</t>
  <t>AES-CCM-16-128-128</t>
</list></t>

</section>
<section anchor="current-asymmetric-mti-profile-suit-sha256-es256-hpke-a128gcm"><name>Current Asymmetric MTI Profile: suit-sha256-es256-hpke-a128gcm</name>

<t>This profile requires the following algorithms:</t>

<t><list style="symbols">
  <t>SHA-256</t>
  <t>ES256</t>
  <t>HPKE</t>
  <t>AES-128-GCM</t>
</list></t>

</section>
<section anchor="future-asymmetric-mti-profile-suit-sha256-hsslms-hpke-a128gcm"><name>Future Asymmetric MTI Profile: suit-sha256-hsslms-hpke-a128gcm</name>

<t>This profile requires the following algorithms:</t>

<t><list style="symbols">
  <t>SHA-256</t>
  <t>HSS-LMS</t>
  <t>HPKE</t>
  <t>AES-128-GCM</t>
</list></t>

</section>
<section anchor="other-profiles"><name>Other Profiles:</name>

<t>Optional classical and PQC profiles are defined below.</t>

<t><list style="symbols">
  <t>suit-sha256-eddsa-ecdh-es-chacha-poly
  <list style="symbols">
      <t>SHA-256</t>
      <t>EdDSA</t>
      <t>ECDH-ES + HKDF-256</t>
      <t>ChaCha20 + Poly1305</t>
    </list></t>
  <t>suit-sha256-falcon512-hpke-a128gcm
  <list style="symbols">
      <t>SHA-256</t>
      <t>HSS-LMS</t>
      <t>HPKE</t>
      <t>AES-128-GCM</t>
    </list></t>
  <t>suit-shake256-dilithium-kyber-a128gcm
  <list style="symbols">
      <t>SHAKE256</t>
      <t>Crystals-Dilithium</t>
      <t>Crystal-Kyber</t>
      <t>AES-128GCM</t>
    </list></t>
</list></t>

</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>TODO</t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>TODO</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC8152' target='https://www.rfc-editor.org/info/rfc8152'>
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author fullname='J. Schaad' initials='J.' surname='Schaad'><organization/></author>
<date month='July' year='2017'/>
<abstract><t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined 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></abstract>
</front>
<seriesInfo name='RFC' value='8152'/>
<seriesInfo name='DOI' value='10.17487/RFC8152'/>
</reference>



<reference anchor='RFC8778' target='https://www.rfc-editor.org/info/rfc8778'>
<front>
<title>Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)</title>
<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></author>
<date month='April' year='2020'/>
<abstract><t>This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.</t></abstract>
</front>
<seriesInfo name='RFC' value='8778'/>
<seriesInfo name='DOI' value='10.17487/RFC8778'/>
</reference>




    </references>

    <references title='Informative References'>




<reference anchor='I-D.ietf-suit-manifest'>
   <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'>
	 <organization>Arm Limited</organization>
      </author>
      <author fullname='Hannes Tschofenig'>
	 <organization>Arm Limited</organization>
      </author>
      <author fullname='Henk Birkholz'>
	 <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname='Koen Zandberg'>
	 <organization>Inria</organization>
      </author>
      <date day='11' month='July' year='2022'/>
      <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-18'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-suit-manifest-18.txt' type='TXT'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAP604WIAA61XUVPbOBB+96/QlJdCTylJSIA8XXDCkQkpFNPp9amj2Eqi
wbZcSQ71dfpf7rfcL7tdyXackHA3c8cwjKVd7a6+/XZXUEo9I0zMB2TG0ogZ
qQpqJJ0kWcwTnhoyjJdSCbNKNFlIRXzFUUkT0Ca+THWecFjJBQnkwjwzxcmn
DOxwq21WnExSw1XKDeo8rkS61CRhqVhwbbTH5nPF1+D8cUKCT5PHhjsvkmHK
EogsUmxhaCIVS6nOBXwaQU/bXghuQLsYEG0izwPfbEACHuZgoPCepXpaKpln
A2vZe+IFbEWDOiA6QrueJzI1IEbl2nROTy9PO54Xwr04XE0PSCo9Txu47FcW
yxSCKbj2MjHwCFGLkEfaFHG5S4iRYeNTpBEAWG1oqYziC12vi2RraZQIa+VQ
Jgh+LRVpLNKNG/7d0FhoQ8HIXMagRuXJO5AAZAnLMgC5EcfXmK85Kp0BRrlZ
SQXRU5Dhj0hBcNUiM0S33HOoXykOhEi3JFItIXV/MCNkOiBDlZBbkQjDo1LO
EybiAZm7oy2bspbgZvHrEiUtuJfnpVIlYGHNEcSHa/+i3etUn+fnFwPISLpo
6kzoyBopk1+SB/QopYTNAToWQh6BXBoRyC1vdcZDsRAcmFpRimRKLkTMHZMt
3SpjJGNK85LWDiQN2BFkAVB6zg1wBsCCvzLjis1FDBxruRASEUUx97wjgtxS
MspDBMjz6pLaxIDkL0i4YumSE7kGo0YknEQ5R3cAN1/LeA0JhNrBUiMx2NAh
y3irWYpYZ5bcPMKo5L5L4m4YyhzAcLUodIvcV1IMYw6OeaY4FlK0iablsHkW
cQzyBTDPBsMhbClCbqsdC7b0BIk4IXegFBTAWuRxU1rK3vi5AlaYN2SoX1O7
zg0AflDLG/G1DWE2/ILhSM3J80qEq6YWtp0CwtcrxEBUraxFJoYARR7G/t1s
Nv4wGo9Ak5nC6dd6tmv9QyCt7Ug2Z1lakDRP5gAloCTBlKozAofQRJML0HQw
C9eT+4B8y1mMjI1aSKVGIwRm8+YpDBpTmhCGvLWdFWOuM++ShsywWd8UxS5t
bOpGYokV0HB4QoZQAnBAhLbUt2VTAGv8vaTwlmSchqrIdk94R0d7fIB6cDOk
nV6fvKXt/rFbT8ftzgVuXJQbtHtxBuuzbrXutTu4PqsPOAtnvWPr6HDg3kGR
hSUSaxFV1VTS3c0X6CEDtH3UIPghW3itm9nQd/fqHVdLe4t+vbSXOD92VhsM
82OmNRiNX7sH4By4S5+jwXE0CoawsIiNA4dXt+dWDq1u/6Wrewnz42POUpMn
r3u7CQJ6OwsQ5P4x+fGj7NM/f4Ls91kAgserEbq7ZjFMTne5ciu4v5l88IN3
9YavChinsaYj7KArAc6dCJN3iFneAcGexD1XybM0h9lW5+yXJrp6s4sdfxuM
WriTdQRj6Php6ThsX1ou2m+XkV4J9D5XFsv76bjGYuyPbug4IO/IzXR0XZZC
p7dH5NLY6W+LMJbpZxRc7gouO1bQPd0RgA8naJeBHrw5pOrhS/A4vA3o9MvV
+KGRpgNl7sD5zZ+Rt+0KHrvqVADZlYXOXzH47Zy+v5dx0e6e9kDL4TgOKFQI
AUvvLdQOj2objJTb/Wrb92fQPyjsUitxd96RWGy77aakf9Y409kjcWe6eOd6
bHreAw/lEt5AwLi631oalj13zmP5jB386K8/9w5EeK3iM0bD9Xt9ukpYSBm6
C8OkfMNUY0zxb7lQOMlX+JyOwTA+DDaTYNDooo3GU2bis62nz4ple5GyqSyn
8u6Uu98XKtc24OyJ24CX/zle28bKoihDxNiAJTY2N4H/VWgrreNE/5+xlU3v
cHR3drRXvIDTd7YioOLDuvZta/nov06Uk22Qo0gzysNoBXhT6HjwSzMoEvvC
3kToVrb3V98vukkpqGoNJFW17Thd2MYNTWYbwX0eK1zKFWLjPpv4bKw/cbQf
Vb2ePhXwMnrpwE7xKtwXE2JbQKdoY9urS0r9v5/9xxSGgrLjDB9Qd6M7VJgM
PwwPCP8Gz8unsQoPAAA=

-->

</rfc>

