Re: [Suit] Ordering of elements in SUIT Manifest

[Ken Takayama <[e-mail]>]

Dear Brendan and Hannes,

I've changed and tested my library a bit, and now I'm 100% agree with
Brendan.
The order MUST be canonical / deterministic,
so that the constrained device can easily parse it.
I will complete fixing my parser soon.


> Brendan and Hannes
The SUIT_Encryption_Info is still trial,
and there is no firmware encryption manifest.
Does this example binary match to your thoughts?
<
https://github.com/yuichitk/libcsuit/blob/firmware-encryption/testfiles/suit_manifest_expE.md?plain=1#L74
>

Best,
Ken

2022年7月29日(金) 6:15 Ken Takayama <[e-mail]>:

> Dear Brendan,
> CC: Hannes
>
> Thank you for your insightful comments.
> I didn't care about the constrained devices enough. Now your intention
> limiting envelope to canonical/determrnistic CBOR ordering in 8.1. becomes
> clear.
> ```
> All CBOR maps in the Manifest and manifest envelope MUST be encoded
> with the canonical CBOR ordering as defined in [RFC8949].
> ```
>
>
> Let me explain more detail why I'm still thinkig about the order of
> integrated elements and suit-install.
> My current implementation of libcsuit assumes this format:
>
> - suit-authentication-block
> - **integrated-payoad** (e.g. "#payload": h'beef')
> - suit-manifest
>   - suit-install
>     - suit-directive-override-parameters
>       - suit-parameter-uri "#payload"
>     - suit-directive-fetch
>   - suit-text digest
> - suit-text
>
> The libcsuit parse it with these sequence, which are almost the same what
> you explained except step 3.
> 1. cache the digest in suit-authentication-block
> 2. authenticate the digest with the signature
> 3. **store the memory address of key "#payload" and its bstr value into
> pointer variables respectively**
> 4. calculate the hash of suit-manifest and compare it with the cached
> digest
> 5. execute the manifest (set uri and fetch it from the stored pointers
> created in step 3)
> 6. cache the diget of suit-text
> 7. validate the severed suit-text w/o executing it
>
> > since this would require random-access parsing of the manifest, rather
> than the linear process we have up to this point.
>
> Right, it causes random access parsing, but I expect that parsing
> canonical SUIT Manifest would also be random access.
>
> - suit-authentication-block
> - suit-manifest
>   - suit-install
>     - suit-directive-override-parameters
>       - suit-parameter-uri "#payload"
>     - suit-directive-fetch
>  - suit-text digest
> - suit-text
> - **integrated-payoad** (e.g. "#payload": h'beef')
>
> When I parse the manifest above, I want to cache the address of
> integrated payload first otherwise the parser cannot resolve the uri
> "#payload" while fetching the content in suit-install section. So the
> parser will:
>
> 1. cache the digest in suit-authentication-block
> 2. authenticate the digest with the signature
> 3. calculate the hash of suit-manifest and compare it with the cached
> digest
> 4. store the memory address of severed suit-text section
> 5. **store the memory address of key "#payload" and its bstr value into
> pointer variables respectively**
> 6. execute the manifest (set uri and fetch it from the stored pointers
> created in step 5, then may validate the suit-text digest)
> 7. ignore severed suit-text section
>
> I may misunderstand your thought, but I'm eager to make it clear in order
> to implement correct parser and encoder.
>
>
> > Regardless, the manifest now encodes integrated items with string keys,
> so it may well be that your CBOR encoder puts those before integers?
>
> The CBOR encoder I'm using follows the procedure like so called
> OrderedDict, so I do have to care it as a caller.
>
>
> There is a good example which integrates encrypted firmware. I created it
> in the IETF114 hackathon.
> I integrated the encrypted firmware inside the manifest just before the
> suit-manifest, because it has to be decryped while executing the manifest.
> <
> https://github.com/yuichitk/libcsuit/blob/firmware-encryption/testfiles/suit_manifest_expE.md?plain=1#L30
> >
>
> I hope you and Hannes give me some feedback on it not only the order of
> map keys but also around SUIT_Encryption_Info.
>
>
> Again, thank you Brendan answering my questions!
>
> Best,
> Ken
>
> 2022年7月28日(木) 18:37 Brendan Moran <[e-mail]>:
>
>> Hi Ken,
>>
>> I noticed your message in the meet echo chat; unfortunately, it wasn’t
>> repeated at the mic and I missed it during the meeting.
>>
>> > Related to the order of the manifest, I'm not convinced but I think the
>> integrated elements should be before the suit-manifest because it would be
>> referred by suit-install or suit-dependency-resolution section.
>>
>> I think it is reasonable to say that elements the recipient requires
>> should come before the elements the recipient does not require.
>>
>> I also think it is reasonable to say that severable elements should come
>> after non-severable elements.
>>
>> But these are both “should” not “must.” So I don’t hold the opinion
>> strongly.
>>
>>
>> Now as to the location of the integrated elements, I think I have to
>> disagree. The problem is the order of operations:
>>
>> When a constrained recipient receives a manifest, the first thing it
>> encounters is delegation chains. This allows it to work down towards the
>> public key that is in use. Next, it finds the authentication block. By now,
>> it has the correct public key to validate the authentication block. The
>> authentication block allows the constrained recipient to validate a single
>> digest. Once it has done this, it can discard the authentication block
>> (from memory anyway). It does not need to parse the authentication block
>> again. Having parsed the authentication block, it has the expected hash of
>> the manifest in memory. The next step it takes is to hash the manifest to
>> verify/authenticate it. If this passes, then it can begin executing the
>> manifest.
>>
>> The constrained recipient won’t even know it needs an integrated element
>> until after it has completed all these steps, so I am reluctant to put them
>> first, since this would require random-access parsing of the manifest,
>> rather than the linear process we have up to this point.
>>
>> However, I’m happy to hear other opinions!
>>
>> Regardless, the manifest now encodes integrated items with string keys,
>> so it may well be that your CBOR encoder puts those before integers?
>>
>> 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.
>>
>