Subject: Re: [Suit] Manifest format encodings

From: Brendan Moran <[email-masked]>
Date: Wed, 1 Nov 2017 10:57:41 +0000

> On 31 Oct 2017, at 18:51, Michael Richardson <[email-masked]> wrote:
>
>
> Henk Birkholz <[email-masked]> wrote:
>>> The device is not the only entity that needs to be able to see into the
>>> manifest.  But, these other systems that need to look at manifests are not
>>> constrained, they are not bootloaders or PXE clients, etc.
>>>
>>> This means that we should have an abstraction of what's in the manifest.
>>>
>>> (YANG is pretty good at this, in part because it does not come with a default
>>> way to serialize things).
>

This is not the only use-case for multiple inspection of the manifest.

Manifests could support configuration data (it’s just another binary blob, right?) and this complicates matters.

Suppose an OEM has retained the sole right to write firmware for a device, but they have delegated the authority to write configuration data to an Operator. The Operator may have many different device vendors and, therefore, may need to support many different OEMs. If each OEM has the right to select any encoding they want for the manifest, then the Operator will need to have many toolchains for creating manifests. It becomes easy for the Operator to produce the wrong encoding of manifest for each device.

Contrast this with a single encoding, regardless of what that encoding is: the Operator needs a single, standard toolchain for producing manifests for any managed device. The devices can always parse the manifest, and produce useful messages about the content.

This is not the only use-case. Multiple-signature of manifests may be used to assert qualification by third parties, such as test labs. If an Operator wants to ensure that a particular firmware or configuration works as expected on one or more networks, they may contract a third-party test lab to qualify the update package (manifest + payload). This third-party test lab will then sign the manifest when they have finished qualification.

With a single encoding, the test lab will be able to sign any manifest easily. With many encodings, the test lab incurs a burden for maintaining and supporting all the different toolchains required for the verification and signature process.

I think that there are a lot of hidden costs then using many encodings. Using a single encoding ensures that there is no confusion for OEMs, Operators, end users, intermediate infrastructure, or devices.

I don’t have a strong preference for which encoding to use, however the revised draft that we submitted on 2017-10-30 used CBOR/COSE due to the reduced encoded size. I don’t think that JSON or XML are good choices for resource-constrained devices.

Best Regards,
Brendan
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: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Nov 2017 13:43:54 -0400

Having written three ASN.1 parser/encoders, I have a few opinions on them.

For cryptographic applications, some use of ASN.1 is inevitable. Its
just the legacy infrastructure and there is no way to escape it. But
unless you are trying to do something unusual, you can almost always
make use of the ASN.1 code that is provided in crypto libraries for
the operations you need to use crypto.

In many if not most cases, those ASN.1 libraries are not general
purpose and can't be used to encode or decode other data structures
without a LOT of additional work. As in five to ten times the amount
of work it would take me to write a JSON encoder/decoder from scratch.

So my policy on ASN.1 is: No new ASN.1.

The way I implemented ASN.1 in the Mesh was to manually convert the
insane schema format to something I could parse with my own tools and
used that to develop an encoder/decoder for DER encoding. If I had to
write a specification round ASN.1, I would emit the ASN.1 schema from
my tool as an output.

This is exactly the same way that I make use of XML Schema. When I was
editing the SAML 1.0 spec, people's ideas on how to encode data
structures in XML changed every couple of weeks. Use model groups! No
don't! etc.

It is now my firm belief that the fact that there are at least six
ways to encode a data set in XML means that XML is the wrong tool. I
have even abandoned use of XML for my documentation tooling in favor
of what is essentially Markdown but using XML-ish tags in place of
punctuation characters as I find <dt> easier to remember than whatever
colon mess Markdown is using.

At this point, the industry is very very fixed on JSON as the future.
It might turn out to be a flavor of the month thing but I doubt it.
JSON is essentially just a variation on  S-expression syntax which has
been used since the 60s. It matches the data model of virtually every
modern programming language, at least as far as what is relevant to a
serialization format. What ASN.1 got wrong is that there is no such
thing as a set in a serialization since a sequence of bytes will
ALWAYS be a list.

So I would very much like it if we decided to make the JSON data model
the basis for the encoding of the manifest data. I believe that is
going to be the future.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Nov 2017 15:52:44 -0400

> Manifests could support configuration data (it’s just another binary
    > blob, right?) and this complicates matters.

It might not be a binary blog, it may well be signed JSON.

    > Suppose an OEM has retained the sole right to write firmware for a
    > device, but they have delegated the authority to write configuration
    > data to an Operator. The Operator may have many different device
    > vendors and, therefore, may need to support many different OEMs. If
    > each OEM has the right to select any encoding they want for the
    > manifest, then the Operator will need to have many toolchains for
    > creating manifests. It becomes easy for the Operator to produce the
    > wrong encoding of manifest for each device.

I don't buy your argument.
Incompetent operators might do that, but I don't see why this should force
the manufacturer to put multiple sets of possibly buggy code in their
bootloader.

You seem to be suggesting that:
a) the manifest contains the configuration data.
   An alternative is that the configuration data is a second blob with a
   second manifest.

b) that toolchains running on non-constrained hosts are expensive.
   I claim otherwise.

    > Contrast this with a single encoding, regardless of what that encoding
    > is: the Operator needs a single, standard toolchain for producing
    > manifests for any managed device. The devices can always parse the
    > manifest, and produce useful messages about the content.

I don't really want to have an encoding war.

    > This is not the only use-case. Multiple-signature of manifests may be
    > used to assert qualification by third parties, such as test labs. If an
    > Operator wants to ensure that a particular firmware or configuration
    > works as expected on one or more networks, they may contract a
    > third-party test lab to qualify the update package (manifest +
    > payload). This third-party test lab will then sign the manifest when
    > they have finished qualification.

Third-party testing is not cheap.
If the format of the manifest is an issue, then the third-party will die.

    > I don’t have a strong preference for which encoding to use, however the
    > revised draft that we submitted on 2017-10-30 used CBOR/COSE due to the
    > reduced encoded size. I don’t think that JSON or XML are good choices
    > for resource-constrained devices.

I'm all for COSE, but it depends upon what you sign it with.

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

---

From: Brendan Moran <[email-masked]>
Date: Mon, 6 Nov 2017 21:31:34 +0000

> On 1 Nov 2017, at 19:52, Michael Richardson <[email-masked]> wrote:
>

Signed JSON is representable in binary. Everything is representable in binary. That is the point of my statement. As long as the payload is hashable, it doesn’t matter what the encoding is, text, binary, 7-bit ASCII, base-64 encoded binary--if you can use a message digest on it, the content is irrelevant to the metadata format.

> b) that toolchains running on non-constrained hosts are expensive.

I’m suggesting that including the option for many encodings will create interoperability challenges that do not exist for a single encoding.

> I don't really want to have an encoding war.

I don’t want an encoding war either, but I also don’t want to create a legacy of interoperability challenges. Which is worse?

I don’t think this is all perfectly clear: I think there are some trade-offs to be made.

Best Regards,
Brendan