Subject: [Suit] Manifest format encodings

From: Brendan Moran <[email-masked]>
Date: Mon, 30 Oct 2017 14:03:21 +0000

I have seen several remarks encouraging the use of XML, JSON, CBOR, etc. manifests. I strongly believe that there should be a singular canonical encoding for manifests. If this is not the case, it creates a usability problem for the creators of manifests, where they need to know which sort of manifest is accepted by each device.

Based on the growing popularity of CBOR and the compactness of COSE, I believe that the way forward for SUIT is a singular “canonical” encoding in CBOR.

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: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 30 Oct 2017 15:30:06 +0000

Brendan,

[Chair hat off]

I believe the serialization requirement is that there must be parity between the producer of the manifest and the capabilities of the device. I don't believe that there is an absolute requirement for a single canonical serialization format for manifests. This allows different sets of products to choose the serialization approach that makes the most sense for those products. IMHO, choosing a single serialization is too limiting and does not provide for change over time in this space as needs/capabilities shift.

I believe it would be more useful to focus on what our priorities are in this regard. What should we work on first, second, etc?

Note: I am using serialization to avoid confusion with character encodings. Unfortunately the terminology is murky around these topics.

Regards,
Dave

> -----Original Message-----
> From: Suit [mailto:[email-masked]] On Behalf Of Brendan Moran
> Sent: Monday, October 30, 2017 10:03 AM
> To: [email-masked]
> Subject: [Suit] Manifest format encodings
> 
> I have seen several remarks encouraging the use of XML, JSON, CBOR, etc.
> manifests. I strongly believe that there should be a singular canonical
> encoding for manifests. If this is not the case, it creates a usability problem
> for the creators of manifests, where they need to know which sort of
> manifest is accepted by each device.
> 
> Based on the growing popularity of CBOR and the compactness of COSE, I
> believe that the way forward for SUIT is a singular “canonical” encoding in
> CBOR.
> 
> 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.
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdavid.waltermire
> %40nist.gov%7Ca136894ce7764857fce208d51f9f0156%7C2ab5d82fd8fa4797a9
> 3e054655c61dec%7C1%7C0%7C636449690137753614&sdata=ixILPutBN2y7u7
> Wv9YLL%2BaiAn9f8COZ10qJQFCCsuKk%3D&reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Oct 2017 20:51:05 -0400

Waltermire, David A. (Fed) <[email-masked]> wrote:
    > I believe the serialization requirement is that there must be parity
    > between the producer of the manifest and the capabilities of the
    > device. I don't believe that there is an absolute requirement for a
    > single canonical serialization format for manifests. This allows
    > different sets of products to choose the serialization approach that
    > makes the most sense for those products. IMHO, choosing a single
    > serialization is too limiting and does not provide for change over time
    > in this space as needs/capabilities shift.

Let me ask and answer some stupid questions in order to agree with you.

Q: Why do we need any kind of standard for the blob?
We don't really need a standard.
We happen to have rfc4108, with it's FirmwarePkgData and other containers.

Manufacturers know what the format of their firmware is, and can can produce
matching blobs. There is no negotiation here at all.

Q: So why do we need a manifest for?
A: The manifest tells the device what's in the blob.
    Integrity codes, version numbers, etc.
    Again the manufacturer knows exactly what kind of serialization the
    device supports for the manifest.  The device need only support one
    format, and the manufacturer has to produce that format.

Q: so why are we here?

A: Because it's useful to have (common) tools and systems that can intermediate the
   upgrade process, and those devices need to look at the manifest.

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).

Then we should have a set of serializations of the manifests: XML, CBOR/CWT,
YAML, JSON/JOSE... and even DER/ASN1.

This is what we did in ANIMA with draft-ietf-anima-voucher.

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

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 31 Oct 2017 02:40:57 +0100

Hello Michael,

I hope you do not mind that I provide some friendly comments :)

> matching blobs. There is no negotiation here at all.

Some people might see that as a benefit.

>      The device need only support one

Same as above. And a niche example not intended to sway opinion: vetting 
of integrity and certification will always be a thing and a huge cost sink.

>     upgrade process, and those devices need to look at the manifest.

Sounds sound.

> way to serialize things).

Well YANG comes with three serializations from which most people seem to 
think XML is the... default, I think?

> YAML, JSON/JOSE... and even DER/ASN1.

I just saw XML YAML and DER in that least. From my point, of view that 
does not let me feel very comfortable in respect to manifests.

> This is what we did in ANIMA with draft-ietf-anima-voucher.

And not everyone in ANIMA is happy with this, I think?

That said, I do not intend to discourage diversity, but using YANG as an 
abstraction for ASN.1? :o)

Viele Grüße,

Henk

> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Oct 2017 14:51:12 -0400

> think XML is the... default, I think?

No, that's really not the case.  There really isn't a default, but people had
to start someplace.

YANG serializes to XML easily, but most people want to go to JSON, and there
are now ways to go to CBOR directly.

    > I just saw XML YAML and DER in that least. From my point, of view that does
    > not let me feel very comfortable in respect to manifests.

So, don't use XML or DER.  Both make me ill.

Someone who has a device which already does extensive xml parsing might want
it. (Not me!)

    > And not everyone in ANIMA is happy with this, I think?

The feedback has mostly been about people thought that because we gave an
example in draft-ietf-anima-voucher that involved PKCS/CMS signed JSON, that
this was the only format allowed.  That was never the intention, and we fixed
that.

    > abstraction for ASN.1? :o)

ASN.1 is akin to CBOR's CDDL in the kinds of structures that it can describe.
DER is akin to CBOR.
(Except that ASN.1 is so general and OIDs so silly as to piss everyone off)

Ultimately YANG needs arrays and dictionaries (and nesting of them).
So you don't really describe the ASN.1 with YANG, rather, you probably use
ASN.1 to describe a nestable container in which you can translate YANG
attributes.  Again... it's not something I want to do, but for those that
enjoy it, they can do so.