[Suit] Re: Minor comments on draft-suit-manifest-34

[Hannes Tschofenig <[e-mail]>]

Hi Koen!

Thanks for contributing another SUIT manifest parser. This is great news.

Regarding your suggestions for further improving the draft. As you know, 
the document is already in the RFC Ed Queue state and only minor changes 
can be made at this point in time. I will check what clarifications can 
be made at this stage.

Ciao
Hannes

Am 13.03.2026 um 13:30 schrieb Koen Zandberg:
> Hi all,
>
> I've had the pleasure to create another constrained SUIT manifest 
> parser implementation[1], this time in Rust and with 
> draft-ietf-suit-manifest-34. Based on this implementation, I have a 
> few comments where the document could be clearer. I'm aware I'm late 
> to the party with the feedback here.
>
> Starting with a minor editorial nit: suit-parameter-content is used 
> with both suit-condition-check-content and suit-directive-write. 
> Section 8.4.8.9 only references Section 8.4.10.6 (copy) and not 
> Section 8.4.9.3 (check-content). Section 8.4.9.3 is missing a 
> reference back to the parameter similar to suit-directive-write. In 
> general I found these references between command and parameter very 
> helpful to match the parameter to the commands.
>
> Section 8.3 describes the SUIT_Authentication_Block as computed using 
> detached payload over a bstr-wrapped SUIT_Digest. I stumbled over this 
> in my implementation because RFC 9052, section 4.4[2] specifies the 
> payload as used in the Sig_structure also as bstr. Following these 
> instructions and passing the SUIT_Digest to a cose library as 
> bstr-wrapped results in a double bstr wrapping, once by my code and 
> once by the COSE implementation. I do not think this was the intent 
> here and the examples in the document correctly verify when the 
> SUIT_Digest is not extra bstr wrapped. Practically speaking, I think 
> this section could use some clarification and maybe an example 
> Sig_structure or MAC_structure to prevent confusion.
>
> One open question I still have is on the severable elements. What is 
> the procedure a SUIT manifest implementation must follow to remove a 
> severable element from the envelope? The text describes in detail how 
> to make elements severable, but does not seem to be clear on how to 
> remove the elements from the envelope. I see two ways: 1) remove the 
> key and the bstr content from the envelope, or 2) replace the bstr in 
> the envelope with a null. Option 2 feels a bit easier on constrained 
> implementations because the map itself does not have to be modified, 
> it is only a replace of the bstr with a null and a memmove to keep the 
> rest of the manifest attached. Option 1 should also be fine for 
> constrained implementation because the CBOR map marker should always 
> be only 1 byte, given the limited number of elements of the envelope. 
> (And should never trigger a memmove of almost the whole document).
>
> The last thing I noticed, where I'm not sure it is intentional or an 
> issue, is the lack of component slot for the source component. It is 
> possible to specify a component slot (via 
> suit-parameter-component-slot) for the slot within the current 
> component. But there doesn't exist a method to specify a slot for the 
> suit-parameter-source-component`. One use case I can imagine is to 
> encode a backup of the current content of a component slot to 
> (external) storage via a copy directive. I mainly want to bring this 
> to attention because I noticed it while writing my implementation, and 
> want to check if it's intentional or an oversight in the document.
>
> Best regards,
> Koen Zandberg
>
> [1]: https://github.com/ariel-os/dress-up/
> [2]: https://www.rfc-editor.org/rfc/rfc9052#section-4.4
>
> _______________________________________________
> Suit mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]