Return-Path: X-Original-To: suit@mail2.ietf.org Delivered-To: suit@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id DBCE2F627865 for ; Wed, 27 May 2026 12:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779909164; bh=f8QoXod3k6vbFoKQAFJa49QrlxNnwPdvi4bAIEzilKM=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=bDjL0jTnXwU4vdqnpkxKJnbU+d9IqDYWMAcR1F83vvdO7LPa0Nyc796YXWBGvdHww hXEPc3m7sQLfz7hOppw31sVco0/liF594efeIcao+C9/p4Fh9eFjshZl1o+9PyM73f hme5FanZ14HOqYC35vcP4BVqWvIB3Vo2YKox59+8= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJuWEMBrsy5Q for ; Wed, 27 May 2026 12:12:44 -0700 (PDT) Received: from mail-dy1-x1336.google.com (mail-dy1-x1336.google.com [IPv6:2607:f8b0:4864:20::1336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 90F25F6276CD for ; Wed, 27 May 2026 12:11:16 -0700 (PDT) Received: by mail-dy1-x1336.google.com with SMTP id 5a478bee46e88-2f0ad52830cso15365930eec.1 for ; Wed, 27 May 2026 12:11:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779909075; cv=none; d=google.com; s=arc-20240605; b=PdZRHV+13NJy7kzzt7i21m8yVJvw3Wkkrm9CJLtOZuvkCG212/gWnfys673FJ9YG2z IGP5+sr1/R3hG+7HlU8XWG1GOsx2OsekUPK46jflJQRVEK1HrXpcqT/1MbHMCK3QVjAL 1+zYMiwXYOAyw2ZktfIHFtqhKV7KizncCpZoaGTut8LzCvpERVRV1EM0XU+gE6dLVEZM vmbTim3Lqjx4RDuwgAyAvrJRpvC8IASgWE/e668OsMTm+i4ok8tNszVHbZALD4+oPREk sUr27kGuylSi1l2ygPygUh5rmj2fMh3k5p15tebg5bir9tJp8aUIPnQMwQJSGHMyr8WB B2rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=f8QoXod3k6vbFoKQAFJa49QrlxNnwPdvi4bAIEzilKM=; fh=zxsp6JrsoOXp8w5NkKXErBjwl7B/e3CSoUVXl27X4mk=; b=NOgOoaF2O3aQhaO9bY/MmUDF9DFG05AKIjVqBVT/EkJ/LsK2g2xJrntArviVeSVaj2 lvbRPQOYtHvYCxpN1r085TTfFKPPtsIykq5IOok9yAuuM7ulH61qMQAZ5F2x1EH+NQkw OUVBmq6WB3UoQae96YfdsNsbTo2YQM4dlL/kp3Zp03TET5pJiWzLx990FPLmb+392YkX 9OVIodSNRjpn6mknvUGg1YPcxNSev3T63EQkStADGzgWcRov37YHMWQ+Si/ApWPVWVGl 5MORL6ZyF7selUrFJas3HnjYYcWdzUHXbxVprZQP+rtz0wsAnYUjNIScWau9ucY/YdI4 ymfQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779909075; x=1780513875; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f8QoXod3k6vbFoKQAFJa49QrlxNnwPdvi4bAIEzilKM=; b=QSNpQ8NxEJgS2bw0CZYYRqnTsXERdmCjYQsE+LhHmwNibrxmz/GvT/YHcxgC8jTDGw fS3bQNsrz0NGhzGJ0nEuth1Lou85eJeibkKNDXWTofKwgL2hCF2nXmewX1tP2xWuChOc Js/y5r4F7aGgE+QQPMMo9nMFkz8/akM2GBF2e+b5XaGgjYZdi5A2aFSvBbOeoB5XrODx CD0vevcsWxHZRDPBJEOjnMAEluYWbUhrz9fmb1M1gSMg9jHKuvBxucTD/nLCTKKwhT+N J+TBP0HhbednjEJfb8XKf7uVHmO8Muld25BtPyKec2CnSrL1MsGgHTj20pnSR30xyEok N1mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779909075; x=1780513875; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=f8QoXod3k6vbFoKQAFJa49QrlxNnwPdvi4bAIEzilKM=; b=qV9RRcFgT99vRvi0aq9sG1bf1vZXrWi4LaX4HCL68rfPrLqUmDTNRAbDIAacoUmwxb Dq9eceVcwwHJzP6rTBGRWfbc3aD67MEEbjuEtszZjYqNPFk8xuKsi9aqGdaLcntjik6k TErCi33bZVRA+X72ZdB6ytaBGh2vjcztkLsL6DYCEJoVxRh3/qNB4ipGbYg/QQO6Fi4Y FQW1udmIBhmvBkICccYnLOTToSFZZi8AK8xRvGC6lhmuEUioaqngmrM3qWxZFZ4b4G94 9bLAUAWMw1kugKBt4SStDQFMhp7ZBl4j9eAS/0je98mMS5AB0geFQA7nUdg1ctDp7+hg Rtlg== X-Forwarded-Encrypted: i=1; AFNElJ88omN7L1r5Bft1mfQlJsyjK2FpNifoQdBYzqwh8VicWIBoXARP9QkUFTvcG3K5TX7p1ior@ietf.org X-Gm-Message-State: AOJu0Yy78DLYylg1OL2i5Py+g6bMTjqWNNSqQPAIyohHOBu/LzWb/ILm 0uaRAXsPayaKZMH0hZpNNH9XbK34amhOi9aWFAvga0bHE+f5RxNfqXgAeL+5N0mFnV8TmwpXvn6 Fstev+dDVrdIN2GD2fswaUsYbWc2XOQ== X-Gm-Gg: Acq92OHFbXGiOzzjLbHiFU7xTq8NgwpetM49T9+fOT8vAf8a3/S/ayGBY2NUkYEgiqa Qz+5Thg2jV0OQl42rCw6eG6OrQ3Q8RMUAC0wUyUn9cQ6xBtiQW+ysZdlF8aZNsGYRWKErC0dlza VbBwnCgmly1lRnthR+Qp6X1XYZvYvRmWm5AmoR1Hi+k/OCcKC951KmoFwSLUdegEfmTcXZSCjSf cCFqhyzlPwyw4x/DliplAidbq5QT0r9YcYYAtp5pbrD/qSQoAwDnzzqZWylIxipkMRREKIXGv6I chTPm179iwA2R6TiZ8j1n088xyk3r1/aVSW3vb3enTR4LecOjPckZI8mt3MruFTvp5LSaCt6CkE x797aB/BViXiuI6d8OxlHsyhxi3eQRRKBlPrHV4q4oOMYRbQ= X-Received: by 2002:a05:7300:134a:b0:2ed:a64:a457 with SMTP id 5a478bee46e88-30449184cbcmr11202653eec.20.1779909075326; Wed, 27 May 2026 12:11:15 -0700 (PDT) MIME-Version: 1.0 References: <9cfa4d62-64c2-4145-9c61-897021861b12@gmx.net> In-Reply-To: <9cfa4d62-64c2-4145-9c61-897021861b12@gmx.net> From: Deb Cooley Date: Wed, 27 May 2026 15:11:02 -0400 X-Gm-Features: AVHnY4L8Wss-mdrOvYTpsEiV9r32idjJ1Rfq-xxEwmS-PDe6MPh00vKase9h8UE Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary="0000000000002addcd0652d16052" Message-ID-Hash: DGCD5C3VQDOWPGUM23HJLD4X4L32HJKY X-Message-ID-Hash: DGCD5C3VQDOWPGUM23HJLD4X4L32HJKY X-MailFrom: debcooley1@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-suit.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Koen Zandberg , suit@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BSuit=5D_Re=3A_Minor_comments_on_draft-suit-manifest-34?= List-Id: Software Updates for Internet of Things Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002addcd0652d16052 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Hannes Tschofenig 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 new= s. > > > > 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=E2=80=91wrapping is not the intented behavior. A clarificatio= n 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 -- suit@ietf.org > >> To unsubscribe send an email to suit-leave@ietf.org > > _______________________________________________ > Suit mailing list -- suit@ietf.org > To unsubscribe send an email to suit-leave@ietf.org > --0000000000002addcd0652d16052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the delay, technically the manifest dra= ft belongs to Roman (he has Manifest and Mud), but I'm sure we are all = fine with editorial and minor changes.

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

Deb

On Tue, Mar 31, 2026 at 10:07=E2=80=AFAM Hannes Tsch= ofenig <hannes.tschofenig=3D= 40gmx.net@dmarc.ietf.org> 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 ne= ws.
>
> Regarding your suggestions for further improving the draft. As you > know, the document is already in the RFC Ed Queue=C2=A0state 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 manif= est
>> 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&= #39;m late
>> to the party with the feedback here.
>>
>> Starting with a minor editorial nit: suit-parameter-content is use= d
>> with both suit-condition-check-content and suit-directive-write. <= br> >> 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. I= n
>> general I found these references between command and parameter ver= y
>> 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 us= ing
>> detached payload over a bstr-wrapped SUIT_Digest. I stumbled over =
>> this in my implementation because RFC 9052, section 4.4[2] specifi= es
>> the payload as used in the Sig_structure also as bstr. Following <= br> >> these instructions and passing the SUIT_Digest to a cose library a= s
>> bstr-wrapped results in a double bstr wrapping, once by my code an= d
>> once by the COSE implementation. I do not think this was the inten= t
>> here and the examples in the document correctly verify when the >> SUIT_Digest is not extra bstr wrapped. Practically speaking, I thi= nk
>> this section could use some clarification and maybe an example >> Sig_structure or MAC_structure to prevent confusion.

Double bstr=E2=80=91wrapping 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 t= o
>> remove the elements from the envelope. I see two ways: 1) remove t= he
>> 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 constrain= ed
>> implementations because the map itself does not have to be modifie= d,
>> 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 fo= r
>> constrained implementation because the CBOR map marker should alwa= ys
>> be only 1 byte, given the limited number of elements of the envelo= pe.
>> (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 say= s
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 th= is
>> to attention because I noticed it while writing my implementation,=
>> and want to check if it's intentional or an oversight in the d= ocument.

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/rfc90= 52#section-4.4
>>
>> _______________________________________________
>> Suit mailing list -- suit@ietf.org
>> To unsubscribe send an email to suit-leave@ietf.org

_______________________________________________
Suit mailing list -- sui= t@ietf.org
To unsubscribe send an email to suit-leave@ietf.org
--0000000000002addcd0652d16052--