Re: [Suit] self-describing format vs fixed/binary manifest structure

[Martin Pagel <[e-mail]>]

Thanks, Michael, 
I think the greatest value of the SUIT draft is the Architecture and Information Model documents as they define the rationale for a specific set of manifest fields. How you encode these fields is secondary and I believe it is more important that these fields can get easily loaded by the MCU rather than coming up with a portable/standard format. I only specified 64-bytes as an example, yes, 32-byte are enough for ECDSA. Same applies to thumbprint. Each manufacturer (or whoever develops the boot and installation software) would need to define the details of the manifest structure format it expects including byte alignment, crypto algorithms, keys etc.

I admit that the tables are difficult to decipher in text, you might want to review the PDF version I uploaded, but I will check out the ASCIIO tool. 

I will address your notes on Security Considerations with my next revision.
Martin

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Michael Richardson
Sent: Friday, December 14, 2018 9:46 AM
To: [e-mail]; [e-mail]
Subject: Re: [Suit] self-describing format vs fixed/binary manifest structure


Martin Pagel <[e-mail]> wrote:
> both formats are binary formats, the difference is that the CBOR is 
> self-describing, meaning each field has a prefix which describes the 
> data type and field number whereas the fixed structure are just a 
> packed binary structure such as a C struct.

Unfortunately, it's only "such as", because we can not describe it as
a C-struct in a portable/standard way   :-(
Many of us have extensive experience overlaying C-structure definitions on memory, so we can just "suck it in", but it has always resulted in issues.

This is why we like CBOR.  Please realize that the structure has to be processed as a series of byte copies from the buffer into *ANOTHER* structure (and/or processed and validated inline).

But, let's assume that I'm willing to go with a fixed-format structure such
as you have described.    There are some issues that I have:

1) The "Signature" block at 64-bytes is both too small and wasteful at the
   same time... :-)
   32-bytes is enough for ECDSA signatures.
   64-bytes in inadequate (as I understand it), for a hash-based signature.
   I think it's critical for any device that will be in the field past 2025
   to support hash-based signatures.  It may have to support both
   simultaenously for a period of time.

2) The SignCertThumbprint at 20 bytes seems to imply at most a sha1 hash of a
   certificate?

3) I did not understand easily the ManifestSet Header with the multiple Manifests.
   Can you split the ManifestSetHeader, Footer and Manifest sections into
   multiple sections.  Move the descriptions into a point-list after the
   description of the structure.  Don't use "Type" Unit16, but rather more
   convential IETF ascii-art diagrams.
   (You might find the tool "asciio" very useful for this)

4) I don't think that the explanation of how the format complies to the
   requirements belongs in the Security Considerations.  That's not what
   Security Considerations is for.  The protocol should explain itself,
   and then the SC should explain how those features defeat, mitigate, or
   fail to mitigate various attacks.

--
Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-