Re: [Suit] Draft-ietf-suit-manifest encryption use

[Russ Housley <[e-mail]>]

Brendan:

I thought we talked about moving the whole COSE_Encrypt structure so that it was not covered by the signature.  That would allow a party in the distribution path to change the COSE_Recipients without damage to the signature.  Since we a re using detached payload, the implementation needs to remember the resulting CEK.  Which is still needed in your proposal, I believe.

Russ


> On Jun 2, 2021, at 5:59 AM, Brendan Moran <[e-mail]> wrote:
> 
> During the virtual interim, we raised the point that the COSE_Recipients for a COSE_Encrypt should not be covered by a signature or digest. This prevents a management system from sending each recipient only the COSE_Recipient structure that pertains to it. This is not ideal for the structure of the manifest.
> 
> I can see several ways forward:
> 1. Key agreement is explicitly out-of-band. The manifest uses COSE_Encrypt0 exclusively. No changes are needed to the manifest. The kid header parameter is used to distinguish between keys for different payloads.
> 
> 2. The manifest references encryption information by URI. The typical approach is to place the encryption info in the SUIT_Envelope, then reference it by a numeric reference. (e.g. 12 for key 12 in the current SUIT_Envelope). This approach permits the distributor to edit the COSE_Recipients, which allows a firmware author to include all recipients. The distributor can then remove all but the intended recipient. Federated distributors are also possible, where the COSE_Recipients is reduced at each level of distribution.
> 
> 3. Break COSE’s existing conventions: set COSE_Recipients to nil in order to represent that COSE_Recipients is detached. This is problematic for two reasons: first, it means that we break compatibility with existing COSE libraries, since they will not expect a detached COSE_Recipients; second, it leaves no way to indicate where to find COSE_Recipients. Instead of ’nil’ we could use an int.
> 
> I think we should probably discard Option 3. I worry that Option 2 exposes a number of options for tampering with the COSE_Encrypt. It also means that the parser has to advance past the manifest in order to locate the COSE_Encrypt blocks. The envelope should not contain an enormous number of elements, so it may be acceptable to simply hold a table in memory of the key, start, end of each element of the envelope.
> 
> We could enable both 1 and 2 by changing the current SUIT Parameter:
> ORIGINAL:
>        SUIT_Encryption_Info = COSE_Encrypt_Tagged/COSE_Encrypt0_Tagged
> PROPOSED:
>        SUIT_Encryption_Info = int / COSE_Encrypt_Tagged/COSE_Encrypt0_Tagged
> 
> 
> Alternatively, we could enable both 1 and 2 by adding a new parameter:
> 
> SUIT_Parameters //= (suit-parameter-encryption-ref
>    => int)
> 
> Best Regards,
> Brendan
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit