[Suit] Re: Minor comments to draft-ietf-suit-report-18

[Brendan Moran <[e-mail]>]

Hi Ken,

Sorry it's taken some time to get back to you on this.

> Should the sentence below say “either a COSE_Encrypt0, COSE_Sign1, or
COSE_Mac0 structure”?

Yes, that's probably correct.

> "Double-fault" handling
I don't think it is acceptable for a device to fail to sign a suit
report. It is also not acceptable for a suit report to EVER be
transmitted unauthenticated--just think about the attack scenarios
that would occur if you have decision logic that acts on an
unauthenticated suit report. I think--if there's a failure while
creating a suit report, there should be a fallback, for sure, but not
one that results in an unauthenticated suit report.

> `suit-report-manifest-uri` should not be mandatory
If the URI is not mandatory, then from where do you obtain a full copy
of the manifest? I suppose, if the report ONLY contains
SUIT_Record_System_Properties, then you can get away with processing
the suit report without the manifest. But I don't think it is a good
idea. You lose a lot of information when processing the suit report
without the manifest.

> Because the `suit-reference` section and its elements are currently
> required in `SUIT_Report`, a SUIT Manifest Processor may be unable to
> encode them when processing a manifest that lacks a
> `suit-authentication-wrapper` or `suit-reference-uri`.
> Therefore, I would propose making these elements optional at the CDDL level.

The SUIT report is designed to be consumed with a manifest. If there
is no reference URI for the manifest and there is no digest of the
manifest, then how can a Recipient of a SUIT Report identify which
manifest to use with the SUIT Report? These two documents are
intimately connected. As I said above, there is an edge case, for a
purely reporting scenario, where the SUIT Report only contains
SUIT_Record_System_Properties. I still think that this leaves a
recipient in the dark about how that software arrived on the device
and who authorised it, so I am reluctant to remove the requirement for
a SUIT_Reference. I believe it is necessary.

> a manifest that lacks a `suit-authentication-wrapper`

This is prohibited by the Manifest Specification:
https://www.ietf.org/archive/id/draft-ietf-suit-manifest-34.html#name-authenticated-manifests
> The SUIT_Digest MUST always be present.

> Am I correct in assuming that entities that encode (sign and/or
> encrypt) a SUIT_Report are considered one of the "Reporting Engine"?

Yes, that is correct. You are right: we should at least have a note
that explains this.

> The appropriate behavior of the Reporting Engine is unclear to me.
Part of the problem is that the SUIT Manifest specification defines
the behaviour of the reporting engine from an API perspective. It only
has two APIs:
* RE_Set_Manifest (URI, Digest)
* RE_Report(ManifestPath, ManifestKey, Offset, SystemParameters,
ResultCode, ReportingPolicy)

RE_Set_Manifest is called once. RE_Report is called for every single
Manifest Command. The other APIs are implementation details as far as
the format is concerned. Remember, the reporting policy is a hint, and
can be overridden by the Reporting Engine. So it needs a chance to
evaluate all command results.

Your approach seems completely reasonable. But it's not part of the
specification, if that makes sense?

> 6. Question: Can suit-parameter-image-size be consumed in
suit-condition-image-match?

Yes, in fact in most scenarios, this is mandatory. However, do
consider https://www.rfc-editor.org/rfc/rfc9124#name-reqsecimgcomplete_digest-wh

> 7. Question: Is suit-report-reason-ok necessary?

It depends on reporting policy. A report that generates system
properties can, if the RE wants to, also generate a SUIT_Record.

> 8. Question: Why does SUIT_Record exist twice?

Good Question! It's because they occupy two logically distinct roles.
The SUIT_Records are a log. The SUIT_Result is a status/failure code.
While we could keep semantics that explain this (the last record in
SUIT_Records is a status/failure result) it moves it into two separate
subtrees of the structure, which would be a problem for a derivative
use or format that extracts just the result.

> 9. Editorial: Some CDDL parts do not match to the Appendix (Full CDDL)

Good point, I'll take a look at this.

> 10. Question: Is suit-record-manifest-id derived from the Component Index of the dependency manifest?

Yes, it is. I'll review the text for that section. It should be
referencing Component Indices.

Your idea for an updated example with components mixed in looks good
to me. I will see about updating the example to match.

> 11. Comment: Experimental SUIT Report feature is added to libcsuit
> <https://github.com/kentakayama/libcsuit> supports SUIT Report
> encoding while processing a manifest.

That's great! Hopefully I can match feature parity with you on that soon.

Best Regards,
Brendan

On Wed, Feb 4, 2026 at 5:34 AM Ken Takayama <[e-mail]> wrote:
>
> Dear draft-ietf-suit-report authors,
>
> While reviewing the CDDL in draft-ietf-suit-report, I noticed that
> some of the extensions might be better defined as optional.
>
> ```diff
> -   $$SUIT_Report_Extensions
> +   * $$SUIT_Report_Extensions
>
> - $$SUIT_Record_Extensions
> + * $$SUIT_Record_Extensions
>
> -   $$SUIT_Capability_Report_Extensions
> +   * $$SUIT_Capability_Report_Extensions
> ```
>
> Best regards,
> Ken
>
> 2025年12月19日(金) 23:38 Ken Takayama <[e-mail]>:
>
> >
> > Dear draft-ietf-suit-report authors,
> >
> > I think this is the final comment from me while implementing SUIT
> > Report encoder.
> >
> > ## 10. Question: Is suit-record-manifest-id derived from the Component
> > Index of the dependency manifest?
> > Since `suit-directive-set-dependency-index` was removed in
> > draft-ietf-suit-trust-domains-01, dependency manifests are treated as
> > components and the dependency-index are combined into a single
> > Component Index space.
> > I believe the draft should clarify whether the "index" used in
> > suit-record-manifest-id refers to the Component Index of the
> > dependency manifest, or to the position within the SUIT_Dependencies
> > map.
> > My preference is the former -- the Component Index -- because this is
> > the index throughout the Command Sequences.
> >
> > If this interpretation is correct, then the index of the dependency
> > manifests start from 0 only when `suit-components` contains no
> > components. Otherwise, the Component Index values of dependency
> > manifests overlap with those of non-dependency components.
> >
> > To avoid this ambiguity, I suggest that the example manifests should
> > include zero or more non-dependency components so that the indexing
> > behavior becomes clearer.
> > <https://datatracker.ietf.org/doc/html/draft-ietf-suit-report-18#section-3-11>
> >
> > Updated example:
> > * Root (manifest-id: [])
> >   - Component 0 (Component Index: 0)
> >   - Dependency A (Component Index: 1, manifest-id: [1])
> >     o Component A0 (Component Index: 0)
> >     o Component A1 (Component Index: 1)
> >     o Dependency AA (Component Index: 2, manifest-id: [1,2])
> >     o Dependency AB (Component Index: 3, manifest-id: [1,3])
> >   - Dependency B (Component Index: 2, manifest-id: [2])
> >     o Component B0 (Component Index: 0)
> >     o Component B1 (Component Index: 1)
> >     o Component B2 (Component Index: 2)
> >     o Dependency BA (Component Index: 3, manifest-id: [2,3])
> >     o Dependency BB (Component Index: 4, manifest-id: [2,3])
> >   - Dependency C (Component Index: 3, manifest-id: [3])
> >     o Dependency CA (Component Index: 0, manifest-id: [2,0])
> >     o Dependency CB (Component Index: 1, manifest-id: [2,1])
> >
> > ## 11. Comment: Experimental SUIT Report feature is added to libcsuit
> > <https://github.com/kentakayama/libcsuit> supports SUIT Report
> > encoding while processing a manifest.
> > For example, while processing the Example 0 in draft-ietf-suit-manifest-34,
> > the Reporting Engine encodes the following protected SUIT_Report:
> > ```
> > 18([
> >   / protected: / << {
> >     / alg / 1: -9 / ESP256 /
> >   } >>,
> >   / unprotected / {
> >     / kid / 4: h'E96788B10B1610ABE478F9CE8DCFE2304C0911DD8CFEADDE25EC30CCB5A7B5AF'
> >   },
> >   / payload: / << / SUIT_Report = / {
> >     / suit-reference / 99: [
> >       / suit-report-manifest-uri: / "",
> >       / suit-report-manifest-digest: / [-16,
> > h'6658EA560262696DD1F13B782239A064DA7C6C5CBAF52FDED428A6FC83C7E5AF']
> >     ],
> >     / suir-report-records / 3: [
> >       / system-property-claims = / {
> >         / system-component-id / 0: [<< 0 >>],
> >         / image-size / 14: 34768
> >       }
> >     ],
> >     / suit-report-result / 4: true
> >   } >>,
> >   / signature: /
> > h'C41DD559CB03811CCFD0DC63B8E0AD79470D6DA746D732708825BB1BAEE7D8F69EA305868827DB33431FF06846C266F96BA3F6F3519B1F7DCB9800E362AD5D63'
> > ])
> > ```
> >
> > NOTE: It reports only the image-size because there is no actual file
> > on my machine.
> > The image-match callback handler receives both image-size and
> > image-digest, first checks the image-size when the file is loaded and
> > then marks it as consumed.
> > The operation fails because the component is not on my machine, but
> > the error is intentionally suppressed for testing purposes.
> > As a result, the suit-report-result is true, and the error cause is
> > not recorded.
> >
> > Best regards,
> > Ken
> >
> > 2025年12月17日(水) 19:20 Ken Takayama <[e-mail]>:
> > >
> > > Dear draft-ietf-suit-report authors,
> > >
> > > Following up on my earlier comments on draft-ietf-suit-report, I would
> > > like to clarify and add some points.
> > >
> > > ## 4. Opinion: Terminology Issue
> > > The draft-ietf-suit-manifest states that the "Reporting Engine"
> > > receives some hints from the SUIT Manifest Processor.
> > > However, draft-ietf-suit-report does not mention this.
> > > Am I correct in assuming that entities that encode (sign and/or
> > > encrypt) a SUIT_Report are considered one of the "Reporting Engine"?
> > >
> > >
> > > ## 5. Opinion: Behavior of the Reporting Engine is unclear
> > > The appropriate behavior of the Reporting Engine is unclear to me.
> > >
> > > Below is my current understanding based on the SUIT Report draft and
> > > the SUIT Manifest draft,
> > > assuming the Reporting Engine encodes the (signed or encrypted)
> > > SUIT_Report as early as possible.
> > > At least six Reporting Engine APIs come to my mind:
> > > - RE_Initialize()
> > > - RE_ManifestDigest()
> > > - RE_ReferenceURI()
> > > - RE_ExtendSystemPropertyClaims()
> > > - RE_ExtendRecord()
> > > - RE_Finalize()
> > >
> > > Flow:
> > > [MP = SUIT Manifest Processor]
> > > 1. Initialize Reporting Engine with RE_Initialize(nonce)
> > >
> > > [RE = Reporting Engine]
> > > 2. Open a CBOR map for SUIT_Report, encode suit-nonce if present, and
> > > optionally encode suit-report-capability-report
> > > RE state: S0. before initialization => S1. initialized
> > >
> > > [MP]
> > > 3. Parse the SUIT_Envelope and extract the SUIT_Digest
> > > 4. Verify it using SUIT_Authentication_Block(s)
> > > 5. If verified, trigger RE_ManifestDigest(digest)
> > > (Question: If not verified, what kind of the SUIT_Report can be produced?)
> > >
> > > [RE]
> > > 6. Store the SUIT_Digest internally (cannot encode it yet because
> > > suit-report-manifest-uri is unresolved)
> > > RE state: S1. initialized => S2. SUIT_Digest stored
> > >
> > > [MP]
> > > 7. Extract and verify the SUIT_Manifest against the digest
> > > 8. process the SUIT_Manifest, extract the suit-report-manifest-uri and
> > > trigger RE_ReferenceURI(reference-uri)
> > > (If it does not exist, null or "" can be passed when the key exceeds 4
> > > = suit-reference-uri)
> > >
> > > [RE]
> > > 9. Encode SUIT_Reference with reference-uri and the stored
> > > SUIT_Digest, then open suit-report-records array
> > > RE state: S2. SUIT_Digest stored => S3. encoding suit-report-record started
> > >
> > > [MP]
> > > 10. Process any SUIT_Command_Sequence
> > > 11. When reporting policy applies, trigger
> > > RE_ExtendSystemPropertyClaims(component-index,
> > > SUIT_Component_Identifier, parameter(s)),
> > > or trigger RE_ExtendRecord(manifest-id, manifest-section,
> > > section-offset, component-index, parameter(s)) on failure
> > >
> > > [RE]
> > > 12. With RE_ExtendSystemPropertyClaims, (encode
> > > SUIT_Component_Identifier for system-property-claim if not already
> > > encoded or the component-index is changed from previous one, and)
> > > append the parameter;
> > > with RE_ExtendRecords, stop encoding system-property-claims and encode
> > > SUIT_Record
> > > RE state: S3. encoding suit-report-record started (or SUIT_Record is
> > > encoded) <=> S4. SUIT_Component identifier is encoded
> > >
> > > [MP]
> > > 13. Before termination (success or error in the final result for the
> > > SUIT Manifest Processor), trigger RE_Finalize(result-code, ,
> > > &encoded_report)
> > >
> > > [RE]
> > > 14. Stop encoding suit-report-records and encode suit-report-result
> > > (True on success, {suit-report-result-*} on failure)
> > > RE state: S3 or S4 => S5. SUIT_Report is encoded
> > > 15. Sign or encrypt if necessary
> > > RE state: S5. SUIT_Report is encoded => S6. finalized
> > >
> > > [MP or RE]
> > > 16. Send the encoded SUIT_Report to the Status Tracker Server (RFC 9019)
> > >
> > > With this flow, the Reporting Engine would have these states:
> > > - Reporting Engine (RE) state
> > >   - S0. before initialization
> > >   - S1. initialized
> > >   - S2. SUIT_Digest stored
> > >   - S3. encoding suit-report-record started (or SUIT_Record is encoded)
> > >   - S4. SUIT_Component identifier is encoded
> > >   - S5. SUIT_Report is encoded
> > >   - S6. finalized
> > > - temporal SUIT_Digest (can be removed if the proposal 3. Better
> > > SUIT_Report encoding is accepted in previous email)
> > > - current component-index
> > > - CBOR encoder
> > > - COSE sender with sign1/mac0/encrypt0 (optional)
> > >
> > >
> > > ## 6. Question: Can suit-parameter-image-size be consumed in
> > > suit-condition-image-match?
> > > This might be a question to section 8.4.9.2 of the draft-ietf-suit-manifest:
> > > <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest#section-8.4.9.2>
> > > It says only the digest is verified, but I think
> > > suit-parameter-image-size can be also compared.
> > > If so, suit-parameter-image-size could be reported in
> > > suit-condition-image-match (and suit-condition-image-not-match).
> > >
> > > For example, Example 0 includes image-size even though neither
> > > directive-ferch nor directive-copy is used:
> > > <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest#name-example-0-secure-boot>
> > >
> > >
> > > ## 7. Question: Is suit-report-reason-ok necessary?
> > > In the previous flow of SUIT Manifest Processor and Reporting Engine,
> > > suit-report-reason-ok seems unnecessary, because SUIT_Report_Reasons
> > > is encoded on error.
> > > When do we use it?
> > >
> > >
> > > ## 8. Question: Why does SUIT_Record exist twice?
> > > It appears in both suit-report-records and suit-report-result.
> > > If I understand correctly, the purpose is for soft-failure in
> > > run-sequence and try-each:
> > > each failure is recorded, but the SUIT Manifest Processor does not terminate.
> > >
> > > Otherwise, could we remove it from suit-report-records to simplify the
> > > Reporting Engine state.
> > >
> > >
> > > ## 9. Editorial: Some CDDL parts do not match to the Appendix (Full CDDL)
> > > <https://datatracker.ietf.org/doc/html/draft-ietf-suit-report-18#section-3-9>
> > > From:
> > > ```
> > > SUIT_Record = [
> > >     suit-record-manifest-id        : [* uint ],
> > >     suit-record-manifest-section   : int,
> > >     suit-record-section-offset     : uint,
> > >     suit-record-component-index    : uint,
> > >     suit-record-properties         : SUIT_Parameters,
> > >     $$SUIT_Record_Extensions
> > > ]
> > > ```
> > > To:
> > > ```
> > > SUIT_Record = [
> > >     suit-record-manifest-id        : [* uint ],
> > >     suit-record-manifest-section   : int,
> > >     suit-record-section-offset     : uint,
> > >     suit-record-component-index    : uint,
> > >     suit-record-properties         : {*$$SUIT_Parameters},
> > >     $$SUIT_Record_Extensions
> > > ]
> > > ```
> > > NOTE: Should the $$SUIT_Record_Extensions optional? ( `*
> > > $$SUIT_Record_Extensions` )
> > >
> > >
> > > <https://datatracker.ietf.org/doc/html/draft-ietf-suit-report-18#section-4-3>
> > > From:
> > > ```
> > > system-property-claims = {
> > >   system-component-id => SUIT_Component_Identifier,
> > >   + SUIT_Parameters,
> > > }
> > > ```
> > > To:
> > > ```
> > > system-property-claims = {
> > >   system-component-id => SUIT_Component_Identifier,
> > >   + $$SUIT_Parameters,
> > > }
> > > ```
> > >
> > > <https://datatracker.ietf.org/doc/html/draft-ietf-suit-report-18#section-4.1-3>
> > > From:
> > > ```
> > > SUIT_Record_System_Properties = {
> > >   * component-id => {
> > >     + SUIT_Parameters,
> > >   }
> > > }
> > > ```
> > > To:
> > > ```
> > > SUIT_Record_System_Properties = {
> > >   * component-id => {
> > >     + $$SUIT_Parameters,
> > >   }
> > > }
> > > ```
> > >
> > > Best regards,
> > > Ken
> > >
> > > 2025年12月16日(火) 11:04 Ken Takayama <[e-mail]>:
> > >
> > > >
> > > > Dear draft-ietf-suit-report authors,
> > > >
> > > > ## 1. "Double-fault" handling
> > > > While encoding or signing a SUIT Report to report an error, another
> > > > error may occur.
> > > > For example: COSE_Sign1 signing failures, CBOR encoding failures, or
> > > > missing mandatory elements for SUIT_Report not parsed by the SUIT
> > > > Manifest Processor.
> > > > In such cases, is it permissible for the manifest processor to return
> > > > a "dummy" pre-encoded SUIT Report instead, though it may not be
> > > > protected?
> > > >
> > > > ## 2. `suit-report-manifest-uri` should not be mandatory
> > > > Since `suit-reference-uri` is an OPTIONAL element in the CDDL of the
> > > > SUIT Manifest,
> > > > I believe `suit-report-manifest-uri` in `SUIT_Reference` should also
> > > > be OPTIONAL.
> > > > https://datatracker.ietf.org/doc/html/draft-ietf-suit-report-18#section-4-5
> > > >
> > > > ## 3. Better SUIT_Report encoding
> > > > Because the `suit-reference` section and its elements are currently
> > > > required in `SUIT_Report`, a SUIT Manifest Processor may be unable to
> > > > encode them when processing a manifest that lacks a
> > > > `suit-authentication-wrapper` or `suit-reference-uri`.
> > > > Therefore, I would propose making these elements optional at the CDDL level.
> > > >
> > > > Current:
> > > > ```cddl
> > > > SUIT_Report = {
> > > >   suit-reference => SUIT_Reference,
> > > > }
> > > > SUIT_Reference = [
> > > >     suit-report-manifest-uri  : tstr,
> > > >     suit-report-manifest-digest : SUIT_Digest,
> > > > ]
> > > > ```
> > > >
> > > > Suggestion A (my preference):
> > > > Move `suit-report-manifest-digest` first and make both
> > > > `SUIT_Reference` and `suit-report-manifest-uri` optional.
> > > > This makes it easier for the SUIT Manifest Processor to encode a
> > > > SUIT_Report during processing:
> > > > 1. open a map for `SUIT_Report`,
> > > > 2. parse the `suit-authentication-wrapper` and extract the
> > > > `SUIT_Digest` (otherwise the `suit-report-reason-cbor-parse` will be
> > > > set -- is this correct?),
> > > > 3. verify it using the following `SUIT_Authentication_Block`s (if none
> > > > can be verified, one of the `suit-report-reason-unauthorized`,
> > > > `suit-report-reason-cose-unsupported` or
> > > > `suit-report-reason-alg-unsupported` will be set),
> > > > 4) add the array as `SUIT_Reference` with key `suit-reference` to the
> > > > map and append the `SUIT_Digest`,
> > > > 5) verify the `suit-manifest` against the digest (question: which
> > > > error should be returned if this fails?),
> > > > 6) process the `SUIT_Manifest` and append the
> > > > `suit-report-manifest-uri` if it exists,
> > > > 7) close the `SUIT_Reference` array.
> > > >
> > > > ```cddl
> > > > SUIT_Report = {
> > > >   ? suit-reference => SUIT_Reference,
> > > > }
> > > > SUIT_Reference = [
> > > >     suit-report-manifest-digest : SUIT_Digest,
> > > >     ? suit-report-manifest-uri  : tstr,
> > > > ]
> > > > ```
> > > >
> > > > Suggestion B:
> > > > Convert `SUIT_Reference` from an array to a map.
> > > > The basic behavior of the SUIT Manifest Processor remains the same as
> > > > described above.
> > > > This requires assigning labels.
> > > >
> > > > ```cddl
> > > > SUIT_Reference = {
> > > >    ? suit-report-manifest-uri  => tstr,
> > > >    ? suit-report-manifest-digest => SUIT_Digest,
> > > > }
> > > > suir-report-manifest-uri = 98 ; TBD
> > > > suit-report-manifest-digest = 97 ; TBD
> > > > ```
> > > >
> > > > Best regards,
> > > > Ken
> > > >
> > > > 2025年12月15日(月) 14:34 Ken Takayama <[e-mail]>:
> > > > >
> > > > > SUIT WG,
> > > > >
> > > > > This is Ken Takayama.
> > > > >
> > > > > I may be mistaken as I have only just begun reading the document
> > > > > deeply and have not started implementing the feature yet, but I would
> > > > > like to share a small piece of feedback.
> > > > >
> > > > > Should the sentence below say “either a COSE_Encrypt0, COSE_Sign1, or
> > > > > COSE_Mac0 structure”?
> > > > >
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-suit-report-18#section-8-4.3.1
> > > > > > Encapsulated within a secure container, such as a COSE structure. In the case of COSE, the container MUST be either a COSE_Encrypt0 or COSE_Sign1 structure. The SUIT_Report MUST be the sole payload, as illustrated by the CDDL fragment below.
> > > > >
> > > > > Since I have just started implementing SUIT Report functionality in
> > > > > libcsuit (https://github.com/kentakayama/libcsuit) I expect I may
> > > > > send additional feedback, either improvements or positive findings, as
> > > > > I progress.
> > > > >
> > > > > Best regards,
> > > > > Ken
>
> _______________________________________________
> Suit mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]