Subject: [Suit] Manifest Formats

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

Hi,

Current charter says

""" A lower number of formats is preferred to reduce code size for
supporting decoders on devices receiving a manifest and to maximize
interoperability of solutions

"""

I don’t think this is applicable since a device will support just one
format, The multiplicity of the formats is needed on the Firmware server to
support devices with different capabilities on the manifest encoding
format. This comment in the charter seems incorrect.

Cheers

Suhas Nandakumar

---

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

Hi Suhas,

Do you agree that having multiple formats will cause additional pain and lower interoperability?

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 23 November 2017 00:41
To: [email-masked]
Subject: [Suit] Manifest Formats

Hi,

Current charter says

""" A lower number of formats is preferred to reduce code size for supporting decoders on devices receiving a manifest and to maximize interoperability of solutions

"""

I don’t think this is applicable since a device will support just one format, The multiplicity of the formats is needed on the Firmware server to support devices with different capabilities on the manifest encoding format. This comment in the charter seems incorrect.

Cheers

Suhas Nandakumar

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: Carsten Bormann <[email-masked]>
Date: Thu, 23 Nov 2017 09:01:37 +0100

I’m not Suhas, but I’d like to point out that while this is trivially true, it may also be trivially irrelevant, as demonstrated by a sentence like:

> having both UDP and TCP as transport protocols for IP will cause additional pain and lower interoperability

(I’m not sure what “format” means here; if this is about serializations, different considerations apply than if this is about information models and security models.)

Grüße, Carsten

---

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

Hi Carsten,

Format here means having an ASN.1, XML, JSON, CBOR, etc. encodings of the manifest (+ the appropriate security mechanisms).

For us offering operating systems we fear that one customer will want ASN.1 and the other want JSON, like they do with IoT protocols (e.g., CoAP and MQTT) today as well. The result is that we have to support everything and while they will not be compiled into the code at the same time they need to be available and need to be maintained.

When you then update a fleet of devices, some of them may support foo and some bar. Imagine a vehicle that comes with many different processors and they require a mixture of different formats. The backend infrastructure then needs to know what format is supported by which device/processor.

I hope this makes sense.

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 23 November 2017 09:02
To: Hannes Tschofenig
Cc: Suhas Nandakumar; [email-masked]
Subject: Re: [Suit] Manifest Formats

Grüße, Carsten

---

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

Hello,

my assumption is that we are talking about a serialization of a data 
model for data in motion here.

And a personal note: I would really like not to have to to nest 
sequences in sets with one item nested in sequences again, anymore.

Viele Grüße,

Henk

On 11/23/2017 09:01 AM, Carsten Bormann wrote:
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Nov 2017 11:31:29 +0100

> Format here means having an ASN.1, XML, JSON, CBOR, etc. encodings of the manifest (+ the appropriate security mechanisms).

But that list is rather confused/ing.

ASN.1 is an abstract syntax notation, i.e. a data model specification language.
It comes with a number of serializations such as BER/DER and OER (or even XER).
While BER/DER has history in the IETF, you’d probably want to use OER in a car.

XML is a generic data model with two serializations: XML character format and EXI.  It is often used with one of three data model specification languages: XML DTD, XSD, and Relax-NG (ASN.1 via XER is theoretically possible, but rarely used).  IETF also uses YANG to specify data models that are then serialized in XML.

JSON and CBOR are two serializations for a common generic data model (which has been made extensible, and was extended, for CBOR).
No dominating data model specification language has evolved in this space, although IETF has been using YANG and CDDL.

BER/DER has PKCS7/CMS as a security spec (which uses ASN.1 as its data model specification language).

I don’t know a security spec that would be applicable for XML in this space.

JSON and CBOR come with JOSE and COSE, respectively; the latter uses CDDL as its data model specification language.  There is currently no way to specify these security data models in YANG.

What exactly do you mean by “format" now?  I would have thought that would be the specific data model of the manifest, including security mechanisms, combined with a preferred serialization.

Grüße, Carsten

---

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

Hi Carsten,

Yes, there are lots of details to discuss but do you think that any of this should go into the charter (given that the current version of the charter already says that we will discuss this and pick one or multiple formats)?

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 23 November 2017 11:31
To: Hannes Tschofenig
Cc: Suhas Nandakumar; [email-masked]
Subject: Re: [Suit] Manifest Formats

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Nov 2017 11:42:08 +0100

> Yes, there are lots of details to discuss but do you think that any of this should go into the charter (given that the current version of the charter already says that we will discuss this and pick…

Well, I’d say we’ll design a format and pick one or more serializations for it.
I was just trying to explain why the term “format” maybe is a bit too fuzzy in those places of the charter where we want to be specific.

Grüße, Carsten

---

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

Hi Carsten,

> I was just trying to explain why the term “format” maybe is a bit too fuzzy in those places of the charter where we want to be specific.

For me the question was whether we restrict the design at charter writing time or when the group was formed. I preferred the former and lost. So, now we do it latter. That's fine.
Adding the distinction between format and serialization in the charter will not make any difference IMHO. I think we are just dancing around the topic.

Let us finish the charter and start the real work.

Ciao
Hannes

---

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

On Thu, Nov 23, 2017 at 12:09 AM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi Carsten,
>
> Format here means having an ASN.1, XML, JSON, CBOR, etc. encodings of the
> manifest (+ the appropriate security mechanisms).
>
> For us offering operating systems we fear that one customer will want
> ASN.1 and the other want JSON, like they do with IoT protocols (e.g., CoAP
> and MQTT) today as well. The result is that we have to support everything
> and while they will not be compiled into the code at the same time they
> need to be available and need to be maintained.
>
> When you then update a fleet of devices, some of them may support foo and
> some bar. Imagine a vehicle that comes with many different processors and
> they require a mixture of different formats. The backend infrastructure
> then needs to know what format is supported by which device/processor.
>

The device will ask for the format that it supports. Say, the device needs
manifest in CBOR format for example
 The device is basically dumb in that context and I am saying we don't need
to complicate that. Let the burden of having multiple encodings support be
on the update server and the device will ask the only thing it supports.

> I’m not Suhas, but I’d like to point out that while this is trivially
> true, it may also be trivially irrelevant, as demonstrated by a sentence
> like:
>
> > having both UDP and TCP as transport protocols for IP will cause
> additional pain and lower interoperability
>
> (I’m not sure what “format” means here; if this is about serializations,
> different considerations apply than if this is about information models and
> security models.)
>
> Grüße, Carsten
>
> 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:13:15 +0000

Hi Suhas,

The way we would like this to work is not to have the update server create these manifests in real-time, based on what the device asks for. Instead, the manifests are created and signed by the developer (using a tool or a web service). The update server is mainly a repository. This approach provides better security.

If you look back in the history of the IETF security work then defining multiple, similar solution has not been a great success story.

Ciao
Hannes

From: Suhas Nandakumar [mailto:[email-masked]]
Sent: 23 November 2017 16:52
To: Hannes Tschofenig
Cc: Carsten Bormann; [email-masked]
Subject: Re: [Suit] Manifest Formats

On Thu, Nov 23, 2017 at 12:09 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Carsten,

The device will ask for the format that it supports. Say, the device needs manifest in CBOR format for example
 The device is basically dumb in that context and I am saying we don't need to complicate that. Let the burden of having multiple encodings support be on the update server and the device will ask the only thing it supports.

I hope this makes sense.

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 23 November 2017 09:02
To: Hannes Tschofenig
Cc: Suhas Nandakumar; [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Manifest Formats

Grüße, Carsten

---

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

On Thu, Nov 23, 2017 at 8:13 AM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi Suhas,
>
>
>
> The way we would like this to work is not to have the update server create
> these manifests in real-time, based on what the device asks for. Instead,
> the manifests are created and signed by the developer (using a tool or a
> web service). The update server is mainly a repository. This approach
> provides better security.
>
>
>

Hello Hannes,

  I think i am not stating it should be real-time created either and you
are right that update server is just a repository. I don't think I am
disagreeing on that either.
  More than one encoding is created an stored on the server

> If you look back in the history of the IETF security work then defining
> multiple, similar solution has not been a great success story.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* Suhas Nandakumar [mailto:[email-masked]]
> *Sent:* 23 November 2017 16:52
> *To:* Hannes Tschofenig
> *Cc:* Carsten Bormann; [email-masked]
>
> *Subject:* Re: [Suit] Manifest Formats
>
>
>
>
>
>
>
>  The device is basically dumb in that context and I am saying we don't
> need to complicate that. Let the burden of having multiple encodings
> support be on the update server and the device will ask the only thing it
> supports.
>
>
>
>
> I hope this makes sense.
>
> Ciao
> Hannes
>
>

---

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

Suhas,

storing more than one format sounds definitely better than having to do anything in real-time.
At least we agree on something ;-)

Ciao
Hannes

From: Suhas Nandakumar [mailto:[email-masked]]
Sent: 23 November 2017 17:36
To: Hannes Tschofenig
Cc: Carsten Bormann; [email-masked]
Subject: Re: [Suit] Manifest Formats

On Thu, Nov 23, 2017 at 8:13 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Suhas,

Hello Hannes,

  I think i am not stating it should be real-time created either and you are right that update server is just a repository. I don't think I am disagreeing on that either.
  More than one encoding is created an stored on the server

---

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

> format, The multiplicity of the formats is needed on the Firmware
    > server to support devices with different capabilities on the manifest
    > encoding format. This comment in the charter seems incorrect.

I have made that point as well, and I think it bears repeating.

I understand that operating systems vendors might have to maintain more than
one set of code (of which they will compile one or the other).

Frankly I'd rather have two simple formats that as easily (code) reviewed
than a single format that has gotten complex due to hacks.

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

---

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

Hannes Tschofenig <[email-masked]> wrote:
    > Yes, there are lots of details to discuss but do you think that any of
    > this should go into the charter (given that the current version of the
    > charter already says that we will discuss this and pick one or multiple
    > formats)?

The charter needs to say one of:
     1) the format shall be X. (at one point it said to enhance 4108, so
          ASN.1 was the data model and DER was the serialization).

     2) there shall be one format, please hold taste test.
          (cf: http://www.redballoon.net/humor/alice.txt )

     3) there can be many serializations, but only one data model.

     4) whatever you want.

I prefer (3), btw.

I have good experience with YANG as the data model, and CBOR+COSE as the
serialization using SID based keys.
{I could live with CMS signed JSON if it wasn't the only possibility}

---

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

Hannes Tschofenig <[email-masked]> wrote:
    > The way we would like this to work is not to have the update server
    > create these manifests in real-time, based on what the device asks
    > for. Instead, the manifests are created and signed by the developer
    > (using a tool or a web service). The update server is mainly a
    > repository. This approach provides better security.

Yes, and the developer knows what the device is going to ask for, so this
isn't a problem.

The reason the device should still ask is because it is entirely possible
that devices might evolve over time and change their default.

---

From: Justin Cappos <[email-masked]>
Date: Sat, 25 Nov 2017 01:12:43 -0500

> then needs to know what format is supported by which device/processor.

The Uptane project <https://uptane.github.io/>, which handles secure
updates for automobiles intentionally doesn't standardize the format.  In a
car, the communication protocol used by the ECUs is effectively defined by
the Ford, GM, etc. even though most of the parts are made by vendors.  When
a vendor sells the same part to different automakers, they will change
their part to support the different formats needed.

In Uptane, we originally had the same goal of a standardized format which
Hannes mentioned.  However, when we started to work with the automakers, we
learned that a standardized format was a show stopper.  They wanted the
flexibility to customize things slightly for their environment because the
networks and existing toolchains are so different.

This has made testing implementations of Uptane a bit more difficult, but
it seems like we've had better adoption as a result.

Thanks,
Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 25 Nov 2017 12:35:47 +0100

Hi Justin,

I guess there is also a different interpretation about what format means
here.

If you look at draft-moran-suit-manifest-00 you will see that the
content maps to your terminology of "metadata" (for which you happen to
have used ASN.1).

Hence, I believe we are exactly on the same page as far as the goals and
values for standardization goes.

Ciao
Hannes

On 11/25/2017 07:12 AM, Justin Cappos wrote:
>     When you then update a fleet of devices, some of them may support
>     foo and some bar. Imagine a vehicle that comes with many different
>     processors and they require a mixture of different formats. The
>     backend infrastructure then needs to know what format is supported
>     by which device/processor.
> 
> 
> updates for automobiles intentionally doesn't standardize the format. 
> In a car, the communication protocol used by the ECUs is effectively
> defined by the Ford, GM, etc. even though most of the parts are made by
> vendors.  When a vendor sells the same part to different automakers,
> they will change their part to support the different formats needed.  
> 
> In Uptane, we originally had the same goal of a standardized format
> which Hannes mentioned.  However, when we started to work with the
> automakers, we learned that a standardized format was a show stopper. 
> They wanted the flexibility to customize things slightly for their
> environment because the networks and existing toolchains are so different.
> 
> This has made testing implementations of Uptane a bit more difficult,
> but it seems like we've had better adoption as a result.
> 
> Thanks,
> Justin
> 
>

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 25 Nov 2017 17:21:57 +0100

1) +1, but let me rephase this with an ask:

IMHO the charter MUST make a statement whether the group is expected to
define ONE or multiple DATA MODELs for metadata/manifest. So far
i can not see the term data model in the charter text at all (-07).

Once that charter decision is aggreed on, it will become a lot less
controversial whether the scope of the WG should be restricted to one
set of (serialization) formats or not - and how to write that into the
charter.

2) Having been around the block arguing between different formats
and the pettiness by which different interest groups proliferate redundant
choices, the best i would hope for is that the charter could serialize
format RFCs: Do not make drafts for a second, redundant format option
WG adopted until the first set is in RFC editor queue. And if you do not like for
your format to be second in queue, think about how this can help you
improve on shortcomings made in the first format RFCs. Heck, you're
even given chance to do a -bis on the data format definition to improve
your formats results.

Toerless

-- 
---
[email-masked]

---

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

> On Nov 23, 2017, at 9:13 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Suhas,
> 
>  
> 

How would that work? Would the update server, an online computer on the internet, need have the private key to sign the manifests? I can assure you that many IoT vendors do not handle their software signing keys that way. 

I imagine this working that a given vendor would likely only use one format but an update server could serve up manifests in any format. Sure one format would be nice but no matter which one you choose, a bunch of vendors will not like it and will do something else. The important part is the deciding the semantic level information and design choices. The syntax is really not the hard part of any of this yet different vendors have strong opinions about this often with very good reasons.