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

[Brendan Moran <[e-mail]>]

Thank you for the comments Carsten and Øyvind. I think I submitted that draft in too much of a hurry!

Directives are intended to handle a set of problems that are entirely constrained to the application of the manifest. For example:

  *   Wait until battery level is above 50% before applying manifest (note that there is a similar condition for non-energy harvesting applications)
  *   Reboot after application
  *   Restart designated component when installation is complete
  *   Apply only at 23:59 on a Saturday.
  *   Disconnect from the network prior to installation

Meanwhile, extensions are a placeholder for all those concepts that we haven’t realised we’re missing yet.

The ProcessingSteps need to have multiple inputs. I think that inode should be a list and onode should be single. Then, a processor is the aggregate of a map of inputs and a single output. It may be that this is not correct and that multiple onodes are needed.

If a target is an alias, that implies several things:

  *   There must be another target with the same digest in a dependency manifest
  *   The target is missing several key pieces of information:
     *   Size
     *   Component ID
     *   Storage location
     *   Encoding
  *   The containing manifest doesn’t need to have rights to install the target

The point of the alias is to redirect a client to different hosting infrastructure for a given payload.

There must be a way to reference the resources declared by dependency manifests. There are two ways that I can see to handle this:

  1.  Use arbitrary names (this is vulnerable to node-name collisions)
  2.  Use node paths (this makes cross-branch references more difficult, but I’m not certain that those are legitimate: each manifest should declare its dependencies explicitly; if that means there are duplicate manifests in a tree, that is acceptable.)

If node paths are used, then how are they encoded? I would suspect they should be CBOR arrays.

I’ll see what I can do about those CDDL problems! Once I have a chance to take in some more of the feedback, I’ll send a CDDL file that encompasses these and more recommendations out.

Thanks,
Brendan

On 4 Jul 2018, at 21:38, Carsten Bormann <[e-mail]<mailto:[e-mail]>> wrote:

On Jul 4, 2018, at 10:26, Rønningstad, Øyvind <[e-mail]<mailto:[e-mail]>> wrote:
>
>        • CDDL nitpicking:
>                • Some name inconsistencies: ProcessingStep vs Processor, TargetInfo vs Target.
>                • There's probably a typo in the definition of Directive. Should it be an array of maps?
>                • Target::storageIdentifier and Target::componentIdentifier don't use the custom types for StorageIdentifier and ComponentIdentifier.
>                • I think digests should have a type, so the user can more easily restrict its format after choosing a digest algorithm.
>                • Suggestion: Add nint to textKeys group.
>                • AuthenticatedManifest should probably contain an authenticatedManifestVersion or similar.
>                • "Processor" might be confusing (“does it mean CPU?”).

It also helps to occasionally run instances of formal languages through some tool to check them…

Apart from inconsistent use of names, most of the syntax errors stem from the arcane syntax that CDDL is using for its workaround for not having true enumerations (Section 2.2.2.2 of draft-ietf-cbor-cddl-03.txt); this requires commas (or nothing) instead of slashes, and an enclosing &, so with Øyvind’s suggestion, textKeys becomes, e.g.:

  textKeys = &(
      uninitialised: 0
      manifestDescription: 1
      payloadDescription: 2
      vendorName: 3
      modelName: 4
      payloadVersion: 5
  ) / nint

And Processor starts off as:

  Processor       = [
      &(decrypt: 1, decompress: 2, undiff: 3, relocate: 4, unrelocate: 5),


(Of course, the same thing can be expressed as:

  Processor       = [
      &(decrypt: 1, decompress: 2, undiff: 3, relocate: 4, unrelocate: 5),
      decrypt: 1 // decompress: 2 // undiff: 3 // relocate: 4 // unrelocate: 5,

Not sure what the intent is here; in the first case, I’d probably also add a label, as in

  Processor       = [
      process: &(decrypt: 1, decompress: 2, undiff: 3, relocate: 4, unrelocate: 5),

I have attached a version that parses (I don’t think an attachment will make it to the lists) but does not address any other of Øyvind’s suggestions.

The other problem that should probably be addressed is that most rules are unused — there would need to be one cddl file for the manifest, and maybe one for the COSE envelope.  We simply don’t have a good way in CDDL yet to say “Manifest goes through an algorithm and turns up in COSE_Sign” — actually, in this case this could be solved in part as the manifest turns up in cleartezt.
I have included a dirty hack in the attached which I intend to fix.

I’m CCing the CBOR WG to give an example for CDDL being used in another WG.  If you want to discuss a CDDL feature, please strike SUIT from the list (and if you want to discuss a SUIT feature, maybe strike CBOR from the list).

Grüße, Carsten



<suit.cddl>

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.