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

Glad the meaning sunk in. I think we get into some small problems by creating
names that aren't self-explanatory. Especially if they are duplicated and/or
represented in a few different ways in the format.

We agree that we could place the textReference in the manifest so that we know 
what to discard at a later stage. It will make it easy for a simple bootloader 
to do the information severing, if it only needs to keep the signature and/or 
manifest after the update...

I've rewritten the initial idea by Øyvind for severability with the 
textReference  (now named textDigest) in the main manifest. I've also renamed 
the processReference to be updateProcessDigest. Stating digest in the instance 
name makes it easier for humans to parse IMHO.

; Example of extracting long-lived information so it can be stored while 
; short-lived processing info is discarded.

AuthenticatedManifest = [
  authenticatedManifest: COSE_Mac / COSE_Sign,
  updateProcess:         bstr .cbor UpdateProcess,
  text:                  bstr .cbor TextMap,
]

UpdateProcess = [
  nonce :              bstr,
  preConditions :      [ * PreCondition ],
  directives :         [ * Directive ],
  resources :          [ * ResourceInfo ],
  processors :         [ * ProcessingStep ],
  targets :            [ * TargetInfo ],
  extensions :         { * int => bstr}
]

Manifest = [
  manifestVersion :     1,
  digestInfo :          DigestInfo,
  sequence :            SequenceNumber,
  postConditions :      [ * PostCondition ],
  updateProcessDigest : bstr,
  textDigest :          bstr
]

I'm still a bit curious why DigestInfo needs to be split away from the digests.
I would like to support multiple digest-types through a manifest and I would
naturally assume the same methodology as the TLS standard - i.e. prepending the 
digest type with the digest (enum + digest content). It even allows for a TV 
encoding of the data instead of TLV (if need be). I'm not arguing against
removing the DigestInfo structure, in case there is a need for parameter data. 
But I think there should be little penalty changing the digestInfo  in the 
manifest to an array of DigestInfos, and using an enum/int identifier to 
reference between the digests and the DigestInfo...

Regards
Frank Audun Kvamtrø

> -----Original Message-----
> From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of David Brown
> Sent: 11. juli 2018 19:49
> To: Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no>
> Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; suit <suit@ietf.org>;
> Brendan Moran <Brendan.Moran@arm.com>
> Subject: Re: [Suit] [suit]: draft-moran-suit-manifest-02
> 
> Sorry, most of this can be ignored, as I missed the processReference field in the
> Manifest.  I would still suggest putting the textReference in the Manifest as well
> so that it doesn't require as deep of nesting to verify the text.
> 
> David
> 
> On Wed, Jul 11, 2018 at 11:47:26AM -0600, David Brown wrote:
> >On Fri, Jul 06, 2018 at 01:50:38PM +0000, Rønningstad, Øyvind wrote:
> >
> >>AuthenticatedManifest = [
> >>  authenticatedManifest: COSE_Mac / COSE_Sign,
> >>  updateProcess:         bstr .cbor UpdateProcess,
> >>  text:                  bstr .cbor TextMap,
> >>]
> >
> >>UpdateProcess = [
> >>  nonce :              bstr,
> >>  textReference :      bstr,
> >>  preConditions :      [ * PreCondition ],
> >>  directives :         [ * Directive ],
> >>  resources :          [ * ResourceInfo ],
> >>  processors :         [ * ProcessingStep ],
> >>  targets :            [ * TargetInfo ],
> >>  extensions :         { * int => bstr}
> >>]
> >
> >The textReference has to be in the Manifest that is covered by the
> >signature.  As stated here, none of the updateProcess or text
> >information is covered by a signature.
> >
> >This could be done by moving textReference above into the Manifest, as
> >well as adding an updateProcessReference that would contain a digest of
> >the updateProcess.  This adds complexity to verifying this additional
> >information, but would indeed then allow them to be severed, while
> >still being covered by the signature.
> >
> >David
> 
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit