Hi, I'm Oula. I'm a security a whole week and I have a problem.
Great. Highly. That's the problem, sir. Let's go. I have a problem because I'm working
in Oula's with a cyclone DX, industry working group and we're also developing a new API.
And we're going to deliver a lot of documents surrounding software across the supply chain.
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.
And that nothing is changed really. So we need many customers to trust many vendors. You see how this scales critically.
In a given manufacturer project, according to the CRA terminology, manufacturer, they can have thousands of upstream open source projects.
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.
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.
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.
And why there's a need for a software signing certificate, unless it looks the distribution of mobile apps or something.
So we need to implement trust and transparency across the software supply chain. So I've been looking for solutions.
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.
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.
We have some ideas in the West Transparency Exchange API that I want to share with you.
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,
I think the start looking after Windows saying, oh, it's a beautiful day.
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,
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.
So we need to be able to sign, we need to be able to validate and trust these signatures.
Both for an open source project, but also for commercial vendors.
We need to build this without giving away the business to American CS, we're recording this.
You know them.
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.
And I'm also looking into transparency.
How many here and no certificate transparency on the web API?
A few of you, we monitor the public C-A, the sign certificates for webs and other things,
and see every single certificate they issued to make me sure that we can monitor what they do,
that they actually have some trust in their systems.
But that's another thing.
And this is a global problem, right?
And that's very important to recognize because there's not much happening on this side or the pond.
Sixth store, part of the open source security foundation, it's a very cool project.
They use open ID authentication like you'll get up account to create temporary key pair and a certificate sign you'll commit
and throw away the certificate because the stored transaction in a secure log with timestamps, secure timestamps.
See how one time certificates don't tell the environmental people, but we throw them away basically.
It's cool technology.
I like the software I like the solution, but the implementation that people use is running on US servers in the cloud.
And you have to provide your email address as proof or the ID use in your authentication system.
It's not very likely that European corporations will connect their systems to this because that will likely be a GDP or violation.
That's very cool.
But again, it's not a solution for everyone, but I like the ideas.
Let's encrypt recently, it's turned off signing.
I really appreciate their work, they've done miracles for the WebPKI by handing out free certificates.
And maybe we can discuss with them if they can help us with solutions.
Open source traditionally use GPT keys.
But in the old days here at first, they had huge signing parties outside.
Now there's food trucks everywhere, but not signing out of my keys, sadly.
But the best current practice have disappeared.
There are so many projects to say, well, you used all my Devion Ripple.
Just download with curl, the key and automatically pop pipe it into.
And it doesn't give me the fingerprint.
I can't validate the key.
It's blindly have to accept that I have to do this in order to sign.
And the user doesn't know what he's doing.
But he's installing a trust anchor from unknown sources.
That's not a good solution.
Managing a private PKI is hard.
I've spent not last summer, but some of the before writing PKI policies for kind of high critical software cloud system.
And it turned out that the management did understand anything.
I totally failed.
Well, I won't tell you the solution, but it's not a good one.
Like, keys in a pocket somewhere.
So, six store by throwing away the keys escape the key management problem.
Now, if we are going to develop something new,
we need to figure out how to build trust for that.
And we have different models that we have been used.
Trust is normally something you earn, but in the web it's forced upon us.
When you buy fancy computers like this one, someone has paid Apple for being part of the key store.
And immediately I have to trust everything that's in that key store and that applies to all other systems as well.
So, that's one reason why I think the WebPKI is broken.
But we're trying to do, like, have a linear over here who's a contributor in the Transparency Exchange API.
We're trying to build an API server where you can find for a given product various artifacts.
But let's stay on the S-Bong.
You want to download S-Bong for every given release or the product you have to see what's in there.
And that API server is typically protected by a let's encrypt certificates.
So, we have some level of trust otherwise you wouldn't connect to that server.
Right?
So, the key client that downloads this could be UbOS dependency track.
We'll automatically download and trust these servers.
So, maybe I think, and I've been trying to discuss this with various people.
Yeah, they kind of accept this, that under the trust layer we established with a let's encrypt TLS certificate or any other one.
Maybe we can create trust for a new sign-sirt that only applies to that producer, the open source project or the manufacturer.
But the problem here is that we just created a new PKI and we have keys to manage keys to protect.
Someone needs to do that.
Yeah.
That's another piece of the puzzle that makes it hard.
For people like me, you'll possibly see them.
Ah, that's easy.
So, we can do this problem.
We've done this before.
But most people haven't spent a life with ASN.1 and X5 and X3 tickets.
So, I really want to get help to find a simplified solution still with a lot of trust.
Something has clever as a CIG store.
We need simple key management.
In the best possible load keys that we can throw away.
Simple trust anchor establishment.
Distributed.
Right?
With respect to privacy.
Dear Santa, please.
Right.
So, cool stuff.
I'm involved in the ITF dance working group.
We need more dancers.
Maybe you know Dane, the ability to validate or store even CS certificates in the NSIC.
Dance is about client certificates in the NSIC.
That's really cool technology.
But maybe we can establish trust in the NSIC as well as deliver the certificate under the
Let's encrypt thing and have fingerprints on websites in a well-known address.
I don't know.
There are projects that work on the transparency side.
There's a secondary problem, but I think that's going to be really, really critical.
As a customer, you probably want someone to watch the manufacturer as well.
Here's a pointer to transparency exchange API.
And I believe we have stickers as well.
So, let's discuss this.
Here's some pointers.
And I believe we have time for questions.
Yes.
Thank you.
I went very fast that everyone was like, oh, is this how fast they're just going to be?
Any questions?
Up there.
And we have a runner.
You mentioned the issue with six stories that it's still trusting on being hosted somewhere
in the US, but as far as understanding it's an open stack, so we could just host ourselves.
Oh, yeah.
I might not.
Yep.
But that requires resource and organization, but it's a good thing.
But I don't still think that corporations will have problems connecting their AD and exposing
their employee names and email addresses, which is typical authentication handle
to any service outside the corporation.
But yeah, maybe.
Question here.
Yeah.
Go ahead.
I'll repeat it.
I have feelings that there is an elephant in the room.
It is identity when we're talking about trusting something.
The point that is not usually discussed is what is that what we want to trust
or does don't trust.
And it is actually very not real.
It's not like some social networks trying to make official,
or make it up the usual official names and so on.
The identity that we want to trust is the entities that created that thing that we already
trust, usually.
Yep.
I think it makes sense to think of certificate chains and web of trust and so on in terms of such entities.
Who produced the things that we already used?
Okay.
That was a very long question at the end.
But I think you're on the right path.
I've been wondering about this.
What is the entity in the certificate that we're handing out that connects to the
real identity of the open source project and the manufacturer and how do we trust the
connection between that?
That's a classical PKI problem, a leap of faith problem.
Let's encrypt to main validation and say that whoever has a domain that's good enough for us.
Other systems require blood samples and driving license or we did parents or something.
Depending on the transaction, I have a CA by the way.
I want to make a commercial announcement.
I can't sign any CSR you sent to me.
If you provide me with two bottles of good French wine, I'll trust anything.
Yeah.
There's a competition here.
Also French wine or German?
Yeah.
Beer will do.
Okay.
So, yeah, absolutely.
And this is a critical issue in ITF as well.
Many ITF overseas and drafts say that all valid ATLS, but doesn't say we'd
want or how.
I've been working in SIP and in SIP, we have a SIP UI that we use DNSSR.
We record the change, we can end up with very different domains than the SIP
UI and get the TLS search.
We've got that says good news.
Watch.
Oh, no story, another talk.
More questions.
Over there, microphone.
I'm actually working on a solution that bites, answered your question.
An open source solution, of course.
Oh, you message me.
Yeah.
Thank you.
I've been working on this for one year.
And one decision I took is to go for multi-sig signature.
So, that multiple entities have to sign the release.
I'm working focusing on releases on GitHub and GitHub for the moment.
And I wanted to know what we thought about this approach of multi-signature,
because it adds the management of the private key.
The solution only works with the key pair.
So there's no account to be created.
But then we add the problem of ending the private key,
like you said, the PKI infrastructure.
But do you think that going for the multi-signature is helping, in that case,
because if one developer loses access to the private key or
it is stolen, we still have the protection of the multi-sig.
What's your thought about that?
At this point, I want to brainstorm and just take in all ideas.
I think multi-signature, I haven't thought about that.
That sounds pretty cool.
Let me think about it and see how we continue.
I want to look at the project.
I didn't have time to add it.
So there was a question here for what's the name of the project,
the name is asvalued.
You can go to asvalued.com or github.com slash asvalued slash asvalued.
It's completely open source.
It's MPLV2.
Developed in Rust.
The backend is ADPLV3.
I'm really invested in open source since 25 years.
Also in Foss Dam.
So my focus is the open source solution.
I'm trying to sell the project, not for dollars or euros, but trying to
promote security.
Good.
Very interested in getting feedback.
If you think this is a bad idea, please mail me that I stop working on it.
Okay, so I'm really interested in feedback.
Thank you.
Great.
We'll make sure you get feedback.
Anthony and the red up there.
So maybe try to post the link to the metrics channel of security.
It will be probably better for people to pick it up from the link,
rather than from the work.
Okay.
I don't understand PKI.
But I understand the issue of federated.
So what's the solution?
So can we not take six door to make six door federated?
Oh, good idea.
It requires work.
Cool stuff.
I'm kind of liked idea that anchoring something in DNS.
Many people don't like that, but we have to trust DNS.
And we have a route in the talk with ICANN that we have to trust anyway.
So we can base a federation upon that single point of trust that we have to trust anyway.
So a federation version of the six story?
Absolutely.
Let's investigate that.
Any more questions?
We have a few minutes left.
Over there.
Microphone.
Okay, but the trust is not the only issue,
because it seems like that we solved trust, which is not easy.
We have 90% of the work, but a model software,
use a lot of dependencies, which means a lot of things to validate.
And these things change rapidly, because when I have a lot of dependencies,
they change at least I have some change daily or even more.
It's a resource issue.
It's also a resource issue because it's a resource issue for small projects,
because it requires a discrete amount of resources.
Yep.
I don't have solutions.
But that part, the supply chain and all our dependencies,
is something that people work on in OSP cycle and the X,
in OpenSSF.
We have a lot of groups working on S-POM, in ORCVG.
We have a lot of work because of the CRA and dependencies and other things.
So a lot of work on dependencies is going on,
but none is looking into the signatures,
and that's a real missing piece.
It will take some time.
But I really think that we need to do something.
I don't know how, but if you are interested in this discussion,
if you want to contribute with cool ideas, questions
that we have to answer requirements or solutions,
please contact me over one of these channels,
and I will try to organize a meeting.
We'll see if we can find a home for this work.
Many organizations related,
who could be a good home for this.
But let's start with having a discussion.
So please follow up if you're interested, contact me,
and I'll set up meeting lists and meetings and do the cool stuff
that's needed.
Thank you very much.
Actually, we have three more minutes, and there's another question.
Oh, we have a question.
We have three more minutes.
So if you want to leave the room, please do it quietly.
There's another question from Matrix from Howby.
He says that's maybe beyond the topic of the talk,
but his question is,
hey, hey, we have more questions.
I'm sorry.
I didn't see that.
Yeah.
So the question is,
what assigning artifacts help without being able to verify
the whole supply chain by reproducing the binaries,
starting at the git commit ID,
which would also wouldn't include
to verify and reproduce the build infrastructure.
That's a very, very good question,
but also topic for a lot of other work in other groups.
And that's work that's going on.
How to trust the supply chain artifacts,
how to trust the bills you're getting,
and getting attestation of the bills,
like when you download packages to Debian,
where things, where did that come from?
And is the call in Debian,
the call that Daniel releases?
It's called with a lot of patches.
The Daniel doesn't know about.
But there are people working on that.
That's a topic that's been handled in many groups.
I want to have a shock focus on
the signatures on the trust.
Here.
Thank you very much.
Thank you.
Don't go out with me.
Thank you.