Re: [Suit] SUIT rechartering: proposed text

[Russ Housley <[e-mail]>]

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%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-suit%2Fwithmilestones-01-00.txt
> 
> 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.

> (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.

> (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.

> (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.

> (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.

Feb 2022  Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard.
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.

Thanks,
  Russ