WEBVTT

00:00.000 --> 00:18.000
Hi, I'm Oula. I'm a security a whole week and I have a problem.

00:18.000 --> 00:26.000
Great. Highly. That's the problem, sir. Let's go. I have a problem because I'm working

00:26.000 --> 00:34.000
in Oula's with a cyclone DX, industry working group and we're also developing a new API.

00:34.000 --> 00:41.000
And we're going to deliver a lot of documents surrounding software across the supply chain.

00:41.000 --> 00:52.000
And in that case, we need to be able to trust that the documents we get are the documents, the upstream, open source project, or vendor actually signed.

00:52.000 --> 01:02.000
And that nothing is changed really. So we need many customers to trust many vendors. You see how this scales critically.

01:02.000 --> 01:13.000
In a given manufacturer project, according to the CRA terminology, manufacturer, they can have thousands of upstream open source projects.

01:13.000 --> 01:24.000
And then you need documents. This is very much like the problem with web trust, but we all know that the web trust, well, that's another talk.

01:24.000 --> 01:42.000
We have problems with the web trust system. Commercial signing certificates costs around $2,500, not available for open source, not available reachable for small medium size enterprises.

01:42.000 --> 01:51.000
And not even possible to buy really large corporations because the people who are supposed to sign the bill doesn't understand what they're signing.

01:51.000 --> 01:59.000
And why there's a need for a software signing certificate, unless it looks the distribution of mobile apps or something.

02:00.000 --> 02:12.000
So we need to implement trust and transparency across the software supply chain. So I've been looking for solutions.

02:12.000 --> 02:25.000
We have CVS. There's a lot of things about the need of signing S-bomb. They need to validate S-bomb, but doesn't say how or with what.

02:25.000 --> 02:43.000
In these areas, published a document called the S-bomb landscape, and I'm so happy to find a section on digital signatures on S-bombs, didn't say how or with what.

02:43.000 --> 02:49.000
We have some ideas in the West Transparency Exchange API that I want to share with you.

02:49.000 --> 03:03.000
But every time I start talking about this in the circles that discuss S-bombs and S-bombs sharing and certificate compliance with UCRA and sharing with that and VIX sharing,

03:03.000 --> 03:08.000
I think the start looking after Windows saying, oh, it's a beautiful day.

03:08.000 --> 03:21.000
Or don't we need coffee now? So the word you live in, where I can happily spend half an hour here discussing X-49,

03:21.000 --> 03:35.000
and it's a very, very different world from the world of S-bombs and trust in software supply chains, but we need to work together here.

03:35.000 --> 03:43.000
So we need to be able to sign, we need to be able to validate and trust these signatures.

03:43.000 --> 03:47.000
Both for an open source project, but also for commercial vendors.

03:47.000 --> 03:58.000
We need to build this without giving away the business to American CS, we're recording this.

03:58.000 --> 04:01.000
You know them.

04:01.000 --> 04:12.000
I'm looking for something distributed here, something where we don't have a single point of failure in the middle that we all have to trust without thinking about them.

04:12.000 --> 04:17.000
And I'm also looking into transparency.

04:17.000 --> 04:22.000
How many here and no certificate transparency on the web API?

04:22.000 --> 04:31.000
A few of you, we monitor the public C-A, the sign certificates for webs and other things,

04:31.000 --> 04:38.000
and see every single certificate they issued to make me sure that we can monitor what they do,

04:38.000 --> 04:46.000
that they actually have some trust in their systems.

04:46.000 --> 04:49.000
But that's another thing.

04:49.000 --> 04:52.000
And this is a global problem, right?

04:52.000 --> 04:59.000
And that's very important to recognize because there's not much happening on this side or the pond.

04:59.000 --> 05:06.000
Sixth store, part of the open source security foundation, it's a very cool project.

05:06.000 --> 05:18.000
They use open ID authentication like you'll get up account to create temporary key pair and a certificate sign you'll commit

05:18.000 --> 05:27.000
and throw away the certificate because the stored transaction in a secure log with timestamps, secure timestamps.

05:27.000 --> 05:34.000
See how one time certificates don't tell the environmental people, but we throw them away basically.

05:34.000 --> 05:36.000
It's cool technology.

05:36.000 --> 05:46.000
I like the software I like the solution, but the implementation that people use is running on US servers in the cloud.

05:46.000 --> 05:54.000
And you have to provide your email address as proof or the ID use in your authentication system.

05:54.000 --> 06:04.000
It's not very likely that European corporations will connect their systems to this because that will likely be a GDP or violation.

06:04.000 --> 06:06.000
That's very cool.

06:06.000 --> 06:12.000
But again, it's not a solution for everyone, but I like the ideas.

06:12.000 --> 06:17.000
Let's encrypt recently, it's turned off signing.

06:17.000 --> 06:25.000
I really appreciate their work, they've done miracles for the WebPKI by handing out free certificates.

06:25.000 --> 06:30.000
And maybe we can discuss with them if they can help us with solutions.

06:30.000 --> 06:35.000
Open source traditionally use GPT keys.

06:35.000 --> 06:41.000
But in the old days here at first, they had huge signing parties outside.

06:41.000 --> 06:49.000
Now there's food trucks everywhere, but not signing out of my keys, sadly.

06:49.000 --> 06:52.000
But the best current practice have disappeared.

06:52.000 --> 06:57.000
There are so many projects to say, well, you used all my Devion Ripple.

06:57.000 --> 07:03.000
Just download with curl, the key and automatically pop pipe it into.

07:03.000 --> 07:05.000
And it doesn't give me the fingerprint.

07:05.000 --> 07:07.000
I can't validate the key.

07:07.000 --> 07:11.000
It's blindly have to accept that I have to do this in order to sign.

07:11.000 --> 07:13.000
And the user doesn't know what he's doing.

07:13.000 --> 07:17.000
But he's installing a trust anchor from unknown sources.

07:17.000 --> 07:21.000
That's not a good solution.

07:21.000 --> 07:24.000
Managing a private PKI is hard.

07:24.000 --> 07:35.000
I've spent not last summer, but some of the before writing PKI policies for kind of high critical software cloud system.

07:35.000 --> 07:39.000
And it turned out that the management did understand anything.

07:39.000 --> 07:41.000
I totally failed.

07:41.000 --> 07:45.000
Well, I won't tell you the solution, but it's not a good one.

07:45.000 --> 07:49.000
Like, keys in a pocket somewhere.

07:49.000 --> 07:58.000
So, six store by throwing away the keys escape the key management problem.

07:58.000 --> 08:02.000
Now, if we are going to develop something new,

08:02.000 --> 08:06.000
we need to figure out how to build trust for that.

08:06.000 --> 08:10.000
And we have different models that we have been used.

08:10.000 --> 08:16.000
Trust is normally something you earn, but in the web it's forced upon us.

08:16.000 --> 08:24.000
When you buy fancy computers like this one, someone has paid Apple for being part of the key store.

08:24.000 --> 08:30.000
And immediately I have to trust everything that's in that key store and that applies to all other systems as well.

08:30.000 --> 08:38.000
So, that's one reason why I think the WebPKI is broken.

08:38.000 --> 08:46.000
But we're trying to do, like, have a linear over here who's a contributor in the Transparency Exchange API.

08:46.000 --> 08:56.000
We're trying to build an API server where you can find for a given product various artifacts.

08:56.000 --> 08:59.000
But let's stay on the S-Bong.

08:59.000 --> 09:06.000
You want to download S-Bong for every given release or the product you have to see what's in there.

09:06.000 --> 09:12.000
And that API server is typically protected by a let's encrypt certificates.

09:12.000 --> 09:18.000
So, we have some level of trust otherwise you wouldn't connect to that server.

09:18.000 --> 09:20.000
Right?

09:20.000 --> 09:26.000
So, the key client that downloads this could be UbOS dependency track.

09:26.000 --> 09:30.000
We'll automatically download and trust these servers.

09:30.000 --> 09:37.000
So, maybe I think, and I've been trying to discuss this with various people.

09:37.000 --> 09:46.000
Yeah, they kind of accept this, that under the trust layer we established with a let's encrypt TLS certificate or any other one.

09:46.000 --> 10:00.000
Maybe we can create trust for a new sign-sirt that only applies to that producer, the open source project or the manufacturer.

10:00.000 --> 10:10.000
But the problem here is that we just created a new PKI and we have keys to manage keys to protect.

10:10.000 --> 10:12.000
Someone needs to do that.

10:12.000 --> 10:13.000
Yeah.

10:13.000 --> 10:18.000
That's another piece of the puzzle that makes it hard.

10:18.000 --> 10:21.000
For people like me, you'll possibly see them.

10:21.000 --> 10:23.000
Ah, that's easy.

10:23.000 --> 10:24.000
So, we can do this problem.

10:24.000 --> 10:25.000
We've done this before.

10:25.000 --> 10:31.000
But most people haven't spent a life with ASN.1 and X5 and X3 tickets.

10:31.000 --> 10:40.000
So, I really want to get help to find a simplified solution still with a lot of trust.

10:40.000 --> 10:43.000
Something has clever as a CIG store.

10:43.000 --> 10:46.000
We need simple key management.

10:46.000 --> 10:50.000
In the best possible load keys that we can throw away.

10:50.000 --> 10:54.000
Simple trust anchor establishment.

10:54.000 --> 10:56.000
Distributed.

10:56.000 --> 10:58.000
Right?

10:58.000 --> 11:02.000
With respect to privacy.

11:02.000 --> 11:05.000
Dear Santa, please.

11:05.000 --> 11:06.000
Right.

11:06.000 --> 11:09.000
So, cool stuff.

11:09.000 --> 11:13.000
I'm involved in the ITF dance working group.

11:13.000 --> 11:15.000
We need more dancers.

11:15.000 --> 11:23.000
Maybe you know Dane, the ability to validate or store even CS certificates in the NSIC.

11:23.000 --> 11:28.000
Dance is about client certificates in the NSIC.

11:28.000 --> 11:30.000
That's really cool technology.

11:30.000 --> 11:36.000
But maybe we can establish trust in the NSIC as well as deliver the certificate under the

11:36.000 --> 11:42.000
Let's encrypt thing and have fingerprints on websites in a well-known address.

11:42.000 --> 11:45.000
I don't know.

11:45.000 --> 11:49.000
There are projects that work on the transparency side.

11:49.000 --> 11:54.000
There's a secondary problem, but I think that's going to be really, really critical.

11:54.000 --> 12:01.000
As a customer, you probably want someone to watch the manufacturer as well.

12:01.000 --> 12:05.000
Here's a pointer to transparency exchange API.

12:05.000 --> 12:08.000
And I believe we have stickers as well.

12:08.000 --> 12:11.000
So, let's discuss this.

12:11.000 --> 12:13.000
Here's some pointers.

12:13.000 --> 12:17.000
And I believe we have time for questions.

12:17.000 --> 12:20.000
Yes.

12:20.000 --> 12:29.000
Thank you.

12:29.000 --> 12:35.000
I went very fast that everyone was like, oh, is this how fast they're just going to be?

12:35.000 --> 12:36.000
Any questions?

12:36.000 --> 12:38.000
Up there.

12:38.000 --> 12:41.000
And we have a runner.

12:41.000 --> 12:47.000
You mentioned the issue with six stories that it's still trusting on being hosted somewhere

12:47.000 --> 12:53.000
in the US, but as far as understanding it's an open stack, so we could just host ourselves.

12:53.000 --> 12:54.000
Oh, yeah.

12:54.000 --> 12:55.000
I might not.

12:55.000 --> 12:56.000
Yep.

12:56.000 --> 12:59.000
But that requires resource and organization, but it's a good thing.

12:59.000 --> 13:07.000
But I don't still think that corporations will have problems connecting their AD and exposing

13:07.000 --> 13:12.000
their employee names and email addresses, which is typical authentication handle

13:12.000 --> 13:15.000
to any service outside the corporation.

13:15.000 --> 13:24.000
But yeah, maybe.

13:24.000 --> 13:26.000
Question here.

13:26.000 --> 13:27.000
Yeah.

13:27.000 --> 13:28.000
Go ahead.

13:28.000 --> 13:30.000
I'll repeat it.

13:30.000 --> 13:35.000
I have feelings that there is an elephant in the room.

13:35.000 --> 13:42.000
It is identity when we're talking about trusting something.

13:42.000 --> 13:50.000
The point that is not usually discussed is what is that what we want to trust

13:50.000 --> 13:53.000
or does don't trust.

13:53.000 --> 13:56.000
And it is actually very not real.

13:56.000 --> 14:03.000
It's not like some social networks trying to make official,

14:03.000 --> 14:07.000
or make it up the usual official names and so on.

14:07.000 --> 14:15.000
The identity that we want to trust is the entities that created that thing that we already

14:15.000 --> 14:17.000
trust, usually.

14:17.000 --> 14:18.000
Yep.

14:18.000 --> 14:30.000
I think it makes sense to think of certificate chains and web of trust and so on in terms of such entities.

14:30.000 --> 14:34.000
Who produced the things that we already used?

14:34.000 --> 14:35.000
Okay.

14:35.000 --> 14:39.000
That was a very long question at the end.

14:39.000 --> 14:42.000
But I think you're on the right path.

14:42.000 --> 14:45.000
I've been wondering about this.

14:45.000 --> 14:52.000
What is the entity in the certificate that we're handing out that connects to the

14:52.000 --> 14:57.000
real identity of the open source project and the manufacturer and how do we trust the

14:57.000 --> 14:58.000
connection between that?

14:58.000 --> 15:03.000
That's a classical PKI problem, a leap of faith problem.

15:03.000 --> 15:10.000
Let's encrypt to main validation and say that whoever has a domain that's good enough for us.

15:10.000 --> 15:17.000
Other systems require blood samples and driving license or we did parents or something.

15:17.000 --> 15:20.000
Depending on the transaction, I have a CA by the way.

15:20.000 --> 15:22.000
I want to make a commercial announcement.

15:22.000 --> 15:26.000
I can't sign any CSR you sent to me.

15:26.000 --> 15:32.000
If you provide me with two bottles of good French wine, I'll trust anything.

15:32.000 --> 15:34.000
Yeah.

15:34.000 --> 15:37.000
There's a competition here.

15:37.000 --> 15:40.000
Also French wine or German?

15:40.000 --> 15:41.000
Yeah.

15:41.000 --> 15:43.000
Beer will do.

15:43.000 --> 15:44.000
Okay.

15:44.000 --> 15:47.000
So, yeah, absolutely.

15:48.000 --> 15:51.000
And this is a critical issue in ITF as well.

15:51.000 --> 15:57.000
Many ITF overseas and drafts say that all valid ATLS, but doesn't say we'd

15:57.000 --> 15:59.000
want or how.

15:59.000 --> 16:04.000
I've been working in SIP and in SIP, we have a SIP UI that we use DNSSR.

16:04.000 --> 16:08.000
We record the change, we can end up with very different domains than the SIP

16:08.000 --> 16:10.000
UI and get the TLS search.

16:10.000 --> 16:12.000
We've got that says good news.

16:12.000 --> 16:13.000
Watch.

16:13.000 --> 16:15.000
Oh, no story, another talk.

16:15.000 --> 16:17.000
More questions.

16:17.000 --> 16:19.000
Over there, microphone.

16:27.000 --> 16:33.000
I'm actually working on a solution that bites, answered your question.

16:33.000 --> 16:36.000
An open source solution, of course.

16:36.000 --> 16:37.000
Oh, you message me.

16:37.000 --> 16:38.000
Yeah.

16:38.000 --> 16:39.000
Thank you.

16:39.000 --> 16:42.000
I've been working on this for one year.

16:42.000 --> 16:49.000
And one decision I took is to go for multi-sig signature.

16:49.000 --> 16:54.000
So, that multiple entities have to sign the release.

16:54.000 --> 16:59.000
I'm working focusing on releases on GitHub and GitHub for the moment.

16:59.000 --> 17:04.000
And I wanted to know what we thought about this approach of multi-signature,

17:04.000 --> 17:08.000
because it adds the management of the private key.

17:08.000 --> 17:11.000
The solution only works with the key pair.

17:11.000 --> 17:14.000
So there's no account to be created.

17:14.000 --> 17:18.000
But then we add the problem of ending the private key,

17:18.000 --> 17:21.000
like you said, the PKI infrastructure.

17:21.000 --> 17:27.000
But do you think that going for the multi-signature is helping, in that case,

17:27.000 --> 17:33.000
because if one developer loses access to the private key or

17:33.000 --> 17:39.000
it is stolen, we still have the protection of the multi-sig.

17:39.000 --> 17:42.000
What's your thought about that?

17:42.000 --> 17:47.000
At this point, I want to brainstorm and just take in all ideas.

17:47.000 --> 17:50.000
I think multi-signature, I haven't thought about that.

17:50.000 --> 17:51.000
That sounds pretty cool.

17:51.000 --> 17:57.000
Let me think about it and see how we continue.

17:57.000 --> 18:00.000
I want to look at the project.

18:00.000 --> 18:05.000
I didn't have time to add it.

18:05.000 --> 18:10.000
So there was a question here for what's the name of the project,

18:10.000 --> 18:12.000
the name is asvalued.

18:12.000 --> 18:17.000
You can go to asvalued.com or github.com slash asvalued slash asvalued.

18:17.000 --> 18:19.000
It's completely open source.

18:19.000 --> 18:21.000
It's MPLV2.

18:21.000 --> 18:23.000
Developed in Rust.

18:23.000 --> 18:26.000
The backend is ADPLV3.

18:27.000 --> 18:32.000
I'm really invested in open source since 25 years.

18:32.000 --> 18:35.000
Also in Foss Dam.

18:35.000 --> 18:38.000
So my focus is the open source solution.

18:38.000 --> 18:43.000
I'm trying to sell the project, not for dollars or euros, but trying to

18:43.000 --> 18:44.000
promote security.

18:44.000 --> 18:45.000
Good.

18:45.000 --> 18:48.000
Very interested in getting feedback.

18:48.000 --> 18:53.000
If you think this is a bad idea, please mail me that I stop working on it.

18:54.000 --> 18:57.000
Okay, so I'm really interested in feedback.

18:57.000 --> 18:58.000
Thank you.

18:58.000 --> 18:59.000
Great.

18:59.000 --> 19:00.000
We'll make sure you get feedback.

19:00.000 --> 19:02.000
Anthony and the red up there.

19:02.000 --> 19:06.000
So maybe try to post the link to the metrics channel of security.

19:06.000 --> 19:09.000
It will be probably better for people to pick it up from the link,

19:09.000 --> 19:11.000
rather than from the work.

19:11.000 --> 19:12.000
Okay.

19:17.000 --> 19:19.000
I don't understand PKI.

19:19.000 --> 19:21.000
But I understand the issue of federated.

19:21.000 --> 19:23.000
So what's the solution?

19:23.000 --> 19:28.000
So can we not take six door to make six door federated?

19:28.000 --> 19:30.000
Oh, good idea.

19:30.000 --> 19:32.000
It requires work.

19:32.000 --> 19:34.000
Cool stuff.

19:34.000 --> 19:41.000
I'm kind of liked idea that anchoring something in DNS.

19:41.000 --> 19:45.000
Many people don't like that, but we have to trust DNS.

19:45.000 --> 19:53.000
And we have a route in the talk with ICANN that we have to trust anyway.

19:53.000 --> 20:00.000
So we can base a federation upon that single point of trust that we have to trust anyway.

20:00.000 --> 20:04.000
So a federation version of the six story?

20:04.000 --> 20:05.000
Absolutely.

20:05.000 --> 20:06.000
Let's investigate that.

20:06.000 --> 20:08.000
Any more questions?

20:08.000 --> 20:11.000
We have a few minutes left.

20:12.000 --> 20:14.000
Over there.

20:14.000 --> 20:17.000
Microphone.

20:17.000 --> 20:20.000
Okay, but the trust is not the only issue,

20:20.000 --> 20:26.000
because it seems like that we solved trust, which is not easy.

20:26.000 --> 20:32.000
We have 90% of the work, but a model software,

20:32.000 --> 20:38.000
use a lot of dependencies, which means a lot of things to validate.

20:38.000 --> 20:43.000
And these things change rapidly, because when I have a lot of dependencies,

20:43.000 --> 20:49.000
they change at least I have some change daily or even more.

20:49.000 --> 20:51.000
It's a resource issue.

20:51.000 --> 20:56.000
It's also a resource issue because it's a resource issue for small projects,

20:56.000 --> 21:00.000
because it requires a discrete amount of resources.

21:00.000 --> 21:01.000
Yep.

21:01.000 --> 21:02.000
I don't have solutions.

21:02.000 --> 21:04.000
I don't have solutions.

21:04.000 --> 21:08.000
But that part, the supply chain and all our dependencies,

21:08.000 --> 21:13.000
is something that people work on in OSP cycle and the X,

21:13.000 --> 21:15.000
in OpenSSF.

21:15.000 --> 21:18.000
We have a lot of groups working on S-POM, in ORCVG.

21:18.000 --> 21:23.000
We have a lot of work because of the CRA and dependencies and other things.

21:23.000 --> 21:26.000
So a lot of work on dependencies is going on,

21:26.000 --> 21:30.000
but none is looking into the signatures,

21:30.000 --> 21:32.000
and that's a real missing piece.

21:32.000 --> 21:34.000
It will take some time.

21:34.000 --> 21:37.000
But I really think that we need to do something.

21:37.000 --> 21:41.000
I don't know how, but if you are interested in this discussion,

21:41.000 --> 21:46.000
if you want to contribute with cool ideas, questions

21:46.000 --> 21:50.000
that we have to answer requirements or solutions,

21:50.000 --> 21:53.000
please contact me over one of these channels,

21:53.000 --> 21:56.000
and I will try to organize a meeting.

21:56.000 --> 21:59.000
We'll see if we can find a home for this work.

21:59.000 --> 22:03.000
Many organizations related,

22:03.000 --> 22:06.000
who could be a good home for this.

22:06.000 --> 22:09.000
But let's start with having a discussion.

22:09.000 --> 22:13.000
So please follow up if you're interested, contact me,

22:13.000 --> 22:17.000
and I'll set up meeting lists and meetings and do the cool stuff

22:17.000 --> 22:18.000
that's needed.

22:18.000 --> 22:20.000
Thank you very much.

22:20.000 --> 22:24.000
Actually, we have three more minutes, and there's another question.

22:25.000 --> 22:27.000
Oh, we have a question.

22:27.000 --> 22:28.000
We have three more minutes.

22:28.000 --> 22:31.000
So if you want to leave the room, please do it quietly.

22:31.000 --> 22:34.000
There's another question from Matrix from Howby.

22:34.000 --> 22:37.000
He says that's maybe beyond the topic of the talk,

22:37.000 --> 22:39.000
but his question is,

22:39.000 --> 22:43.000
hey, hey, we have more questions.

22:43.000 --> 22:44.000
I'm sorry.

22:44.000 --> 22:45.000
I didn't see that.

22:45.000 --> 22:46.000
Yeah.

22:46.000 --> 22:47.000
So the question is,

22:47.000 --> 22:50.000
what assigning artifacts help without being able to verify

22:50.000 --> 22:53.000
the whole supply chain by reproducing the binaries,

22:53.000 --> 22:55.000
starting at the git commit ID,

22:55.000 --> 22:57.000
which would also wouldn't include

22:57.000 --> 23:00.000
to verify and reproduce the build infrastructure.

23:00.000 --> 23:04.000
That's a very, very good question,

23:04.000 --> 23:10.000
but also topic for a lot of other work in other groups.

23:10.000 --> 23:11.000
And that's work that's going on.

23:11.000 --> 23:14.000
How to trust the supply chain artifacts,

23:14.000 --> 23:16.000
how to trust the bills you're getting,

23:16.000 --> 23:18.000
and getting attestation of the bills,

23:18.000 --> 23:21.000
like when you download packages to Debian,

23:21.000 --> 23:23.000
where things, where did that come from?

23:23.000 --> 23:25.000
And is the call in Debian,

23:25.000 --> 23:27.000
the call that Daniel releases?

23:27.000 --> 23:29.000
It's called with a lot of patches.

23:29.000 --> 23:32.000
The Daniel doesn't know about.

23:32.000 --> 23:35.000
But there are people working on that.

23:35.000 --> 23:39.000
That's a topic that's been handled in many groups.

23:39.000 --> 23:42.000
I want to have a shock focus on

23:42.000 --> 23:44.000
the signatures on the trust.

23:44.000 --> 23:46.000
Here.

23:46.000 --> 23:48.000
Thank you very much.

23:48.000 --> 23:49.000
Thank you.

23:49.000 --> 23:51.000
Thank you.

24:01.000 --> 24:02.000
Thank you.

24:02.000 --> 24:04.000
Don't go out with me.

24:19.000 --> 24:21.000
Thank you.