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

[Deb Cooley <[e-mail]>]

Apologies for the delay, technically the manifest draft belongs to Roman
(he has Manifest and Mud), but I'm sure we are all fine with editorial and
minor changes.

Given the length of time we have been waiting for the final drafts to work
their way through, it might make sense to do a final scrub through the
whole set to be sure they are still correct.

Deb

On Tue, Mar 31, 2026 at 10:07 AM Hannes Tschofenig <hannes.tschofenig=
[e-mail]> wrote:

> Koen,
>
> I should have also given you a response to your questions below.
>
> See inline.
>
>
> Am 30.03.2026 um 11:49 schrieb Hannes Tschofenig:
> > 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.
> >>
> I agree that having the references there would be useful. I believe this
> is a minor change that can be made during AUTH48. Deb has to verify and
> approve though.
>
>
> >> 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.
>
> Double bstr‑wrapping is not the intented behavior. A clarification would
> be helpful. Adding examples is probably not what we should be adding at
> this stage though.
>
>
> >>
> >> 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).
>
>
> I always assumed option 1. It is an interesting question though. I was
> not thinking about constrained implementations that build the manifest.
> For me the constrained devices were always those that processed the end
> result.
>
> I would add a sentence to Section 8.6 "Several Elements" that says
> something like:
>
> "
> When a severable element is removed, the corresponding key/value pair
> MUST be removed from the SUIT_Envelope CBOR map. Implementations MUST
> NOT replace the value with null.
> "
>
> This is obviously not just an editorial change and will require
> AD-approval.
>
>
> >>
> >> 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.
>
> I give this issue to Brendan.
>
>
> Ciao
>
> Hannes
>
>
> >>
> >> 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]
>
> _______________________________________________
> Suit mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>