Re: [SCITT] Draft WG Charter

[Orie Steele <[e-mail]>]

> I think we should strive to punt on all identity-related issues and
simply pick an abstraction that is extensible for different use cases.

DIDs are one such abstraction, x509 is another... In the threads regarding
COSE envelopes, I've endeavored to support your proposed approach by
focusing on COSE, keys and signatures instead of DIDs, keys and
signatures... But I wonder, if you have any concrete proposals for this
extensible abstraction?

Given establishing the identity of software components, authors and CVEs is
fundamental to all existing SBOM formats I am aware of, I don't see how we
can punt on "all identity-related issues".

When you have signatures or authentication, you have identity, and likely
an identity related abstraction with baggage such as x509, JWT, CWT or DID.

I'm not sure limiting this field via the charter, before the WG is formed
is strategic.

Regards,

OS

On Wed, Jul 13, 2022, 4:48 PM Christopher Wood <[e-mail]> wrote:

> I took a look at the charter. Beyond the problem statement refinement
> happening in another thread, I wanted to comment on the proposed work
> items. My feedback is below. I’m happy to turn some of this into one or
> more PRs against the charter text if that’s helpful.
>
> ---
>
> 1. The WG will select (and potentially profile or augment) acceptable
> common identity format/formats that shall be used in the SCITT ecosystem.
> This will enable interoperability across geographical regions and also
> trace the identity chain seamlessly when a product comprises of multiple
> sub-products from multiple issuers. This includes a model of essential
> actors, such as the supply chain "issuer" (one which generates supply chain
> artifacts), and their duties in the ecosystem.
>
> I think we should strive to punt on all identity-related issues and simply
> pick an abstraction that is extensible for different use cases. MLS has
> some useful text in their charter on this point that we might want to
> repurpose accoringly:
>
>    While authentication is a key goal of this working group, it is not
>    the objective of this working group to develop new authentication
>    technologies. Rather, the security protocol developed by this
>    group will provide a way to leverage existing authentication
>    technologies to associate identities with keys used in the protocol,
>    just as TLS does with X.509.
>
> That would de-emphasize DID — and the baggage it carries — and allow us to
> keep issues of identity separate from the rest of the work.
>
> 2. The WG will define the envelope and common schema for carrying supply
> chain claims/endorsements.
>
> This is a fine work item.
>
> 3. The WG will standardize the Transparent Registry requirements to
> generate homogeneity across multiple supply chains.
>
> This doesn't seem like something the IETF can do since it ultimately boils
> down to policy. For example, some deployments of SCITT might choose to only
> require that a transparent registry produce countersignatures over claims
> without any historical data, whereas other deployments might want full the
> transparency service to provide a complete (global?) view of all claims
> registered with the service. There's definitely a spectrum of options here,
> and the choice of what requirements make sense depend on a particular
> deployment's threat model.
>
> I might rephrase this particular work item to something like the following:
>
>    The WG will standardize profiles of Transparent Registry services and
> document their requirements and security properties.
>
> 4. A standard format for authenticity data returned from the transparent
> registry, such as proof, etc. The standard will enable independent
> verification of supply chain claims at a (much) later point on multiple
> platforms across multiple geographical locations.
>
> This is a fine work item, but I would drop "on multiple platforms across
> multiple geographical locations".
>
> 5. The WG will develop standards for auditing the supply chain claims that
> are introduced in the transparent registry. This will, in turn, generate
> audit claims (results of the audit) which can be introduced in the same
> registry. Audit information can be queried by supply chain consumers (end
> customers) before making critical business decisions.
>
> I don't understand why it's necessary for audit claims (what is an audit
> claim?) to end up in the registry. This again seems like a deployment
> specific requirement. Instead, I might rephrase this to something like the
> following:
>
>    The WG will document ways in which Transparent Registry services can be
> audited for correctness against registered claims.
>
> ... or something. The intent here is to say "we'll describe how to audit,
> where auditing varies based on the service you're interacting with."
>
> 6. The WG will develop standards that define the notarization process and
> outline the core functions/actions that a notary will perform in the supply
> chain ecosystem.
>
> Notary isn't a concept or role in the architecture document, so it's not
> clear to me what this work item intends to document. Can someone please
> clarify?
>
> 7. Standardize request-response interactions ("external API") and
> potentially other interaction models provided to various actors to interact
> with the supply chain ecosystem. This includes standardizing
> inter-component messages between supply chain building blocks to support
> easy reference implementations of SCITT building blocks by various
> organizations and easy industry-wide adaptation.
>
> This seems pretty vague right now, so I suggest we punt this issue out of
> scope for now. To that end, I might rephrase this to something like the
> following:
>
>    The WG will discuss extensions to the protocol that can assist other
> interaction models provided to various actors to interact with the supply
> chain ecosystem. Where such mechanisms appear sufficiently useful, the WG
> will re-charter to add relevant new work items.
>
> ---
>
> Best,
> Chris
>
>
> > On Jul 2, 2022, at 12:18 PM, Eliot Lear <[e-mail]> wrote:
> >
> > Yogesh,
> >
> > This is a very good starting point.  I will have a few suggestions in a
> PR in the coming week.  I would ask that people take a look.  Things to do
> at this point:
> >
> >       • Confirm that the problem statement reflects the results of our
> last BoF,
> >       • Review the goals, non-goals, and work program
> > Things not to do, at least on list:
> >
> >       • Pick at spelling or grammar, or nitpick wording.
> > Eliot
> >
> > On 01.07.22 11:29, Yogesh Deshpande wrote:
> >> Hi all,
> >>
> >> SCITT BoF proponents have prepared a WG charter draft based on the
> comments
> >> since the last BoF (problem statement) and the discussions on list.
> >> This preliminary charter draft is intended as a basis for discussion
> and as
> >> a preparation for the upcoming SCITT BoF at IETF 114 (preliminary
> meeting details:
> >> https://datatracker.ietf.org/meeting/114/session/scitt
> >> ).
> >>
> >> The charter draft lives on github:
> >>
> >>
> >> https://github.com/ietf-scitt/charter/blob/master/ietf-scitt-charter.md
> >>
> >>
> >> Feel free to chime in via comments or suggestions for further
> improvement
> >> by creating github issues or PRs on this repository.
> >>
> >> Regards,
> >> Yogesh
> >> 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.
> >>
> >>
> > --
> > SCITT mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/scitt
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
>