Subject: [Suit] Manifest-07 review

From: Rønningstad, Øyvind <[email-masked]>
Date: Wed, 24 Jun 2020 10:03:26 +0000

Hi guys, here is a review of manifest-07. Mostly small stuff.

Questions:
. Section 6.4: What are the guidelines for extracting the vendor-id, class-id, device-id, or version of a component?
. Suit-condition-component-offset is used in an example, but marked as TBD in its section. I see that it is described in 6.4 as "assert(offsetof(component) == arg)". What are the semantics of "offsetof"?
. Can suit-directive-process-dependency be done on a component, or just on a dependency? Generally, there seems to be some mismatch between the description in 6.4 (which implies that most directives and conditions only apply to a component index) and textual descriptions e.g. in 9.8.4.1 and 9.8.4.2 (which imply that directives and conditions apply to whichever is available of component index and dependency index).
. (It would be very beneficial to make 6.4 "Abstract Machine Description" more prominent, e.g. by linking from the individual section for commands, since 6.4 contains very useful info about how the commands work, and it's hard to discover otherwise.)
. What (if any) are the rules regarding when to perform dependency-resolution, payload-fetch, and install, and when to perform only validate, load, and run?
. suit-manifest-sequence-number: "Each Recipient MUST reject any manifest that has a sequence number lower than its current sequence number." Are there several "current sequence number"s or just one for each SUIT processor. Exactly when is the "current sequence number" updated?
. What should the processor do when waiting on a suit-directive-wait? Can it be interpreted as "try again later", or "busy wait"?
. There are important limitations to what sort of commands can be in suit-common. Could the limitations be reflected in the CDDL? It seems like a natural thing to do, to make the limitations more prominent.
. When processing dependencies, how do we know when to a) expect a signature and b) check the signature on a dependency manifest?
. Did we mean for short payloads to be embeddable in the manifest (I can't find this)? This would be very useful for setting configuration options via SUIT manifests. 
. Is the device-identifier unique for each individual device, or for a collection of devices?	
. Why are suit-directive-set-component-index and suit-directive-set-dependency-index not implemented through set-parameters? Are they subject to the same override mechanics? If not, it might be confusing with suit-parameter-source-component, which seems to be analogous to set-component-index, but might have subtly different behavior because of override mechanics.

Nits:
. Suit-directive-fetch: "manifest-index" is not referred to elsewhere in the document.
. Section 7: Suggested edit in bold: "A digest should always be set using Override Parameters, since this prevents a less-privileged dependent OR dependency from replacing the digest."
. suit-condition-update-authorized seems like it could use some metadata to help determine what is being authorized, e.g. A human readable prompt if user interaction is required, or an identifier if multiple instances of the condition are used in a manifest.

Thanks for the good work,

Øyvind

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 24 Jun 2020 13:29:56 +0000

Øyvind,

Thanks for this review!

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Wednesday, June 24, 2020 6:03 AM
To: suit <[email-masked]>
Subject: [Suit] Manifest-07 review

Questions:
.. Section 6.4: What are the guidelines for extracting the vendor-id, class-id, device-id, or version of a component?
.. Suit-condition-component-offset is used in an example, but marked as TBD in its section. I see that it is described in 6.4 as "assert(offsetof(component) == arg)". What are the semantics of "offsetof"?
.. Can suit-directive-process-dependency be done on a component, or just on a dependency? Generally, there seems to be some mismatch between the description in 6.4 (which implies that most directives and conditions only apply to a component index) and textual descriptions e.g. in 9.8.4.1 and 9.8.4.2 (which imply that directives and conditions apply to whichever is available of component index and dependency index).
.. (It would be very beneficial to make 6.4 "Abstract Machine Description" more prominent, e.g. by linking from the individual section for commands, since 6.4 contains very useful info about how the commands work, and it's hard to discover otherwise.) .. What (if any) are the rules regarding when to perform dependency-resolution, payload-fetch, and install, and when to perform only validate, load, and run?
.. suit-manifest-sequence-number: "Each Recipient MUST reject any manifest that has a sequence number lower than its current sequence number." Are there several "current sequence number"s or just one for each SUIT processor. Exactly when is the "current sequence number" updated?
.. What should the processor do when waiting on a suit-directive-wait? Can it be interpreted as "try again later", or "busy wait"?
.. There are important limitations to what sort of commands can be in suit-common. Could the limitations be reflected in the CDDL? It seems like a natural thing to do, to make the limitations more prominent.
.. When processing dependencies, how do we know when to a) expect a signature and b) check the signature on a dependency manifest?
.. Did we mean for short payloads to be embeddable in the manifest (I can't find this)? This would be very useful for setting configuration options via SUIT manifests. 
.. Is the device-identifier unique for each individual device, or for a collection of devices?	
.. Why are suit-directive-set-component-index and suit-directive-set-dependency-index not implemented through set-parameters? Are they subject to the same override mechanics? If not, it might be confusing with suit-parameter-source-component, which seems to be analogous to set-component-index, but might have subtly different behavior because of override mechanics.

Nits:
.. Suit-directive-fetch: "manifest-index" is not referred to elsewhere in the document.
.. Section 7: Suggested edit in bold: "A digest should always be set using Override Parameters, since this prevents a less-privileged dependent OR dependency from replacing the digest."
.. suit-condition-update-authorized seems like it could use some metadata to help determine what is being authorized, e.g. A human readable prompt if user interaction is required, or an identifier if multiple instances of the condition are used in a manifest.

Øyvind

_______________________________________________
Suit mailing list
[email-masked]
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermire%40nist.gov%7C909e99a025494e915e6008d81825e30f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637285898291416907&amp;sdata=Hww6iMALkbaHZQLb1VeYGCDfb7yrQGbpUbUa%2FD5u4Fo%3D&amp;reserved=0

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 24 Jun 2020 09:35:44 -0400

Are there plans for a standard file naming nomenclature to identify software
objects that contain a suit manifest? 

Today, I use the filename extension to drive an introspection procedure to
generate an SBOM and having a defined filename extension to indicate that a
suit manifest is present would help, otherwise I have to parse each file to
determine which SBOM introspection procedure to invoke.

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Waltermire, David A. (Fed)
Sent: Wednesday, June 24, 2020 9:30 AM
To: Rønningstad, Øyvind <[email-masked]>; suit
<[email-masked]>
Subject: Re: [Suit] Manifest-07 review

Øyvind,

Thanks for this review!

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Wednesday, June 24, 2020 6:03 AM
To: suit <[email-masked]>
Subject: [Suit] Manifest-07 review

Questions:
... Section 6.4: What are the guidelines for extracting the vendor-id,
class-id, device-id, or version of a component?
... Suit-condition-component-offset is used in an example, but marked as TBD
in its section. I see that it is described in 6.4 as
"assert(offsetof(component) == arg)". What are the semantics of "offsetof"?
... Can suit-directive-process-dependency be done on a component, or just on
a dependency? Generally, there seems to be some mismatch between the
description in 6.4 (which implies that most directives and conditions only
apply to a component index) and textual descriptions e.g. in 9.8.4.1 and
9.8.4.2 (which imply that directives and conditions apply to whichever is
available of component index and dependency index).
... (It would be very beneficial to make 6.4 "Abstract Machine Description"
more prominent, e.g. by linking from the individual section for commands,
since 6.4 contains very useful info about how the commands work, and it's
hard to discover otherwise.) .. What (if any) are the rules regarding when
to perform dependency-resolution, payload-fetch, and install, and when to
perform only validate, load, and run?
... suit-manifest-sequence-number: "Each Recipient MUST reject any manifest
that has a sequence number lower than its current sequence number." Are
there several "current sequence number"s or just one for each SUIT
processor. Exactly when is the "current sequence number" updated?
... What should the processor do when waiting on a suit-directive-wait? Can
it be interpreted as "try again later", or "busy wait"?
... There are important limitations to what sort of commands can be in
suit-common. Could the limitations be reflected in the CDDL? It seems like a
natural thing to do, to make the limitations more prominent.
... When processing dependencies, how do we know when to a) expect a
signature and b) check the signature on a dependency manifest?
... Did we mean for short payloads to be embeddable in the manifest (I can't
find this)? This would be very useful for setting configuration options via
SUIT manifests. 
... Is the device-identifier unique for each individual device, or for a
collection of devices?	
... Why are suit-directive-set-component-index and
suit-directive-set-dependency-index not implemented through set-parameters?
Are they subject to the same override mechanics? If not, it might be
confusing with suit-parameter-source-component, which seems to be analogous
to set-component-index, but might have subtly different behavior because of
override mechanics.

Nits:
... Suit-directive-fetch: "manifest-index" is not referred to elsewhere in
the document.
... Section 7: Suggested edit in bold: "A digest should always be set using
Override Parameters, since this prevents a less-privileged dependent OR
dependency from replacing the digest."
... suit-condition-update-authorized seems like it could use some metadata
to help determine what is being authorized, e.g. A human readable prompt if
user interaction is required, or an identifier if multiple instances of the
condition are used in a manifest.

Øyvind

_______________________________________________
Suit mailing list
[email-masked]
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.o
rg%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermire%40nist.go
v%7C909e99a025494e915e6008d81825e30f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%
7C0%7C637285898291416907&amp;sdata=Hww6iMALkbaHZQLb1VeYGCDfb7yrQGbpUbUa%2FD5
u4Fo%3D&amp;reserved=0

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: Brendan Moran <[email-masked]>
Date: Wed, 24 Jun 2020 13:42:09 +0000

The intent is to register a CBOR tag that identifies the manifest envelope. This allows detection of manifests by signature in the first 2-3 bytes. A typical filename extension would be fine. I think the most suitable suggestion would be “.suit” if that suits the working group. We’re past the days of 3 letter extensions now, right?

Best Regards,
Brendan

> On 24 Jun 2020, at 14:35, Dick Brooks <[email-masked]> wrote:
>
> Never trust software, always verify and report! T
> .... Section 6.4: What are the guidelines for extracting the vendor-id,
> .... Suit-condition-component-offset is used in an example, but marked as TBD
> .... Can suit-directive-process-dependency be done on a component, or just on
> .... (It would be very beneficial to make 6.4 "Abstract Machine Description"
> .... suit-manifest-sequence-number: "Each Recipient MUST reject any manifest
> .... What should the processor do when waiting on a suit-directive-wait? Can
> .... There are important limitations to what sort of commands can be in
> .... When processing dependencies, how do we know when to a) expect a
> .... Did we mean for short payloads to be embeddable in the manifest (I can't
> .... Is the device-identifier unique for each individual device, or for a
> collection of devices?
> .... Why are suit-directive-set-component-index and
> .... Suit-directive-fetch: "manifest-index" is not referred to elsewhere in
> the document.
> .... Section 7: Suggested edit in bold: "A digest should always be set using
> .... suit-condition-update-authorized seems like it could use some metadata
> rg%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermire%40nist..go

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 24 Jun 2020 15:48:26 +0200

Are we talking about every "software object" that starts with a CBOR tag 
as defined in this document?

I assume that a manifest in the form of a file can be wrapped or not be 
wrapped in a SUIT envelope. Would that result in the same file extension 
".suit"?

Viele Grüße,

Henk

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Jun 2020 10:01:34 -0400

I think .suit is a very reasonable choice.  We may also want to add a section that registers a media type for the manifest files, which helps with fetching these by HTTP and HTTPS.

Russ

> On Jun 24, 2020, at 9:48 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Are we talking about every "software object" that starts with a CBOR tag as defined in this document?
> 
> I assume that a manifest in the form of a file can be wrapped or not be wrapped in a SUIT envelope. Would that result in the same file extension ".suit"?
> 
> Viele Grüße,
> 
> Henk
>

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 24 Jun 2020 10:22:53 -0400

+1 +1 +1

That would be greatly appreciated - Thanks Russ. 

Thanks,

Dick Brooks

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, June 24, 2020 10:02 AM
To: Brendan Moran <[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] Manifest-07 review

Russ

>>> Are there plans for a standard file naming nomenclature to identify 
>>> software objects that contain a suit manifest?
>>> 
>>> Today, I use the filename extension to drive an introspection 
>>> procedure to generate an SBOM and having a defined filename 
>>> extension to indicate that a suit manifest is present would help, 
>>> otherwise I have to parse each file to determine which SBOM introspection procedure to invoke.
>>> 
>>> Thanks,
>>> 
>>> Dick Brooks
>>> 
>>> .... Section 6.4: What are the guidelines for extracting the 
>>> vendor-id, class-id, device-id, or version of a component?
>>> .... Suit-condition-component-offset is used in an example, but 
>>> marked as TBD in its section. I see that it is described in 6.4 as
>>> .... Can suit-directive-process-dependency be done on a component, 
>>> or just on a dependency? Generally, there seems to be some mismatch 
>>> between the description in 6.4 (which implies that most directives 
>>> and conditions only apply to a component index) and textual 
>>> descriptions e.g. in 9.8.4.1 and
>>> 9.8.4.2 (which imply that directives and conditions apply to 
>>> whichever is available of component index and dependency index).
>>> more prominent, e.g. by linking from the individual section for 
>>> commands, since 6.4 contains very useful info about how the commands 
>>> work, and it's hard to discover otherwise.) .. What (if any) are the 
>>> rules regarding when to perform dependency-resolution, 
>>> payload-fetch, and install, and when to perform only validate, load, and run?
>>> .... suit-manifest-sequence-number: "Each Recipient MUST reject any 
>>> manifest that has a sequence number lower than its current sequence 
>>> number." Are there several "current sequence number"s or just one 
>>> for each SUIT processor. Exactly when is the "current sequence number" updated?
>>> .... What should the processor do when waiting on a 
>>> suit-directive-wait? Can it be interpreted as "try again later", or "busy wait"?
>>> .... There are important limitations to what sort of commands can be 
>>> in suit-common. Could the limitations be reflected in the CDDL? It 
>>> seems like a natural thing to do, to make the limitations more prominent.
>>> .... When processing dependencies, how do we know when to a) expect 
>>> a signature and b) check the signature on a dependency manifest?
>>> .... Did we mean for short payloads to be embeddable in the manifest 
>>> (I can't find this)? This would be very useful for setting 
>>> configuration options via SUIT manifests.
>>> .... Is the device-identifier unique for each individual device, or 
>>> for a collection of devices?
>>> confusing with suit-parameter-source-component, which seems to be 
>>> analogous to set-component-index, but might have subtly different 
>>> behavior because of override mechanics.
>>> 
>>> Nits:
>>> .... Suit-directive-fetch: "manifest-index" is not referred to 
>>> elsewhere in the document.
>>> .... Section 7: Suggested edit in bold: "A digest should always be 
>>> set using Override Parameters, since this prevents a less-privileged 
>>> dependent OR dependency from replacing the digest."
>>> .... suit-condition-update-authorized seems like it could use some 
>>> metadata to help determine what is being authorized, e.g. A human 
>>> readable prompt if user interaction is required, or an identifier if 
>>> multiple instances of the condition are used in a manifest.
>>> 
>>>

---

From: Brendan Moran <[email-masked]>
Date: Wed, 24 Jun 2020 14:24:52 +0000

I’m not certain what *we* are talking about. *I* am talking about SUIT_Envelope or, to be more precise, SUIT_Envelope_Tagged (that is #6.TBD(SUIT_Envelope)). I think that SUIT_Envelope_Tagged could have a “.suit” file name extension. I think it’s probably a bad idea to have SUIT_Manifest floating around on your system without the envelope or a signature. Maybe you could add a COSE_Sign to it. Then, you might want a “.cose” file name extension.

Brendan

On 24 Jun 2020, at 14:48, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Viele Grüße,

Henk

On 24.06.20 15:42, Brendan Moran wrote:
The intent is to register a CBOR tag that identifies the manifest envelope. This allows detection of manifests by signature in the first 2-3 bytes. A typical filename extension would be fine. I think the most suitable suggestion would be “.suit” if that suits the working group. We’re past the days of 3 letter extensions now, right?
Best Regards,
Brendan
On 24 Jun 2020, at 14:35, Dick Brooks <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Dick Brooks

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Waltermire, David A. (Fed)
Sent: Wednesday, June 24, 2020 9:30 AM
To: Rønningstad, Øyvind <[email-masked]>; suit
<[email-masked]>

Øyvind,

Thanks for this review!

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Wednesday, June 24, 2020 6:03 AM
To: suit <[email-masked]>
Subject: [Suit] Manifest-07 review

Questions:

Nits:

Øyvind

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 24 Jun 2020 10:32:42 -0400

I would find it ideal, for my SAG-PM risk assessment logic, to have the suit manifest digitally signed and to have that signed manifest contained in a digitally signed software object so that the two are forever linked in this “virtual blockchain relationship”.

Thanks,

Dick Brooks

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[email-masked]> [email-masked]

Tel: +1 978-696-1788

From: Brendan Moran <[email-masked]> 
Sent: Wednesday, June 24, 2020 10:25 AM
To: Henk Birkholz <[email-masked]>
Cc: Dick Brooks <[email-masked]>; suit <[email-masked]>; Waltermire, David A. (Fed) <david.waltermire=[email-masked]>
Subject: Re: [Suit] Manifest-07 review

Brendan

On 24 Jun 2020, at 14:48, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Viele Grüße,

Henk

On 24 Jun 2020, at 14:35, Dick Brooks <[email-masked] <mailto:[email-masked]> > wrote:

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: [email-masked] <mailto:[email-masked]> 
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked] <mailto:[email-masked]> > On Behalf Of Waltermire, David A. (Fed)
Sent: Wednesday, June 24, 2020 9:30 AM
To: Rønningstad, Øyvind <[email-masked] <mailto:[email-masked]> >; suit
<[email-masked] <mailto:[email-masked]> >
Subject: Re: [Suit] Manifest-07 review

Øyvind,

Thanks for this review!

Dave

-----Original Message-----
From: Suit <[email-masked] <mailto:[email-masked]> > On Behalf Of Rønningstad, Øyvind
Sent: Wednesday, June 24, 2020 6:03 AM
To: suit <[email-masked] <mailto:[email-masked]> >
Subject: [Suit] Manifest-07 review

Questions:

Nits:

Øyvind

[email-masked] <mailto:[email-masked]> 

_______________________________________________
Suit mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/suit

_______________________________________________
Suit mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/suit

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
Suit mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/suit

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Jun 2020 14:39:05 +0000

Dick,

the confusion in the discussion below has its origin in the way how the CDDL elements are called. The “envelope” is the wrapper around the manifest, which contains the digital signature. The signature covers a number of things, including the hash of the software/firmware.

Ignoring all the CDDL language it pretty much does what you are describing. On top of that there is also the option to use encryption.

Ciao
Hannes

From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Wednesday, June 24, 2020 4:33 PM
To: Brendan Moran <[email-masked]>; 'Henk Birkholz' <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Waltermire, David A. (Fed)' <david.waltermire=[email-masked]>
Subject: Re: [Suit] Manifest-07 review

Thanks,

Dick Brooks
Never trust software, always verify and report!<https://reliableenergyanalytics.com/products> ™
http://www.reliableenergyanalytics.com<http://www.reliableenergyanalytics.com/>
Email: [email-masked]<mailto:[email-masked]>
Tel: +1 978-696-1788

From: Brendan Moran <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 24, 2020 10:25 AM
To: Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Cc: Dick Brooks <[email-masked]<mailto:[email-masked]>>; suit <[email-masked]<mailto:[email-masked]>>; Waltermire, David A. (Fed) <david.waltermire=[email-masked]<mailto:david.waltermire=[email-masked]>>
Subject: Re: [Suit] Manifest-07 review

Brendan

Viele Grüße,

Henk

Thanks,

Dick Brooks

Never trust software, always verify and report! T
http://www.reliableenergyanalytics.com
Email: [email-masked]<mailto:[email-masked]>
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Waltermire, David A. (Fed)
Sent: Wednesday, June 24, 2020 9:30 AM
To: Rønningstad, Øyvind <[email-masked]<mailto:[email-masked]>>; suit
<[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Manifest-07 review

Øyvind,

Thanks for this review!

Dave

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Rønningstad, Øyvind
Sent: Wednesday, June 24, 2020 6:03 AM
To: suit <[email-masked]<mailto:[email-masked]>>
Subject: [Suit] Manifest-07 review

Questions:

Nits:

Øyvind

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Jun 2020 11:08:02 -0400

I was talking about the file extension for a signed manifest.

Russ

> On Jun 24, 2020, at 10:24 AM, Brendan Moran <[email-masked]> wrote:
> 
>> On 24 Jun 2020, at 14:48, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On 24 Jun 2020, at 14:35, Dick Brooks <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/>

---

From: Brendan Moran <[email-masked]>
Date: Tue, 30 Jun 2020 10:35:44 +0000

Hi Øyvind,

Thank you for the thorough review!

Here is the pull request for your comments: https://github.com/suit-wg/manifest-spec/pull/26

Best Regards,
Brendan

On 24 Jun 2020, at 11:03, Rønningstad, Øyvind <[email-masked]<mailto:[email-masked]>> wrote:

Questions:

I’m not sure I understand the context of the question. Who is performing the extraction? And from what? I’m going to assume that you are looking for guidelines for what the parser should do to find the local values that it matches against. If that is not correct, then please disregard the paragraph below!

The extraction of vendor-id, class-id, device-id, and component-id are application specific. They may be coded into the device’s firmware image. They may be coded into some metadata about the component. They may be stored within or alongside a security policy such, as an ACL, that the parser uses to validate the manifest actions. They may also be stored in a database that the device uses for generic configuration. Of these options, I have seen both the hard-coded option and the config-database option deployed. I could add some guidance to the text; would that be helpful?

There is a clarification open in a PR on GitHub here: https://github.com/suit-wg/manifest-spec/pull/25/files#diff-4af21d7ed1750009d053675328dd1b85R869
Is it clear enough, or should I provide more precise semantics?

Directives and conditions apply to either a component OR a dependency. I will clarify that.

.. (It would be very beneficial to make 6.4 "Abstract Machine Description" more prominent, e.g. by linking from the individual section for commands, since 6.4 contains very useful info about how the commands work, and it's hard to discover otherwise.)

Good idea.

.. What (if any) are the rules regarding when to perform dependency-resolution, payload-fetch, and install, and when to perform only validate, load, and run?

Section 4.2: Update Workflow Model, covers this. Is there a way that I could make this clearer?

The most important sequence number is the one in the root manifest because it is used by the bootloader/updater to decide whether or not to process any manifests in a tree.

Beyond that, it seems to me that rollback protection should extend to individual components. This is to make sure that the signer of the root manifest cannot force the rollback of a leaf component. Maybe sequence number should be a component parameter? I don’t think so, but I’m open to suggestions!

I don’t think this needs to be mandated in the specification. Any of these options would be acceptable. The intent was reactive: the manifest processing should resume or restart when the specified event occurs.

I think this is reasonable. I’ll make a more restrictive CDDL for Common.

This comes down to an ACL. The root manifest MUST be signed. Other signatures are only necessary where the authority of the root manifest signer is inadequate to confer the rights required to satisfy the device’s ACL.

Yes, this is absolutely intended. There is a discussion of size tradeoffs present in the Information Model. I’ve added a block of text to the manifest template section to explain how to handle this.

Device identifiers were intended to be unique per device, but we found little use for them in firmware update in general. Because of this, they are not well-defined in the specification. If there is a desire for tighter refinement of Device IDs, then please let me know.

Set Component Index and Set Dependency Index effectively define which set of parameters to use. Because of this, they cannot be parameters, which is why they are separate. I do wonder if we could reduce this complexity slightly by changing the name to “set current” and making dependencies to negative numbers. It might also make “set source component” clearer, since it is only used to define the origin of a suit-directive-copy operation.

Nits:

Fixed

Fixed

The original intent of suit-condition-update-authorized was to use a priority identifier (suit-parameter-update-priority) to provide an arbitrating applicaiton to determine whether to allow the update to proceed. The rough idea was that reliability and security fixes might be worth halting a device, while new features might be declined until later.

It sounds like you are discussing a new use-case that requires additional information. We could change suit-parameter-update-priority from uint to:

{
? identifier => int,
? priority => uint,
? description => tstr,
}

Or similar. This is one case where it might be appropriate to include text outside the text section if it’s to be used for on-device user interaction.

Øyvind