Re: [Suit] Ordering of elements in SUIT Manifest

[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.
>