Thank you very much for coming everyone.
So today I want to talk about SQ, which is our command line tool, command line tool for
using OpenPQP, specifically using the Sequoia PCHP library and the infrastructure which
we've been developing for the past seven years.
So what is Sequoia PCHP?
The easiest answer is it's an OpenPQP implementation, but it's actually much more than just
an implementation.
It's a lot of infrastructure.
Privacy and security tooling, and I'm careful to say not necessarily openPGP tooling,
because we view OpenPQP not as an end in and of itself, but we think that it's a pretty
good protocol, and we want to build tooling and applications on top in order to help protect
individuals, privacy, and security.
The goals of the project are to create libraries and applications that are secure, robust,
and usable.
Those are the three things that I always have in mind when I'm working on Sequoia.
Is it secure, is it robust, and is it usable?
And I think usability is particularly important in the context of the security application,
because if it's not usable, it's easy to make mistakes, and doesn't matter how good your
code is, if the human makes mistake, there's no security.
The design of Sequoia is that it's a library first approach.
Now, that may be obvious, but that's the way it is.
At the bottom we have a library that implements all of the OpenPQP specification.
It's low level.
That means that the interfaces are unopinulated.
They don't tell you how to use OpenPQP, they can sort of propose the mechanisms.
And we've designed the mechanisms to be safe by default, and that's really important.
We think for usability.
So the easy way to do something is more or less the right and safe way, which doesn't
mean that you can't do things that are stupid, or dangerous, because sometimes you need
to do those things, but we try to design the API so that it's safe by default.
On top of the low level API, we have these mid-level services, and then we have our
applications.
And as you go up the stack, the interface gets more and more opinionated.
That means that it's easier for the human to use, because they don't have to understand
the protocol as much, and the thing that we tried really hard to do is that when somebody
is using these interfaces, it's possible to say, oh, it's too opinionated, it's doing
something that I don't want, I'm going to go down one level in the stack, and I don't
have to rewrite all of my code, but because we're using the same data types as possible
to then tweak the behavior of the higher level interfaces.
We have optional services, so for instance, we have a certificate store, that's where
the certificates are stored.
Now, every program needs a certificate store, yes.
If you're doing OpenPQP somehow, you have to be using certificates.
But maybe you already have a service that has a database with a postgres table, and there's
a user table, and then you just add a column for the OpenPQP certificate.
All right, you're done.
You don't have to use our certificate store.
You already have a certificate store, because put the certificates in there.
And the other thing that we were doing while we were developing Sequoia was reevaluating
existing paradigms, which means that OpenPQP
is over 31 years old, people have ideas about how it should be used, and we think that
some of those are okay, and some of those can be improved upon, and we questioned everything,
and we came up with some different answers.
And I think you'll see some of that soon.
So what are the components?
Well, at the bottom of the tree, which is at the top of the slide, we have OpenPQP,
which is our low-level library, and then we have a whole bunch of middleware on top.
We have a certificate store, a web of trust engine, a network access, auto-crypt configuration
policy, and there are other things that I didn't show here.
And then we have, for instance, SQ, which is our command line tool, and it uses all of
these high-level libraries and services and provides something even more high-level design
for end users.
Our PM is another program that uses Sequoia.
It doesn't use all of these things.
It doesn't use CQC material.
It has its own certificate store implementation.
It's actually using the same specification that we're using, which is the shared OpenPQP
directory.
Our PM has its own trust model, but it does use the configuration policy framework
that we have.
So finally, we're getting to SQ, which is really the meat of the topic today.
It's a command line tool.
It has a sub-command style interface.
Two examples here are SQC Generate, so we have, for instance, T, which is sort of all
of the functionality related to T management, and then you can generate our certificate.
SQ Network Search, we have a whole bunch of network related functionality, search means
go out on the network and find a certificate given some identifier.
All right, it's a high-level interface.
It's very focused on end user workflows, and if you're unhappy with that, because you want
to use it in a script, which is OK, then you shouldn't be using SQ, it's not for everybody.
If you really need to do the dangerous stuff, then you should be using the libraries.
And SQ now has a stable CLI, released version 1.0, this past December, and the promise
that we made with 1.0 is that we're not going to break the API anymore.
So we have a mechanism for doing future compatible changes, and backward compatible changes,
but you can now write scripts, and you can expect them to continue to work.
And one of the interesting things I think is that SQ can be operated in a stateless mode,
which means that you don't have to set up a home directory whenever you do some sort
of operations.
It can work all in memory, and you provide the files that you want to work with.
For instance, the certificate can be in a file, you say use this certificate, which is in
this file over here, and there's no state.
So demo time.
I'm going to demo SQ, specifically 1.2.
If you're on Fedora, then you have 1.1.
If you're on RELL, you also have or RELL 10 beta, you also have 1.1.
If you're on Debian, this is a little bit older, 1.2 just came out about an hour ago.
Yeah, I had to fix a few things for the slides, but due to space constraints, the output
that we're going to see, it's been trimmed a little bit, but I've tried to be fair,
like I'm not hiding stuff.
If you run it, you're going to get slightly different output, but I had to trim this
that way of fixing.
All right, first thing first, let's verify a download.
You don't need a certificate, you don't need a key in order to verify a download, right?
And in fact, we verify downloads all the time is usually our package manager that's doing
it.
So if you're on Fedora, using RPM, if you're on Debian, using App, and DPKG, but if I download
an ISO, for instance, of Fedora, or if I download cubes, then I have to manually verify.
So how do I do that?
So our goal is to download the latest version of cubes, and we want to verify the signature.
We have a command, it's called SQ Download, it downloads the signature and the file, it
verifies the signature, and it only releases the data if the signature is valid.
So you can't accidentally use bad data.
It forces you to make sure that the signature is valid, and we'll see what exactly it means,
signature is valid.
So first try, I completely naive, we go to the website, we find the URLs, so we do SQ Download,
the first thing we put in is the signature, the Detack Signature.
That's the.pgp.air.airc file, in this case, this.airc, then the URL of the file that we
want to download, and then where we want to put it, dash-alput cubes that I assume.
One thing that we try to do in SQ is that we don't guess, we avoid guessing, we don't
do what I mean interfaces, because we find that do what I mean is a little bit dangerous.
You don't want to accidentally overwrite a file, you don't want to put it someplace, wrong
place, you have to be explicit.
When we immediately get an error, we can't verify the signature, because we don't have
certificates for any of the alleged signers.
So here it's telling us the fingerprint of the certificate that's missing, but it gives
us a hint.
It says, here, go ahead, try this, try searching the public directories, SQ Not Work Search.
And the reason that we don't do that automatically is because it's a privacy concern.
When we go out onto the network, then we're revealing to the network that we're looking
for this particular thing, and maybe our adversary cares that we're doing this, and then
it's going to give us bad data, so that wouldn't be so great.
So we get the certificate, SQ Not Work Search, just like I said, and so we're really happy,
right?
It says, cubes, OS, release key, sign key, that's what we're looking for.
Awesome.
Very good.
That's the bottom, but we're going to ignore, and we're immediately going to try again.
So we try again, and now it's telling us a different error message, it's saying it can't
authenticate the alleged signer.
Oh, no, we can't verify the signature, because we can't authenticate any of the signers.
And then we get another hint.
Verify one of the certificates is authenticate, authenticate, and then link it.
And here's the command that we're supposed to use, SQ, PKI, link ad.
OK, how do we authenticate a certificate?
What does that mean?
Well, authentication means figuring out what certificate belongs to a given entity.
Is this really my certificate?
Is this the cubes certificate?
Just because there's some certificate out there that has cubes in the name doesn't mean
that the cubes people created it.
Anybody can create a certificate.
So how do we find out?
We could ask the cubes community member, could ask a friend who has cubes.
We could go to the cubes stand here at Faustem, and we could say, hey, what's the certificate
that you use, or we could even go to the website, and it's linked right there.
Now using the website means that you add X509 to your trusted computing base, maybe you're
willing to do that, maybe not, it depends on your threat model.
All right, but let's say we authenticate it, we figure out what the right certificates
for cubes.
So we do this SQPK, I link add thing here, and it says Certification Created.
What exactly happens?
Well, if we take a look, we can use the SQSertList command, and we're saying, tell us information
about this certificate.
And we see the user ID, and there's a little checkmark saying that is authenticated.
And if we look here, Sequoia is saying, well, why is it authenticated?
Well, the local trust route said that this binding between the certificate and user
ID is correct, and why did they say that?
Well, we just did SQPK, I link add.
So it's pretty straightforward.
We didn't have to specify a certifier or anything.
We just said, these things belong together.
And the interesting thing is, is that this was modeled in the web of trust data.
It's not some additional mechanism on top.
It's a unified trust model.
So we can use the web of trust calculus in order to compute whether or not a binding is authentic.
Let's give it another try, SQ download just like before.
We see that it downloaded the 6.9 gigabytes of data, finished downloading the data, it authenticated
the data, it authenticated the signature, we're happy it's there, and now we can use cube.
So what happened?
We use the SQ download command, it combines the whole bunch of operations that are important,
fetching the file, fetching the detached signature, and performing diversification.
One thing that we have to do is that we have to authenticate the signer, which is a slight
burden the first time, but depending on your threat model, it's very important that you do this.
And if you're on devion, and you want to verify, for instance, a devion package, you
don't have to look all around, you already have devion installed, and the keys are
already there.
So you can go ahead and immediately link those.
And finally, the data is only released if it can be authenticated.
You can't accidentally use something that is provided by the attacker.
Alright, demo number two, let's sign a message.
Well, first we need a certificate, and then somehow we have to make it available to the recipient.
Alright, so here we have, out of love list, she wants to make a certificate.
She puts in her name, dash dash name, dash dash email, out at example.org, and then there's
this one more parameter over here, own key, which means that that's her own key, her personal key.
She's fully trusted, she's not giving it access to anybody else.
It's hers.
It's like a CA.
And then SQ key, generate conveniently prints out a little bit of information here about what
was created, the fingerprint of the new certificate, and then it even tells you what to do next.
If you want to attach it to an email, you would export it, or if you want to publish it,
then you would use SQ network key server publish.
So SQ is there for you, it's your friend, it's your guide, and now we sign the message.
So we want to do echo hello, SQ sign, and then we get the PGP message out, and we can verify it.
And when we do verify, it tells us not only that the message has been verified, but why,
and it again it shows this path here, local trust route to this certificate.
And that was because SQ key generated, created the appropriate links based on the local trust route.
And we can make a detached signature.
So we're going to do a release of some software, then we would sign it.
Again, we use SQ sign, and then we can verify it, and we see again the path.
So it's clear.
All right, let's sign a certificate.
We go to foster them, there's a key signing party, everybody goes, Alice meets Bob, actually it's odd
and meets Bob, and she vouches that Bob has a certain certificate.
And our terminology, vouch, is a public assertion, and link is a local assertion that's never exported from your computer.
So this whole local trust route stuff, even though it's saved as web of trust data,
it's not revealed to the network because it's only locally stored.
So we search for Bob's fingerprint.
We got him the business card, or whatever.
And then we do SQ PKI vouch add.
Here we have eight as a certificate, and then we have Bob's certificate,
and then we create the certifications.
And it's a little bit inconvenient here to specify the fingerprint all the time.
So you can go ahead and put in your configuration file,
and the state of saying certifier fingerprint, you would say certifier self.
And let's look at Bob's certificate now.
What do we see?
Well, if we list Bob's certificate, we see at the top again the local trust route,
because all of the trust starts at the trust route, it's a route.
And the trust route said that oddas certificate is good,
and that she's a trusted introducer.
It's her own computer, it's her own certificate.
And then oddas went ahead and made a vouch about Bob's certificate,
and user ID, and boom, we see the path.
So it's very clear what's going on, there's some transparency.
And that's important for users to understand how the system works.
All right, let's do some key management, right?
I use a key, I created it after three years, it expires.
What do I do?
Actually, it's really easy.
All you do is SQ PKI expire to change the expiration time.
And then we're going to expire it in three years from now, and we're done.
Well, that was easy.
Let's imagine that your certificate is using SHA1.
Everybody knows SHA1 is broken, right?
That's why we don't use SHA1 anymore.
Right?
Red Hat?
Okay.
This is your homework assignment.
You're going to go home, okay?
And the red Hat people here.
And you're going to generate some new certificates.
You have to make sure that they have the same user IDs.
You want them to have the same structure, right?
Because if it's a signing key, then it doesn't need encryption capable sub keys.
You need to create links between the two certificates.
You want to cross sign them.
If you made any certifications with the old certificate,
you want the new one to also make the same certifications.
And don't forget to retire the old certificate.
That's a lot of work, right?
All right.
SQK rotate, you're done.
It cross signs the old and the new certificates.
It replays the certifications and the links.
It retires the old certificate.
Super easy.
Let's create a certification authority.
Well, I don't want to create a certification authority,
because doing this whole authentication thing is a little bit annoying sometimes.
So you might be a business, an organization, a family,
and there is always somebody who is or an activist collective.
And you got somebody who is technically savvy and other people who aren't.
So you create a CA and you let them use it.
The admin vouchers for the different members of the organization.
You publish it.
The certificates and the vouchers, in for instance,
a WKD, and you have to keep them up to date, right?
The first step is really easy.
Everybody's willing to do that.
It's been half a day, setting everything off.
It's perfect.
And then a year later you have to change something.
And you have no idea anymore.
You got to keep it up to date.
All right.
So first we generate a CA key.
And here it's the same.
It's very similar to what we did before.
But we say we cannot sign.
We cannot authenticate and we cannot encrypt.
It's only for certification.
Because your CA key doesn't need to do those other things.
Then we add a vouch for auto.
And now we have to set up our WKD.
How do we do that?
SQ network WKD publish.
We specify the trust routes or our CA.
The domain is example.org.
And then we're going to ours sink it over to the web server.
And we see it's going to do auto and the CA.
And it's published on the web server and bam.
We're done.
Beautiful.
That work.
It only did the certificates that are authenticated for example.org.
So even if you have a whole bunch of junk in your certificate store.
If you haven't created vouchers for them or you haven't linked those certificates,
they don't get published.
It's completely safe to have lots of junk.
SQ only works with things that are authenticated.
All right.
So you do this one time and then you put it in a crong shop and you're done.
All right.
So let's use the CA.
How do we do it?
We want to send an email and encrypted message to auto.
We can't do it because we couldn't authenticate this certificate.
All right.
So instead of linking auto certificate,
we link the CA's certificate here.
We authorize instead of do add.
And now it's the CA.
And by the way, we have a scope here.
Only for example.org.
The CA can't be used for anything.
It's not like X509 where once you trust the CA, it's like,
Oh, anything.
No.
Very, very scope.
Very tight scope.
And then we do SQ and grips.
Works beautiful.
Everybody's happy.
Easy to use.
What happened here?
We list autos.
Certificate.
Local trust route.
CA.
Auto.
Again, that nice path.
All right.
Summary.
SQ supports high level workloads.
It guides the user with lots of hints.
SQ has some new concepts.
We have this local trust route.
We have links.
And we have mandatory authentication.
There's no curated curing.
And I'd be very happy if you take a look.
And if you want to learn more, we have a user manual,
which is really, really nice introduction.
Book.sacoyatshp.org.
We have man pages.
And in the last one or two minutes, I'd be happy to take a couple of questions.
We have three minutes for questions.
There's a question on matrix.
For by Thomas Mann, he's asking, I was using this.
But notice that UB key support doesn't seem to be available any plans for hardware key support specific.
Right.
So hardware key support in SQ.
The answer is that SQ actually supports multiple backends.
So it has its own local key store backends.
So soft keys that are stored in the file system.
It automatically uses GPG agent.
So if you've already configured GPG agent and you run SQ the first time,
you will see your GPG keys just magically appear.
Because SQ talks to GPG agents by default.
It also has support for using PCSD.
So if you use PCSD, then you can also use your UB key.
It's a little bit problematic if you have GPG agent installed.
Because by default, GPG agent will lock the OpenPGP app on your UB key.
So it's kind of one or the other, which is a little bit tricky.
Or you have to go into the advanced configuration for GPG agent and put into shared mode.
But that's kind of dangerous because as I understand it,
the locking is not guaranteed to be correct.
Can you repeat the question?
OCI Container Signing is the question?
Yeah.
So as a whole bunch of people that are actually using Sequoia,
including, for instance, Red Hat.
The Red Hat people are sitting in front of me.
So I'm picking on you.
But there's also a little bit of work to integrate it into the OCI stuff.
Dike did something there.
So I don't know the exact details because that's not my priority.
Yep.
So I want to manage the PCHP keys of the company I'm working for.
And I follow this CA creation.
Can only I do it or am I the, so am I the only failing point?
Or can I somehow put this in a Git repository and share it so that everyone who is
competent enough to access the skit can at keys or deprecate keys?
So the question was, if I'm at a company and I want to do a CA,
how would I do it?
Should I put it in a Git repository?
And I would not put the secret key material into the Git repository.
The keys that are needed for the Web Key directory.
Right.
So only the, the public keys.
So yeah, you could put them into a, a Git.
The, the way that the, the synchronization works is that it's not a one way synchronization.
It's a two way synchronization.
So SQ first downloads the whole Web Key directory.
It adds any updates they have locally.
And then it sinks it back to the server.
So you can view the Web Key directory as being like half authoritative.
And the actual authoritative part are the certifications that you make using the CA key.
It's times up as I understand it.
It's a little bit confusing.
I agree.
It's not that hard, but we should probably work it out and not right here.
Thank you very much for your work.
Thank you.