[{"author": "Steve Lasker", "text": "

Also having audio problems

", "time": "2023-02-06T16:02:26Z"}, {"author": "Kay Williams", "text": "

Greetings everyone!

", "time": "2023-02-06T16:04:07Z"}, {"author": "Raymond Lutz", "text": "

I'd like to have some discussion on SigStore

", "time": "2023-02-06T16:07:07Z"}, {"author": "Kay Williams", "text": "

Yoges, can you drop a link to the PR in the chat?

", "time": "2023-02-06T16:08:05Z"}, {"author": "Kay Williams", "text": "

*Yogesh

", "time": "2023-02-06T16:08:22Z"}, {"author": "Hannes Tschofenig", "text": "

https://github.com/ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases/

", "time": "2023-02-06T16:08:43Z"}, {"author": "Orie Steele", "text": "

Identity Assurance Levels... see also https://pages.nist.gov/800-63-3/

", "time": "2023-02-06T16:13:10Z"}, {"author": "Roy Williams", "text": "

Agreed we need to flesh out the identity problem.

", "time": "2023-02-06T16:13:33Z"}, {"author": "Steve Lasker", "text": "

Ray, I've been reading the thread and have some thoughts on how to put perspective to the identities and their relationships.

", "time": "2023-02-06T16:13:37Z"}, {"author": "Kay Williams", "text": "

Regarding use cases, does anyone have concerns with https://github.com/ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases/issues/20

", "time": "2023-02-06T16:13:50Z"}, {"author": "Raymond Lutz", "text": "

thanks orie

", "time": "2023-02-06T16:13:54Z"}, {"author": "Roy Williams", "text": "

There is also a tie-in Ray with what Policy identity was evaluated with.

", "time": "2023-02-06T16:14:18Z"}, {"author": "Dick Brooks", "text": "

I have to leave early - can we discuss open issues as we review each use case?

", "time": "2023-02-06T16:14:20Z"}, {"author": "Steve Lasker", "text": "

There's different \"types of identities\" and the policy can accept/decline types of specific identities. But, a focused convo on the topic would be helpful

", "time": "2023-02-06T16:14:23Z"}, {"author": "Roy Williams", "text": "

:thumbsup:

", "time": "2023-02-06T16:17:28Z"}, {"author": "Zachary Newman", "text": "

Yes! We can definitely have something by early March

", "time": "2023-02-06T16:17:37Z"}, {"author": "Zachary Newman", "text": "

Next week or so for a draft, plenty of time to review before the meeting

", "time": "2023-02-06T16:18:19Z"}, {"author": "Kay Williams", "text": "

+1 Jon

", "time": "2023-02-06T16:23:20Z"}, {"author": "Raymond Lutz", "text": "

I like the idea of doing this and we can defer discussion on SigStore.

", "time": "2023-02-06T16:27:32Z"}, {"author": "Dick Brooks", "text": "

Trust is in the name of the group SCITT

", "time": "2023-02-06T16:28:53Z"}, {"author": "Raymond Lutz", "text": "

Build trust through evidence. Even a financial trust, like a trust deed, is backed by interest in the property.

", "time": "2023-02-06T16:30:44Z"}, {"author": "Neal McBurnett", "text": "

+1 to avoiding murky terms like \"trust relationship\" and \"trust bond\".

", "time": "2023-02-06T16:31:41Z"}, {"author": "Steve Lasker", "text": "

I agree Trust is a good term to keep.
\nTrust is established through the policy and the verification of the identity through the notary portion of the policy.

", "time": "2023-02-06T16:33:42Z"}, {"author": "Steve Lasker", "text": "

Trust is also established through a verified identity.

", "time": "2023-02-06T16:34:03Z"}, {"author": "Dick Brooks", "text": "

I agree with Ray/Steve, trust is established based on evidence and a high integrity process that reaches a conclusion on trust, which results in a registry entry in SCITT

", "time": "2023-02-06T16:36:16Z"}, {"author": "Dick Brooks", "text": "

G2G - thanks.

", "time": "2023-02-06T16:36:24Z"}, {"author": "Jon Geater", "text": "

+1 the evidence is your raw material from which to build trust. SCITT doesn't itself GIVE trust. It ENABLES it. Deeper, richer reputations

", "time": "2023-02-06T16:36:28Z"}, {"author": "Steve Lasker", "text": "

+1 ^

", "time": "2023-02-06T16:36:41Z"}, {"author": "Raymond Lutz", "text": "

Yes, good phrasing.

", "time": "2023-02-06T16:36:50Z"}, {"author": "Raymond Lutz", "text": "

yes, the SCITT ledger itself does not provide the end result that Dick brings up, which will need to be built on top of it, and maybe that is another building block.

", "time": "2023-02-06T16:37:58Z"}, {"author": "Neal McBurnett", "text": "

So re the phrasing in the document, I don't think we are creating a \"standardized way\" to \"manage trust relationships\". We are standardizing ways to manage the evidence via which relying parties can use to develop and manage their own trust relationships in whatever ways they do.

", "time": "2023-02-06T16:39:12Z"}, {"author": "Raymond Lutz", "text": "

Those kinds of emotional trust relationships can't be quantified and so are probably not a good match.

", "time": "2023-02-06T16:40:37Z"}, {"author": "Raymond Lutz", "text": "

(responding to Roy)

", "time": "2023-02-06T16:40:49Z"}, {"author": "Raymond Lutz", "text": "

Yes, good way to think of it Neal.

", "time": "2023-02-06T16:41:16Z"}, {"author": "Roy Williams", "text": "

That then points out a wording problem. How to express the removal of responsibility is based on \"XYZ\" that such and such did their job.

", "time": "2023-02-06T16:42:01Z"}, {"author": "Raymond Lutz", "text": "

Please clarify Roy

", "time": "2023-02-06T16:42:31Z"}, {"author": "Raymond Lutz", "text": "

Yes Yogesh.

", "time": "2023-02-06T16:43:03Z"}, {"author": "Roy Williams", "text": "

I trust that Microsoft's CELA team did the full review to their satisfaction that licensing terms work for Microsoft Products.

", "time": "2023-02-06T16:43:20Z"}, {"author": "Roy Williams", "text": "

Thus if they have issues with OSS then I will not take a dependency on it.

", "time": "2023-02-06T16:43:52Z"}, {"author": "Neal McBurnett", "text": "

Are you expecting to issue a statement to that effect? Using a SCITT-standardized statement?

", "time": "2023-02-06T16:44:19Z"}, {"author": "Roy Williams", "text": "

The question is how that flips to more than legal. Do we believe that Corporate \"auditor\" making a statement that a product has a site license, and has evidence of securely built, etc.. I see as an extension of that same scenario going forward.

", "time": "2023-02-06T16:45:06Z"}, {"author": "Steve Lasker", "text": "

There's an association between a \"statement\" and an identity.
\nYou decide to trust verified identities, and then you can trust the content (statements) made by trusted verified identities.

", "time": "2023-02-06T16:45:31Z"}, {"author": "Roy Williams", "text": "

No, it is not a SCITT standardized statement but in a use case for software built upon SCITT yes.

", "time": "2023-02-06T16:45:39Z"}, {"author": "Roy Williams", "text": "

Which gets to Jon's point.

", "time": "2023-02-06T16:45:46Z"}, {"author": "Raymond Lutz", "text": "

I guess the evaluation of the evidence can utilize additional trust or other avenues to approve use of the SW, but SCITT can't actually provide trust in a bottle.

", "time": "2023-02-06T16:46:28Z"}, {"author": "Roy Williams", "text": "

The use case for software is being built up across multiple environments and the EO in the US is causing all sorts of side building blocks. SCITT is the foundation.

", "time": "2023-02-06T16:46:33Z"}, {"author": "Raymond Lutz", "text": "

SCITT building block I hope is very simple.

", "time": "2023-02-06T16:47:00Z"}, {"author": "Roy Williams", "text": "

Agreed Raymond, except in my view, SCITT evaluates identity to match some Policy definition before allowing it entry.

", "time": "2023-02-06T16:47:18Z"}, {"author": "Orie Steele", "text": "

+1 Henk!

", "time": "2023-02-06T16:47:27Z"}, {"author": "Roy Williams", "text": "

That way reducing the view of data back from SCITT as at least matching some policy sanity.

", "time": "2023-02-06T16:47:40Z"}, {"author": "Raymond Lutz", "text": "

That issue is important and needs more work, in my mind at least. I will review the SP 800-63 docs orie mentiond.

", "time": "2023-02-06T16:47:52Z"}, {"author": "Raymond Lutz", "text": "

Everyone admits identity is a hard problem, and we need to face it rather than dodge it, as SigStore did.

", "time": "2023-02-06T16:48:36Z"}, {"author": "Raymond Lutz", "text": "

Yes Roy

", "time": "2023-02-06T16:51:15Z"}, {"author": "Neal McBurnett", "text": "

Re: sigstore. I missed the 01-23 SCITT meeting, but I think they provide an excellent substratum for our work. as As I commented in the video (https://youtu.be/nZHfOFN-Q7A), many in SCITT WG seem interested in baking some policies in to the infrastructure. I'm wondering what the options are for layering policies and well-known CA or auditor identities on top of Sigstore to vouch for policy compliance and address all the SCITT use cases.

\n
", "time": "2023-02-06T16:51:44Z"}, {"author": "Zachary Newman", "text": "

Thanks for the feedback!

", "time": "2023-02-06T16:55:19Z"}, {"author": "Zachary Newman", "text": "

Looking forward to addressing some of these questions in this group :)

", "time": "2023-02-06T16:55:31Z"}, {"author": "Orie Steele", "text": "

https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

", "time": "2023-02-06T16:55:43Z"}, {"author": "Raymond Lutz", "text": "

perfect thanks orie

", "time": "2023-02-06T16:56:37Z"}, {"author": "Orie Steele", "text": "

yes, I think human and service identity need to be considered.

", "time": "2023-02-06T16:56:46Z"}, {"author": "Steve Lasker", "text": "

+1

", "time": "2023-02-06T16:56:56Z"}, {"author": "Steve Lasker", "text": "

A service identity can also be verified.

", "time": "2023-02-06T16:57:06Z"}, {"author": "Orie Steele", "text": "

build servers are not people, but they are important producers of \"signed artifacts\" :)

", "time": "2023-02-06T16:58:28Z"}, {"author": "Steve Lasker", "text": "

There's a good conversation to be had about when \"people\" are trusted, or a \"service\" aka a company.
\nDo you trust software from Microsoft because it was \"signed by Roy\", or signed by Microsoft?

", "time": "2023-02-06T16:59:22Z"}, {"author": "Roy Williams", "text": "

Ray, though if the govenment is part of this, then they have their own CA systems. Thus why go weaker is a question.

", "time": "2023-02-06T17:00:05Z"}, {"author": "Kathleen Moriarty", "text": "

NIST has the levels defined in 800-63

", "time": "2023-02-06T17:00:11Z"}, {"author": "Neal McBurnett", "text": "

I think we should beware of tying too much trust to digital identities, without a means for dealing with compromised identities. See e.g. the Tor framework for how to delegate, effectively revoke and adapt in the face of attacks.

", "time": "2023-02-06T17:00:13Z"}, {"author": "Raymond Lutz", "text": "

LOL I don't automatically trust anything from MS :)

", "time": "2023-02-06T17:00:15Z"}, {"author": "Orie Steele", "text": "

I've been thinking about domains a lot in this context... especially because of the problems with \"email / domain expiring issues\" etc...

", "time": "2023-02-06T17:00:26Z"}, {"author": "Roy Williams", "text": "

I am just shocked Ray LOL

", "time": "2023-02-06T17:00:41Z"}, {"author": "Raymond Lutz", "text": "

:)

", "time": "2023-02-06T17:00:49Z"}, {"author": "Steve Lasker", "text": "

haha

", "time": "2023-02-06T17:01:11Z"}, {"author": "Orie Steele", "text": "

seems that email is basically a more dangerous and less explicit identifiers for a \"controller of a domain\"... might be nice to see the email part dropped and the domain retained...

", "time": "2023-02-06T17:01:24Z"}, {"author": "Raymond Lutz", "text": "

email is a problem in Sigstore.

", "time": "2023-02-06T17:01:38Z"}, {"author": "Orie Steele", "text": "

but this is \"identity problems\" slippery slope.

", "time": "2023-02-06T17:01:45Z"}, {"author": "Steve Lasker", "text": "

Thanks folks

", "time": "2023-02-06T17:02:11Z"}]