Change:
Based on discussions with Russ, I have updated the text in Section 7 about CEK Verification. Text about the parameters used for encryption were missing.

Discussion:
Firmware Encryption with SUIT Manifests <del> draft-ietf-suit-firmware-encryption-03 </del> <ins> draft-ietf-suit-firmware-encryption-04 </ins> Abstract

manifest with key establishment provided by the hybrid public-key encryption (HPKE) scheme and the AES Key Wrap (AES-KW) with a pre- shared key-encryption key.  Encryption of the firmware image is <del> encrypted using AES-GCM or AES-CCM. </del> <ins> accomplished using the established content encryption key and a mutually agreed symmetric encryption algorithm, such as AES-GCM or AES-CCM. </ins> 1.

D.ietf-suit-manifest, the SUIT information model RFC9124 and the SUIT architecture RFC9019. <del> The terms sender and recipient are defined in I-D.irtf-cfrg-hpke and have the following meaning: </del> <ins> The terms sender and recipient are defined in RFC9180 and have the following meaning: </ins> Sender: Role of entity which sends an encrypted message.

Content-encryption key (CEK), a term defined in RFC 2630 RFC2630. <del> Hybrid Public Key Encryption (HPKE), defined in I-D.irtf-cfrg- hpke. </del> <ins> Hybrid Public Key Encryption (HPKE), defined in RFC9180. The main use case of this document is to encrypt firmware.  However, SUIT manifests may require other payloads than firmware images to experience confidentiality protection using encryption.  While the term firmware is used throughout the document, plaintext other than firmware images may get encrypted using the described mechanism. Hence, the terms firmware (image) and plaintext are used interchangably. </ins> 3.

6. <del> Hybrid public-key encryption (HPKE) I-D.irtf-cfrg-hpke is a scheme that provides public key encryption of arbitrary-sized plaintexts given a recipient's public key. </del> <ins> Hybrid public-key encryption (HPKE) RFC9180 is a scheme that provides public key encryption of arbitrary-sized plaintexts given a recipient's public key. </ins> For use with firmware encryption the scheme works as follows: HPKE, which internally utilizes a non-interactive ephemeral-static Diffie-

An example of the COSE_Encrypt structure using the HPKE scheme is shown in hpke-example.  It uses the following algorithm combination: <del> AES-GCM-128 for encryption of the (detached) firmware image (at layer 0). </del> <ins> AES-GCM-128 for encryption of the (detached) firmware image. </ins> <del> AES-GCM-128 for encryption of the CEK in layer 1 as well as ECDH with NIST P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism (KEM). </del> <ins> AES-GCM-128 for encryption of the CEK as well as ECDH with NIST P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism (KEM). </ins> 7. The suit-cek-verification parameter contains a byte string resulting <del> from the encryption of 8 bytes of 0xA5 using the CEK. </del> <ins> from the encryption of 8 bytes of 0xA5 using the CEK with a nonce of all zeros and empty additional data using the cipher algorithm and mode also used to encrypt the plaintext. </ins> <del> [[Editor's Note: Guidance about the selection of an IV needs to be added here.]] </del> <ins> As explained in arch, the suit-cek-verification parameter is optional to implement and optional to use.  When used, it reduces the risk of an battery exhaustion attack against the IoT device. </ins> 8.