Re: [SCITT] Draft WG Charter

[Christopher Wood <[e-mail]>]

Hi Orie,

Apologies for the delayed response. Please see inline below.

On Wed, Jul 13, 2022, at 7:42 PM, Orie Steele wrote:
>> 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?

Sure -- I propose we approach this exactly the same way that MLS did. That means two things:

1. Update the charter text to be clear on how we'll treat identity, e.g.:

   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.

2. In the protocol, adopt something that lets us slot in new formats as needed, e.g., as was done in https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-16#section-6.3.

Does this clarify?

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

I think it's important to focus the efforts of this group on work that can be feasibly accomplished. To that end, I think we ought to make sure that we shape the protocol and architecture to work with different identity formats (as needed for different deployments), but not discuss anything else about how those identities are obtained, validated, etc. As a point of comparison, TLS basically punts on how X.509 certificates are authenticated, and I think we ought to do the same thing here.

Best,
Chris

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