Re: [Suit] [suit]: draft-moran-suit-manifest-02

[David Brown <[e-mail]>]

On Tue, Jul 03, 2018 at 09:08:02PM +0000, Brendan Moran wrote:
>This draft is a significant departure from previous drafts, so I think it is
>important to highlight the changes. The draft requires a lot of text that
>hasn’t been written yet, so I will try to put some of that here for discussion.
>
>[1]https://datatracker.ietf.org/doc/draft-moran-suit-manifest/

In this email, I wanted to enumerate the parts of the current manifest
draft that are either unclear to me (possibly just needing more
explanation) and/or should be reworked.

1.  Signature contents.

A few things need to be spelled out about the COSE_Mac and COSE_Sign
blocks:

  - The payload should be a "Manifest".

  - What is the content type used for this.  Presumably, we will
    register one for a SUIT manifest, when the RFC is finalized, but
    it does need to be stated.  Just stating it is CBOR could also
    work, but then a processor would have to look into the payload to
    determine if it is a manifest.

  - Is the CBOR for the manifest tagged?  If so, we should register a
    tag for our manifest format.

2.  DigestInfo

We need to define the values for digestAlgorithm, and what is
contained in digestParameters.  Are these related to the values
defined in COSE, or at least do they come from the same number space?

3.  Encoding of ProcessingStep, Pre and Post conditions.

Using different arrays with the first element of the array is a number
indicating the meaning of the remainder of the array is different than
how I've seen other data represented in CBOR.  I'm presuming that this
is so that order can preserved, where as a map would require a
specific order for a canonical encoding.  I don't know the
ramifications of this on processing code.  It is certainly legal from
CBOR's point of view.

Other possibilities would be to have the fields be an array of pairs,
similar to how a map would be encoded, but described as an array so
that order could be preserved.  I don't know if this can be
represented in CDDL.

It could also be an array of maps.  The grouping simply used to allow
ordering to be enforced when that is needed.

4.  The Directive encoding

The CDDL grammar allows the "=>" to be used inside of an array (so
this parses), but there are no example or explanation of what this
would mean.  Do we intend for the Directive to be a map, or are we
hoping to have something of an ordered map, similar to what I
described above as an array of pairs.

5.  Use of numbers.

We have numerous fields that make use of small integers.  Is the
intent that these be fixed, and any additional values only be allowed
in the 'extensions' field?

6.  Extensions.

The extensions are described as maps.  Do we envision a case where
ordering needs to be preserved in extensions?

In addition, do we need to have something similar to the criticality
header in COSE where a manifest can say certain extensions are
mandatory, and that an actor that doesn't understand that extension
should reject the manifest?

Thanks,
David