Re: [Suit] SUIT rechartering: proposed text

[Roman Danyliw <[e-mail]>]

Hi Russ!

> -----Original Message-----
> From: Russ Housley <[e-mail]>
> Sent: Friday, November 5, 2021 12:25 PM
> To: Roman Danyliw <[e-mail]>
> Cc: suit <[e-mail]>
> Subject: Re: [Suit] SUIT rechartering: proposed text
> 
> Roman:
> 
> > To make it easier to reference it and perform diffs against prior text, I've
> upload the charter text from the WG into the datatracker.
> >
> > For the full text, see
> > https://datatracker.ietf.org/doc/charter-ietf-suit/
> >
> > For the diff from the last approved charter, see
> > https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2
> > Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-
> 01.txt&url2=https%3A%2F%2Fda
> > tatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01-00.tx
> > t
> >
> > I support the spirit of the additional scope.  We need tighten up some of the
> language to get it through the review process.
> 
> Thanks.
> 
> > (a) Editorial.  Be clearer on the motivation.
> >
> > OLD
> > To support the SUIT manifest format, the SUIT WG is also defining
> > formats that enable a SUIT Status Tracker to determine if a particular
> > manifest could be successfully deployed to a device and determine if an
> operation was successful.
> >
> > NEW
> > To enable the SUIT Status Tracker, the SUIT WG is also defining extensions to
> determine if a particular manifest could be successfully deployed to a device
> and determine if an operation was successful.
> 
> This seems fine to me.

Merged into v01-01

> > (b) We need to be consistent on the approach taken to describe the scope of
> extensions.  Specifically:
> >
> > -- We have both a generic clause for scope on "Extensions to the SUIT
> manifest for optional capabilities ...", but then the bullet concludes with a
> specific instance with " ... including firmware encryption".
> >
> > -- There is a stand-alone bullet on making a MUD extension, "A SUIT manifest
> extension to include a MUD file as defined in RFC 8520"
> >
> > Should we have both caveated support of optional capabilities?  Is there a
> threshold we need, say "... when there is broad applicability"?  or limited to
> specific applications/utility?
> >
> > Should we enumerate the extensions were already want to work on here
> > (firmware encryption, MUD, Software IDs/SBOM, multiple trust domains?)
> 
> At the time that this text was crafted, we did not know how the extensions
> would get broken up.  We have a first cut at that now, but I think that the base
> text should allow for further reorganization.
> 
> The SUIT WG document deliverables are:
> * A SUIT manifest format specification using CBOR.
> * Extensions to the SUIT manifest for optional capabilities, including:
>   - firmware encryption,
>   - trust domains,
>   - update management, and
>   - inclusion of MUD file as defined in RFC 8520.
> * A secure method for an IoT device to report on firmware update status.

Merged into v01-01

> > (c) Should be provide a milestone for deciding on where the joint RATS-SUIT
> work will happen?
> 
> I think we can add a milestone if the work lands in SUIT.  I'm guessing it will
> land in RATS with review in SUIT.

I was envisioning a milestone for the decision to do the work in RATS vs. SUIT, not a milestone for the work itself.  For example:

"XXX-2022  Decide with RATS WG on where the 'set of claims for attesting to firmware update status' document should be produced"

> > (d) We also need milestones for the new scope.  Judging from what's in the
> current document list (https://datatracker.ietf.org/wg/suit/documents/) is that:
> 
> I think that you missed that some of the "Done" milestones are new:
> 
>    Done      Adopt firmware encryption document as WG item.
>    Done      Adopt SUIT Status Tracker document as WG item.
> 
> These were already adopted because they fit the old charter, but we failed to
> create milestones at that time.

These are merged into the live WG milestones.

> > (previously defined, still open milestone) Feb 2022  Submit an initial
> > manifest serialization format to the IESG for publication as a Proposed
> Standard.
> >
> > (new milestones)
> > MMM-YYYY Submit a SUIT Manifest firmware encryption extension document
> > to the IESG for publication as a Proposed Standard
> > (draft-ietf-suit-firmware-encryption)
> > MMM-YYYY Submit a SUIT ??? (draft-ietf-suit-report-00) MMM-YYYY Submit
> > a SUIT Manifest MUD extension document to the IESG for publication as
> > a Proposed Standard (draft-moran-suit-mud) MMM-YYYY Submit a SUIT
> > Manifest extension that enables support for multiple domains document
> > to the IESG for publication as a Proposed Standard
> > (draft-moran-suit-trust-domains) MMM-YYYY Submit a SUIT Manifest
> > extension for ??? to the IESG for publication as a Proposed Standard
> > (draft-moran-suit-update-management)
> >
> > The currently unadopted document could also have a corresponding
> milestone of "Adopt ..."
> 
> Sorry, that was a cut-and-paste error on my part:
> 
> Dec 2021  Adopt SUIT Manifest update management document as WG item.
> Dec 2021  Adopt SUIT Manifest trust domains document as WG item.
> Dec 2021  Adopt SUIT Manifest MUD extension document as WG item.

Add to v01-01 charter.

> Feb 2022  Submit an initial manifest serialization format to the IESG for
> publication as a Proposed Standard.

Added to the live (current) charter as this is prior work with a new date.

> Aug 2022  Submit firmware encryption document to the IESG for publication as
> a Proposed Standard.
> Sep 2022  Submit SUIT Status Tracker document to the IESG for publication as a
> Proposed Standard.
> Nov 2022  Submit SUIT Manifest update management document to the IESG for
> publication as a Proposed Standard.
> Nov 2022  Submit SUIT Manifest trust domains document to the IESG for
> publication as a Proposed Standard.
> Dec 2022  Submit SUIT Manifest MUD extension document to the IESG for
> publication as a Proposed Standard.

Add to v01-01 charter.

Regards,
Roman

> Thanks,
>   Russ