Subject: [Suit] SUIT Charter: Firmware Server Discovery and Download Mechanism

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 22 Nov 2017 15:29:26 -0800

Hi,

I would like to propose additions to charter on scoping the work for
firmware server discovery and mechanism to download the same. This is very
important for interoperability and needed to make this work under several
controlled IOT deployments. IIRC, this was one of the updates that was
agreed upon during BOF discussions.

In this regard, the current charter says

"""

A firmware update solution consists of several components, including:

- A mechanism to transport firmware images to compatible devices.

- A manifest that provides meta-data about the firmware image (such as a
firmware package identifier, the hardware the package needs to run, and
dependencies on other firmware packages), as well as cryptographic
information for protecting the firmware image in an end-to-end fashion.

- The firmware image itself.

"""

I would like to propose following addition to the above list

   -

   Mechanisms to discover new firmware is available and the location to
   download it from

Cheers
Suhas Nandakumar

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Nov 2017 18:46:07 -0500

> *   Mechanisms to discover new firmware is available and the location
    > to download it from

I'm actually okay with this in the charter, provided that we don't invent
anything new.   I can imagine doint this with CoAP OBSERVE, DNS-SD, HTTP requests,
and I'm sure I'll think of four more in a minute.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 22 Nov 2017 15:50:53 -0800

Hi Micheal,

 My thinking was same on not inventing new mechanism and re-use existing
ones.

Cheers
Suhas

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 07:59:05 +0000

Hi Suhas, Hi Michael,

the problem is the slippery slope here: as mentioned on the mailing list (not by me) it is not only about discovering the server but very quickly you are talking about "how do I push firmware updates to devices (instead of just polling)", "how do I learn what capabilities the device has (since the server wants to offer the appropriate firmware to the device)", "how do get information about the current state of the firmware update (has it been downloaded already, has the device successfully replaced the firmware, etc.)", "can I reset the device to a previous version of the firmware that is already on the device", "how much flash space is still left on the device", etc.

Some standardization work has been done in this field already, which I had pointed out in previous email discussions.

I am wondering why you don't create your own working group just to work on this topic. This would help to create more focused work.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 23 November 2017 00:46
To: Suhas Nandakumar
Cc: [email-masked]
Subject: Re: [Suit] SUIT Charter: Firmware Server Discovery and Download Mechanism

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

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: Thu, 23 Nov 2017 10:23:44 +0100

Hello,

I am not surprised that people expect a whole work-flow to be in scope 
if text, such as "secure firmware update mechanism", is in the charter. 
Maybe we just prerequisite enrollment, or imprint, or "zerotouch" 
solutions? Maybe we recommend a best practice?

I would recommend to elaborate on "A mechanism to transport firmware 
images to compatible devices", highlighting the scope of the "mechanism".

Viele Grüße,

Henk

On 11/23/2017 08:59 AM, Hannes Tschofenig wrote:
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 10:09:52 +0000

Hi Henk,

the purpose of the current charter is to focus only on a subset of the listed topics, namely the manifest format.
Hence, the other parts (which are not in scope) are not described in great detail.

For this reason, I have suggested to Suhas to propose his own working group that focuses on the topic of "mechanism to transport firmware images to compatible devices".

It is not uncommon to split work between working groups.

I would prefer to get started soon rather than continuing this discussion for months without actually making any real progress. For this exact reason I argued to have a more focused charter. I may be hard to believe but some companies are actually interested in bringing a standardized manifest format to the market.

Regarding the best possible name for a group: I really don’t care. I didn't care when we changed the name from FUD to SUIT and I will not care if we change it again. I care about making progress on the technical front. I want to sit with others at the Hackathon in London and work on some code. I also want an interim meeting before the London IETF meeting to meet some of the other folks working on IoT OSs / bootloaders.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: 23 November 2017 10:24
To: [email-masked]
Subject: Re: [Suit] SUIT Charter: Firmware Server Discovery and Download Mechanism

Hello,

I am not surprised that people expect a whole work-flow to be in scope if text, such as "secure firmware update mechanism", is in the charter.
Maybe we just prerequisite enrollment, or imprint, or "zerotouch"
solutions? Maybe we recommend a best practice?

I would recommend to elaborate on "A mechanism to transport firmware images to compatible devices", highlighting the scope of the "mechanism".

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 Nov 2017 12:06:39 +0100

Hello Hannes,

tl;dr I though the consensus was going into the direction of a small 
list of formats. I consider this to be correct unless consensus shows 
otherwise.

The remainder of this email are just observations:

This statement

On 11/23/2017 11:09 AM, Hannes Tschofenig wrote:
> I may be hard to believe but some companies are actually interested in bringing a standardized manifest format to the market.

in combination with these statements

On 11/23/2017 10:01 AM, Hannes Tschofenig wrote:
> There is separate text in the charter that says the group will pick one or multiple encoding formats.

On 11/23/2017 09:09 AM, Hannes Tschofenig wrote:
> Format here means having an ASN.1, XML, JSON, CBOR, etc. encodings of the manifest (+ the appropriate security mechanisms).

seem to contradict each other?

Either there is a standardized manifest format, or there are multiple 
based on the same data model? Also including ASN.1 in the list is 
somehow confusing to me. If we are talking about format here, I think 
ASN.1 does not fit that list.

And it might also sound surprising, but because some companies (e.g. a 
few that rely on SOTA) are interested in to market solutions, we started 
to address this in drafts before the first TEEP BoF. Now that TEEP is 
emerging, we are splitting the work wrt firmware, and suspended some of 
it to wait for TEEP manifest definition output in order to retain 
interoperability - which is effectively a delay already (but addressing 
a bigger group of stakeholder seems vital, so... viable & necessary).

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Nov 2017 12:22:17 +0100

> I am wondering why you don't create your own working group just to work on this topic. This would help to create more focused work.

Or use an existing one.  SUIT would be the wrong one, as it focuses on securely authorizing firmware updates, although many of the properties conveyed in a SUIT manifest will be important for discovery, too.

LWM2M uses CoAP for firmware transfer.
If CoAP (or the CoRE discovery mechanisms) have gaps or shortcomings for applications that need to do firmware transfer, I think the CoRE WG would be interested to hear about that.  A draft not unlike draft-birkholz-yang-push-coap-problemstatement would be wonderful to prime this discussion.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 15:27:15 +0000

Hi Henk,

> tl;dr I though the consensus was going into the direction of a small list of formats. I consider this to be correct unless consensus shows otherwise.

[Hannes] That would be good. But let's see when we get to the point of selecting.

This statement

Either there is a standardized manifest format, or there are multiple based on the same data model? Also including ASN.1 in the list is somehow confusing to me. If we are talking about format here, I think
ASN.1 does not fit that list.

[Hannes] I don't see the contradiction. When we submitted our initial draft version, which described a solution based on ASN1./DER + CMS, some folks said "I want JSON/JOSE" and yet others said "I want CBOR/COSE". Hence, the charter text changed by delaying the decision to a later time in the working group. What matters ultimately is what one has to implement rather than what clever intermediate language we use or how we structure documents.

And it might also sound surprising, but because some companies (e.g. a few that rely on SOTA) are interested in to market solutions, we started to address this in drafts before the first TEEP BoF. Now that TEEP is emerging, we are splitting the work wrt firmware, and suspended some of it to wait for TEEP manifest definition output in order to retain interoperability - which is effectively a delay already (but addressing a bigger group of stakeholder seems vital, so... viable & necessary).

[Hannes] I am not sure I understood this statement. The Open Trust Protocol, which is the only solution so far submitted to the TEEP group, does not define a manifest format. At the TEEP BOF folks argued that it would be a good idea to re-use the manifest format from SUIT in TEEP but that hasn't been done so far (although I think it is a good idea).

Ciao
Hannes

Viele Grüße,

Henk

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 Nov 2017 07:48:17 -0800

Hello Hannes,

 please see responses inline.

On Wed, Nov 22, 2017 at 11:59 PM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi Suhas, Hi Michael,
>
> the problem is the slippery slope here: as mentioned on the mailing list
> (not by me) it is not only about discovering the server but very quickly
> you are talking about "how do I push firmware updates to devices (instead
> of just polling)", "how do I learn what capabilities the device has (since
> the server wants to offer the appropriate firmware to the device)", "how do
> get information about the current state of the firmware update (has it been
> downloaded already, has the device successfully replaced the firmware,
> etc.)", "can I reset the device to a previous version of the firmware that
> is already on the device", "how much flash space is still left on the
> device", etc.
>
>
I think we are mixing different things here. What I am proposing is a need
to discover the location of the firmware server that has the manifest and
the image, when the device is ready to upgrade  (say, using polling, for
example)
The above list of things you have is way more complicated than what is
being asked. I think we shouldn't mix "firmware server location discovery"
with "capabilities discovery or negotiation mechanism"

> Some standardization work has been done in this field already, which I had
> pointed out in previous email discussions.
>
> I am wondering why you don't create your own working group just to work on
> this topic. This would help to create more focused work.
>
> Ciao
> Hannes
>
> 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: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 16:09:46 +0000

Hi Suhas,

I think we are mixing different things here. What I am proposing is a need to discover the location of the firmware server that has the manifest and the image, when the device is ready to upgrade  (say, using polling, for example)
The above list of things you have is way more complicated than what is being asked. I think we shouldn't mix "firmware server location discovery" with "capabilities discovery or negotiation mechanism"

But there are also other people in this and they have raised additional ideas. That’s the slippery slope.

Ciao
Hannes

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 Nov 2017 17:21:01 +0100

Oh Im sorry, I was confusing TEEP and SUIT again... my fault! :)

So please %s/TEEP/SUIT/g

That said, we added a firmware resource collection to the Concise 
Software Identifier draft in early February this year, which enables 
this document type to be used as a (Reference Integrity Measurement) 
Manifest and/or Container for firmware components.

When the TEEP BoF formed, we separated that part from the core data 
definition and moved it as an extension data definition into an appendix 
of the same draft in expectation of more input.

As we aim for WGLC in December this year (and there will be no decisions 
on firmware related content available until then for sure, 
unfortunately), we will now only include a minimal set of core 
attributes about firmware resources in the core document and create 
another draft that will extend this resource collection in order to 
become a TEEP conform representation later on.

Viele Grüße,

Henk

p.s.

The contradiction I see is that you could use ASN.1 (which is not a 
format/encoding - which I was trying to hint at wrt your list of 
formats, but Carsten was way more elaborate as me on that topic as I 
just saw) in a CMS scenario, but cannot (only) use ASN.1, if you want to 
accommodate more than encodings that are typically defined via the ASN.1 
data model language.

Typically, you (have to / should?) decide on a "clever intermediate 
language", if you do the latter, or am I missing something here? You 
could use multiple languages at once - I guess - and try to keep them 
aligned during the design period of the vocabulary, but I would not like 
to be the person who has to do that.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 Nov 2017 17:26:06 +0100

And again... I meant SUIT, this now seems to be stuck in my head *sigh*

On 11/23/2017 05:21 PM, Henk Birkholz wrote:
>>> I may be hard to believe but some companies are actually interested 
>>> in bringing a standardized manifest format to the market.
>>
>>> Format here means having an ASN.1, XML, JSON, CBOR, etc. encodings of 
>>> the manifest (+ the appropriate security mechanisms).
>>
>> [Hannes] I don't see the contradiction. When we submitted our initial 
>> draft version, which described a solution based on ASN1./DER + CMS, 
>> some folks said "I want JSON/JOSE" and yet others said "I want 
>> CBOR/COSE". Hence, the charter text changed by delaying the decision 
>> to a later time in the working group. What matters ultimately is what 
>> one has to implement rather than what clever intermediate language we 
>> use or how we structure documents.
>>
>> few that rely on SOTA) are interested in to market solutions, we 
>> started to address this in drafts before the first TEEP BoF. Now that 
>> TEEP is emerging, we are splitting the work wrt firmware, and 
>> suspended some of it to wait for TEEP manifest definition output in 
>> order to retain interoperability - which is effectively a delay 
>> already (but addressing a bigger group of stakeholder seems vital, 
>> so... viable & necessary).
>>
>> [Hannes] I am not sure I understood this statement. The Open Trust 
>> Protocol, which is the only solution so far submitted to the TEEP 
>> group, does not define a manifest format. At the TEEP BOF folks argued 
>> that it would be a good idea to re-use the manifest format from SUIT 
>> in TEEP but that hasn't been done so far (although I think it is a 
>> good idea).
>>
>> Ciao
>> Hannes
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 16:29:53 +0000

Hi Henk,

Maybe you need to explain what you are doing with your Concise Software Identifier draft and who the target audience was for it.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: 23 November 2017 17:26
To: [email-masked]
Subject: Re: [Suit] SUIT Charter: Firmware Server Discovery and Download Mechanism

On 11/23/2017 05:21 PM, Henk Birkholz wrote:
> definition and moved it as an extension data definition into an
> appendix of the same draft in expectation of more input.
>
> As we aim for WGLC in December this year (and there will be no
> decisions on firmware related content available until then for sure,
> just saw) in a CMS scenario, but cannot (only) use ASN.1, if you want
> to accommodate more than encodings that are typically defined via the
> ASN.1 data model language.
>
> aligned during the design period of the vocabulary, but I would not
> like to be the person who has to do that.
>
>
>
>>> list of formats. I consider this to be correct unless consensus
>>> shows otherwise.
>>
>>> Format here means having an ASN.1, XML, JSON, CBOR, etc. encodings
>>> of the manifest (+ the appropriate security mechanisms).
>>
>> And it might also sound surprising, but because some companies (e.g.
>> a few that rely on SOTA) are interested in to market solutions, we
>> group, does not define a manifest format. At the TEEP BOF folks
>> argued that it would be a good idea to re-use the manifest format
>> from SUIT in TEEP but that hasn't been done so far (although I think
>> it is a good idea).
>>
>> Ciao
>> Hannes
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 Nov 2017 08:32:51 -0800

> ideas. That’s the slippery slope.

As long as we separate the concerns and ask for consensus , it is not a
slippery slope. From BOF discussions, there was more support for former
than the latter, IIRC.

Thanks
Suhas

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 16:38:54 +0000

Ø  As long as we separate the concerns and ask for consensus , it is not a slippery slope. From BOF discussions, there was more support for former than the latter, IIRC.

Of course, that was only the view of the BOF participants. This needs to be re-confirmed with the participants on the list of which many have not been able to travel to Singapore.

In any case, I agree with Carsten that you should re-use an existing working group. I am also in favour of doing the discovery work (or whatever this turns into) in a new working group.

Ciao
Hannes

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 Nov 2017 18:05:36 +0100

Hm... if that is not clear by reading the draft, I would very welcome a 
review, Hannes!

Software Identifiers (SWID) are documents that provide metadata about 
software components. The traditional audience (and I mean "draft 
readers", not SWID consumers) are the entities creating and or 
distributing software to be installed on (composite) system entities.

Some more detail:

SWID documents can be created by the manufacturer/vendor/distributor and 
can be signed (CoSWID also be encrypted). If they include, for examples 
hash-values about the software components and are signed they can 
provide so called "golden measurements"/"well known values" -> reference 
integrity measurements manifests (RIM manifests). In general, they can 
express a multitude of additional metadata (e.g. various types of 
versions, the roles of the creator or issuer, etc.), and semantic 
dependencies between software components (e.g. patches, requires, 
supersedes, etc.), as well as the different forms in which software 
components exist in (installation package, installed, associated with 
license, even running). SWID documents can also be created by "everyone 
else", e.g. by 3rd party products on the system entities - and therefore 
can compose Evidence.

StrongSwan, for example, an open source IPSec VPN solution 
(https://www.strongswan.org/), includes a SWID generator on the client 
side to provide evidence for network access control.

There are various usage scenarios - one of them: a Firmware Update Manifest.

SWID are defined by ISO (19770-2:2015 Software Identification Tags). 
There is a freely available schema for XML encoding 
(http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd) and a 
guidance document of how to use them by NIST 
(http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf). Concise 
Software Identifier use CBOR/CDDL instead of XML/XSD, include 
clarification provided by NIST about firmware and signatures, reduce 
some ambiguity that is found in the XSD, etc 
(https://github.com/sacmwg/draft-ietf-sacm-coswid).

Viele Grüße,

Henk

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 17:54:54 +0000

Hi Henk,

Give me a few days to digest this info and to read the referenced documents. I have not paid attention to the SACM group since I wasn't aware that it has anything to do with IoT.

Ciao
Hannes

-----Original Message-----
From: Henk Birkholz [mailto:[email-masked]]
Sent: 23 November 2017 18:06
To: Hannes Tschofenig; [email-masked]
Subject: Re: [Suit] SUIT Charter: Firmware Server Discovery and Download Mechanism

Hm... if that is not clear by reading the draft, I would very welcome a review, Hannes!

Software Identifiers (SWID) are documents that provide metadata about software components. The traditional audience (and I mean "draft readers", not SWID consumers) are the entities creating and or distributing software to be installed on (composite) system entities.

Some more detail:

SWID documents can be created by the manufacturer/vendor/distributor and can be signed (CoSWID also be encrypted). If they include, for examples hash-values about the software components and are signed they can provide so called "golden measurements"/"well known values" -> reference integrity measurements manifests (RIM manifests). In general, they can express a multitude of additional metadata (e.g. various types of versions, the roles of the creator or issuer, etc.), and semantic dependencies between software components (e.g. patches, requires, supersedes, etc.), as well as the different forms in which software components exist in (installation package, installed, associated with license, even running). SWID documents can also be created by "everyone else", e.g. by 3rd party products on the system entities - and therefore can compose Evidence.

StrongSwan, for example, an open source IPSec VPN solution (https://www.strongswan.org/), includes a SWID generator on the client side to provide evidence for network access control.

SWID are defined by ISO (19770-2:2015 Software Identification Tags).
There is a freely available schema for XML encoding
(http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd) and a guidance document of how to use them by NIST (http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf). Concise Software Identifier use CBOR/CDDL instead of XML/XSD, include clarification provided by NIST about firmware and signatures, reduce some ambiguity that is found in the XSD, etc (https://github.com/sacmwg/draft-ietf-sacm-coswid).

Viele Grüße,

Henk

On 11/23/2017 05:29 PM, Hannes Tschofenig wrote:
>>>> tl;dr I though the consensus was going into the direction of a
>>>> small list of formats. I consider this to be correct unless
>>>> consensus shows otherwise.
>>>
>>> Either there is a standardized manifest format, or there are
>>> multiple based on the same data model? Also including ASN.1 in the
>>> list is somehow confusing to me. If we are talking about format
>>> here, I think
>>> [Hannes] I don't see the contradiction. When we submitted our
>>> initial draft version, which described a solution based on ASN1./DER
>>> + CMS, some folks said "I want JSON/JOSE" and yet others said "I
>>> want CBOR/COSE". Hence, the charter text changed by delaying the
>>> decision to a later time in the working group. What matters
>>> ultimately is what one has to implement rather than what clever
>>> intermediate language we use or how we structure documents.
>>>
>>> started to address this in drafts before the first TEEP BoF. Now
>>> that TEEP is emerging, we are splitting the work wrt firmware, and
>>> the contents to any other person, use it for any purpose, or store
>>> or copy the information in any medium. Thank you.
>>>
>>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 12:58:26 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > the problem is the slippery slope here: as mentioned on the mailing
    > list (not by me) it is not only about discovering the server but very
    > quickly you are talking about "how do I push firmware updates to
    > devices (instead of just polling)", "how do I learn what capabilities

That's why we argue about the charter now and not leave it open.

    > I am wondering why you don't create your own working group just to work
    > on this topic. This would help to create more focused work.

If we would like the same device to be deployable and upgradeable in
unmanaged (call home to vendor) and air-gap firewall situations, then we had
better not bake in the update URL.

Given that the updates are properly signed from an authorized entity, it
doesn't matter where they come from.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 Nov 2017 18:59:25 +0100

Hello Hannes,

if you (or - by any means - anyone interested) find the time, please 
have a look at the editor's version found at github. Thank you!

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 13:01:36 -0500

Carsten Bormann <[email-masked]> wrote:
    > If CoAP (or the CoRE discovery mechanisms) have gaps or shortcomings
    > for applications that need to do firmware transfer, I think the CoRE WG
    > would be interested to hear about that.  A draft not unlike
    > draft-birkholz-yang-push-coap-problemstatement would be wonderful to
    > prime this discussion.

Carsten, the discovery mechanism might be as simple as stating what
parameters to use for the CoRE discovery process.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Nov 2017 18:01:39 +0000

Hi Michael,

None of this answers the question why you are not doing your discovery work in one of the existing groups (CORE, DHC, ...) or create a new working group.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 23 November 2017 18:58
To: [email-masked]
Subject: Re: [Suit] SUIT Charter: Firmware Server Discovery and Download Mechanism

    > on this topic. This would help to create more focused work.

If we would like the same device to be deployable and upgradeable in unmanaged (call home to vendor) and air-gap firewall situations, then we had better not bake in the update URL.

Given that the updates are properly signed from an authorized entity, it doesn't matter where they come from.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 Nov 2017 19:15:43 +0100

And to add why this work is done in SACM. There are a lot more reasons 
than "IoT" to use a concise representation.

The RIM manifests of software components (especially those deployed in 
file systems) can become quite... extensive. In some usage scenarios it 
is therefore useful, to just reduce the size of the data in motion, e.g. 
TEE attestations of mobile phones or thousands of VNF in a cloud domain.

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 15:46:39 -0500

Henk Birkholz <[email-masked]> wrote:
    > SWID are defined by ISO (19770-2:2015 Software Identification Tags). There is
    > a freely available schema for XML encoding
    > (http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf). Concise Software
    > Identifier use CBOR/CDDL instead of XML/XSD, include clarification provided
    > by NIST about firmware and signatures, reduce some ambiguity that is found in
    > the XSD, etc (https://github.com/sacmwg/draft-ietf-sacm-coswid).

Very cool, thank for posting this.
I was unaware of this work.

It seems like COSWID is so close to the manifest that it should be extended
rather than replaced.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Nov 2017 15:55:25 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > None of this answers the question why you are not doing your discovery
    > work in one of the existing groups (CORE, DHC, ...) or create a new
    > working group.

Because we don't to invent a new discovery protocol.
For that we might need a new WG.
We just want to *use* one in an standard way.
It could be as simple as multicast CoAP for /.well-known/core?rt=suit,
or use DNS-SD.

This might need an IANA action for instance, or we might need to declare a
category of service names.  And perhaps how to interpret the results.

Here, for instance, is the text from BRSKI about discovery using DNS-SD:

   The Pledge MAY perform DNS-based Service Discovery [RFC6763] over
   Multicast DNS [RFC6762] searching for the service
   "_bootstrapks._tcp.local.".

{In fact, that's optional, we use GRASP discovery normatively}
That's it (well, we go on a bunch about congestion concerns, and then IPv4
considerations..., but that's all informative)

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Nov 2017 21:58:16 -0700

> On Nov 22, 2017, at 4:46 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

I'm in favor of using one of those ( or one of the other likely candidates ). I think this is much more important for real world deployments than things like multiple signatures and we have lots of experience with actual systems that do this. This is also one of the areas that actually needs standardization to have interoperable systems vs something like the manifest which is more "here is a nice well reviewed design you can use".