Skip to main content

A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest



Roman Danyliw

No Objection

Erik Kline
Gunter Van de Velde
Jim Guichard
John Scudder
Zaheduzzaman Sarker
(Robert Wilton)

No Record

Deb Cooley
Francesca Palombini
Mahesh Jethanandani
Warren Kumari

Summary: Has 2 DISCUSSes. Needs 2 more YES or NO OBJECTION positions to pass.

Murray Kucherawy
Discuss (2024-02-29) Sent
Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved.

I'm a little puzzled by the use of "nint" as a placeholder in some of the registries.  I don't understand what's going on there, and 8.4.8 (where it's apparently defined) didn't make it any clearer to me.  Can I get a little clarification?


From Orie Steele, incoming ART Area Director:

I have concerns with how i18n and unicode may interact with suite text strings and suite URIs.  Particularly in the case of fetching remote content.

I am also concerned about the potential IDNA issues with how UUIDs are constructed per Section
Comment (2024-02-29) Sent
The shepherd writeup doesn't include the reason that PS is the right status here.


From Orie Steele, incoming ART Area Director:

In the abstract:

This would be clearer if the first use of "IoT" were
expanded.  (
does not mark either as "well-known".)

Side note, is "Internet of Things Software Update (IoTSU)" a relevant / useful acronym here?

In Section 4.2 consider defining "pull parser", prior to using the term.

"The bootloader may add its own authentication, e.g. a Message Authentication Code (MAC), to the manifest in order to prevent further verifications."


In Section 5.3.4 "see {#ovr-integrated}," seems to be an escaped reference.

Section 5.4

Comment: "Severable Elements", seems similar to selective disclosure and elision, you might want to relate your definitions to other industry terminology.

Section 6.2

If a Recipient supports groups of interdependent components (a Component Set), then it SHOULD verify that all Components in the Component Set are specified by one update,

Under what circumstances can a recipient benefit from not verifying all components in the component set are specified by one update? (Why not MUST)

Noting Section 8.4.3 and Section 8.4.4 have internationalization considerations.


A URI Reference RFC3986 from which to fetch a resource, encoded as a text string.

I believe this precludes URI's that contain unicode, you might consider borrowing some language from

The information used to create the class-id condition (see {{uuid-identifiers)

Reference typo.

Section " SUIT_Component_Identifier"

I'd prefer to see unicode considerations in this section.

in Section 11.8

Are expired Internet drafts considered acceptable "stable references" for "standards track range of point assignment"... If not, please give concrete guidance to the experts regarding managing registrations of references that expire.

When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.

Sounds like you are asking for registries that are "Expert Review" not "Specification Required", please confirm after reading:

Extra text in each registry section, would make all this a lot clearer, as I noted in the beginning of my comments.

In Section 11.9

Why not "application/suit-envelope+cose", under what circumstances can a suite envelope be transmitted as application/cose ?

If there will never be other expressions that are not COSE, "application/suit-envelope" seems fine.
Paul Wouters
Discuss (2024-02-29) Sent
A few minor easy to resolve DISCUSSes and comments:

1) Registry Policy

       For each registry, values 0-255 are Standards Action and 256 or
        greater are Expert Review. Negative values -255 to 0 are Standards
        Action, and -256 and lower are Private Use.

        New entries to those registries need to provide a label,
        a name and a reference to a specification that describes the

This sounds like "Specification Required" and not "Expert Review" ?

2) Severability question

If a firmware has multiple severable parts, say PART1, TEXT1, PART2,
where PART1 and PART2 are firmware blobs that cover say different
parts of the hardware. They would be made severable. How can one detect
that PART2 has been removed or replaced with a copy of TEXT1 if one also
replaces the signature of the right part? eg would an attacker be able to
get a firmware update partially installed, leaving in a potential security
issue to exploit?
Comment (2024-02-29) Sent
Shouldn't [COSE_Alg] be a Normative reference?

Shouldn't all of the [I-D.ietf-suit-firmware-*] references be normative?
These are  optional, but if required/used, very normative on how to do it.
eg "if you want it encrypted, I-D.ietf-suit-firmware-encryption must be used".

        Finally, Appendix D gives a summarize of the
        mandatory-to-implement features of this specification.

That should not be in the appendix but in the main body of the document?

I find this text a bit confusing:

        [...] make the following guarantees:

        One of: 1. A [...]


        1.  Where

Might be the result of a misrender?

Section 6.4 uses a term "statement" not defined before. It really sounds
like "Command" to me, especially as one can "perform" a "statement".

Section 6.7:

        that Commands MAY be executed in parallel or out of order.

Should "or" be "and" ?

        Recipient may issue each or every command concurrently until
        the Strict Order parameter is returned to True or the Command
        Sequence ends.

This seems to invite race conditions if one concurrent command causes the
Strict Order parameter to change? What else could change the Strict Order
parameter midway a concurrent execution? Does this mean every command schedule
has to check the Strict Order parameter?

        When the manifest processor encounters any of the following
        scenarios the parallel processing MUST pause until all issued
        commands have completed

If the parallel processing pauses, wouldn't that pause the commands? I
think perhaps you mean "the parallel processing MUST not issue new commands
until all issued commands have completed" ?

        A Component MUST NOT be both a target of an operation and a
        source of data (for example, in Copy or Swap) in a Command
        Sequence where Strict Order is False.

Wouldn't this also be true when Strict Order is True?

Section 8.4.3

        suit-reference-uri is a text string that encodes a URI

What is a text string, esp. in relation to IDNs and non-ascii parts in a URI?

Section 8.4.11

Should suit-command-custom be called suit-command-custom-n with n a negative
integer? It might look from the command list there is only 1 custom command,
but there can be multiple ones.

Section 11.4 and 11.5 lists SUIT Commands/Parameters and shows a number
of Reserved fields in the middle of these new allocations. IS there
anything special with these values? Why are they reserved? Also, the text
states value 0 is skipped on purpose to detect "unset", so should value
0 not be listed as Reserved?

        A technique to efficiently compress firmware images may be standardized in the future.

Perhaps the compressing would be highly inefficient, to make decompressing highly efficient?
Maybe just remove the word "efficiently" :)

The CDDL contains:

suit-reporting-bits = &(
    suit-send-record-success : 0,
    suit-send-record-failure : 1,
    suit-send-sysinfo-success : 2,
    suit-send-sysinfo-failure : 3

Doesn't this mean 2 bits are used to declare a bool?
What if these contradict? Why not use a single bit?


        see {#ovr-integrated},

Markdown misrender ?
Roman Danyliw
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Orie Steele
No Objection
Comment (2024-03-29) Not sent
I support Murray's discuss.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2024-03-04) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-suit-manifest-25

This is a rather superficial/high level ballot of mine (after the actual telechat) in the hope of getting enough ballots before the next IESG is seated.

Thank you for the work put into this document. It is clearly written and pretty clear. I also like the fact that the text elements are i18n per section 8.4.4.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Russ Housley for the shepherd's write-up including the *brief* WG consensus *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,



# COMMENTS (non-blocking)

## Too complex for IoT

When reading (even superficially) the whole document, I wonder whether a constrained device can realistically implement the full document (power, CPU, & memory constraints), are there proof of concept ?

## Section 1

Just curious about `a device to reason`, "to reason" may be a false friend with the French "raisonner", but it seems really weird to give some reasoning power (i.e., conscience) to a device...

## Section 4.1

Is lack of correct time also a limiting factor ? Or intermittent/unstable connection ?

## Section 6.2

Isn't the section title `Required Checks` in contradiction with the first sentence `The RECOMMENDED process is to verify` ?

## Section

Should "PEN" be expanded before first use ?

## Section

It is too late to raise a DISCUSS after the IESG telechat, but what is `DNS_PREFIX` ? I found definition neither in this I-D not in RFC 4122. Should it be `DNS_SUFFIX` BTW? 

`MCU` what is it ? I guess that it is not "MCU        - Multipoint Control Unit (MCU)" per

# NITS (non-blocking / cosmetic)

## Wi-Fi or WiFi

It seems that Wi-Fi is usually written with an hyphen. The RFC Editor will probably check anyway.

## E.g.

Usually, "e.g." is followed by a comma.
Deb Cooley
No Record
Francesca Palombini
No Record
Mahesh Jethanandani
No Record
Warren Kumari
No Record
Martin Duke Former IESG member
No Objection
No Objection (2024-03-04) Sent
(Section 5) the word choice is very confusing:

"-- The manifest is structured from several key components:

The Envelope (see Section 5.1) contains the Authentication Block, the Manifest, any Severable Elements, and any Integrated Payloads."

The common sense reading of this is that the structure is recursive. The manifest contains an envelope, which contains a manifest, which contains an envelope. I think it should be "The metadata is structured"?

Similarly, the hierarchy doesn't seem quite right here. The metadata contains a bunch of stuff, including the envelope, but the envelope actually contains all the other things. So perhaps the correct way to express it is that the envelope carries the metadata, which consists of items 2 through 5. Or maybe you mean something else, in which case this needs to be rewritten even more thoroughly.

(Appendix C) s/Rational/Rationale.
Robert Wilton Former IESG member
No Objection
No Objection () Not sent