Draft: draft-ietf-suit-firmware-encryption

Commentary: Most of the changes are related to line breaks . 
 s / appropriated / appropriate/
Paragraph (version A):
A symmetric cryptographic key is established for encryption and
decryption, and that key can be applied to a SUIT manifest, firmware
images, or personalization data, depending on the encryption choices
of the firmware author.  This symmetric key can be established using
a variety of mechanisms; this document defines two approaches for use
with the IETF SUIT manifest.  Key establishment can be provided by
the hybrid public-key encryption (HPKE) scheme or AES Key Wrap (AES-
KW) with a pre-shared key-encryption key.  These choices reduce the
number of possible key establishment options for interoperability of
different SUIT manifest implementations.  The document also offers a
number of examples for developers.
Paragraph (version B):
A symmetric cryptographic key is established for encryption and
decryption, and that key can be applied to a SUIT manifest, firmware
images, or personalization data, depending on the encryption choices
of the firmware author.  This symmetric key can be established using
a variety of mechanisms; this document defines two approaches for use
with the IETF SUIT manifest.  Key establishment can be provided by
the hybrid public-key encryption (HPKE) scheme or AES Key Wrap (AES-
KW) with a pre-shared key-encryption key.  These choices reduce the
number of possible key establishment options and thereby help
increase interoperability between different SUIT manifest parser
implementations.
Paragraph (version B):
The document also contains a number of examples for developers.
Paragraph (version A):
The terms "recipient" and "firmware consumer" are used
interchangeably.
Paragraph (version B):
In context of encryption, the terms "recipient" and "firmware
consumer" are used interchangeably.
Paragraph (version A):
The AES Key Wrap (AES-KW) algorithm is described in RFC 3394 RFC3394,
and it can be used to encrypt a randomly generated content-encryption
key (CEK) with a pre-shared key-encryption key (KEK).  The COSE
conventions for using AES-KW are specified in Section 12.2.1 of
RFC8152.  The encrypted CEK is carried in the COSE_recipient
structure alongside the information needed for AES-KW.  The
COSE_recipient structure, which is a substructure of the
COSE_Encrypt, contains the CEK encrypted by the KEK.  When the
firmware image is encrypted for use by multiple recipients, the
COSE_recipient structure will contain one encrypted CEK if all of the
authorized recipients have access to the KEK.
Paragraph (version A):
However, the COSE_recipient structure can contain the same CEK
encrypted with many different KEKs if needed to reach all of the
authorized recipients.
Paragraph (version B):
The AES Key Wrap (AES-KW) algorithm is described in RFC 3394 RFC3394,
and it can be used to encrypt a randomly generated content-encryption
key (CEK) with a pre-shared key-encryption key (KEK).  The COSE
conventions for using AES-KW are specified in Section 12.2.1 of
RFC8152.  The encrypted CEK is carried in the COSE_recipient
structure alongside the information needed for AES-KW.  The
COSE_recipient structure, which is a substructure of the COSE_Encrypt
structure, contains the CEK encrypted by the KEK.
Paragraph (version B):
If all of authorized recipients have access to the KEK, a single
COSE_recipient structure contains the encrypted CEK.
Paragraph (version B):
If recipients have different KEKs, then the COSE_recipient
structure may contain the same CEK encrypted with many different
KEKs.  The benefit of this approach is that the firmware image is
encrypted only once with the CEK while the authorized recipients
still need to use their individual KEKs to obtain the plaintext.
Paragraph (version B):
The last option is to use different CEKs encrypted with KEKs of
the authorized recipients.  This is appropriate when no benefits
can be gained from encrypting and transmitting firmware images
only once.  For example, firmware images may contain information
unique to a device instance.
Paragraph (version A):
The COSE specification requires a consistent byte stream for the
authenticated data structure to be created, which is defined as shown
in cddl-enc-aeskw.
Paragraph (version A):
As it can be seen in the CDDL in cddl-aeskw, there are two protected
fields and the 'protected' field in the Enc_structure, see cddl-enc-
aeskw, refers to the outer protected field, not the protected field
of the COSE_recipient structure.
Paragraph (version B):
The COSE specification requires a consistent byte stream for the
authenticated data structure to be created, which is shown in cddl-
enc-aeskw.
Paragraph (version B):
As shown in cddl-aeskw, there are two protected fields: one protected
field in the COSE_Encrypt structure and a second one in the
COSE_recipient structure.  The 'protected' field in the
Enc_structure, see cddl-enc-aeskw, refers to the content of the
protected field from the COSE_Encrypt structure, not to the protected
field of the COSE_recipient structure.
Paragraph (version A):
For use with firmware encryption the firmware author, or the
distribution system, uses HPKE, which internally utilizes a non-
interactive ephemeral-static Diffie-Hellman exchange to derive a
shared secret.  This key is then used to encrypt plaintext.  In the
firmware encryption scenario, the plaintext passed to HPKE for
encryption is a randomly generated CEK.  The output of the HPKE
operation is therefore the encrypted CEK along with HPKE encapsulated
key (i.e. the ephemeral ECDH public key of the author).  The CEK is
then used to encrypt the firmware.
Paragraph (version B):
For use with firmware encryption the scheme works as follows: The
firmware author uses HPKE, which internally utilizes a non-
interactive ephemeral-static Diffie-Hellman exchange to derive a
shared secret, which is then used to encrypt plaintext.
Paragraph (version B):
In the firmware encryption scenario, the plaintext passed to HPKE for
encryption is the randomly generated CEK.  The output of the HPKE
operation is therefore the encrypted CEK along with HPKE encapsulated
key (i.e. the ephemeral ECDH public key of the author).  The CEK is
then used to encrypt the firmware.
Paragraph (version A):
This approach allows us to have all recipients to use the same CEK to
encrypt the firmware image, in case there are multiple recipients, to
fulfill a requirement for the efficient distribution of firmware
images using a multicast or broadcast protocol.
Paragraph (version B):
This approach allows all recipients to use the same CEK to encrypt
the firmware image, in case there are multiple recipients, to fulfill
a requirement for the efficient distribution of firmware images using
a multicast or broadcast protocol.
Paragraph (version A):
PartyUInfo.identity corresponds to the kid found in the
COSE_Sign_Tagged or COSE_Sign1_Tagged structure (when a digital
signature is used.  When utilizing a MAC, then the kid is found in
the COSE_Mac_Tagged or COSE_Mac0_Tagged structure.
Paragraph (version B):
PartyUInfo.identity corresponds to the kid found in the
COSE_Sign_Tagged or COSE_Sign1_Tagged structure (when a digital
signature is used).  When utilizing a MAC, then the kid is found
in the COSE_Mac_Tagged or COSE_Mac0_Tagged structure.
Paragraph (version A):
An example of the COSE_Encrypt structure using the HPKE scheme is
shown in hpke-example.
Paragraph (version A):
TBD: Add example for complete manifest here (which also includes the
digital signature).  TBD: Add multiple recipient example as well.
TBD: Add encryption of manifest (in addition of firmware encryption).
Paragraph (version B):
AES-GCM-128 for encryption of the firmware image.
Paragraph (version B):
AES-GCM-128 for encrytion of the CEK.
Paragraph (version B):
TBD: Example for complete manifest here (which also includes the
digital signature).  TBD: Multiple recipient example as well.  TBD:
Encryption of manifest (in addition of firmware encryption).