WEBVTT 00:00.000 --> 00:08.880 Thank you very much for coming everyone. 00:08.880 --> 00:13.640 So today I want to talk about SQ, which is our command line tool, command line tool for 00:13.640 --> 00:20.160 using OpenPQP, specifically using the Sequoia PCHP library and the infrastructure which 00:20.160 --> 00:23.160 we've been developing for the past seven years. 00:23.160 --> 00:26.600 So what is Sequoia PCHP? 00:26.680 --> 00:30.760 The easiest answer is it's an OpenPQP implementation, but it's actually much more than just 00:30.760 --> 00:31.760 an implementation. 00:31.760 --> 00:35.920 It's a lot of infrastructure. 00:35.920 --> 00:41.560 Privacy and security tooling, and I'm careful to say not necessarily openPGP tooling, 00:41.560 --> 00:45.720 because we view OpenPQP not as an end in and of itself, but we think that it's a pretty 00:45.720 --> 00:52.200 good protocol, and we want to build tooling and applications on top in order to help protect 00:52.200 --> 00:57.000 individuals, privacy, and security. 00:57.000 --> 01:04.640 The goals of the project are to create libraries and applications that are secure, robust, 01:04.640 --> 01:05.640 and usable. 01:05.640 --> 01:11.760 Those are the three things that I always have in mind when I'm working on Sequoia. 01:11.760 --> 01:16.400 Is it secure, is it robust, and is it usable? 01:16.400 --> 01:21.160 And I think usability is particularly important in the context of the security application, 01:21.160 --> 01:24.760 because if it's not usable, it's easy to make mistakes, and doesn't matter how good your 01:24.760 --> 01:30.600 code is, if the human makes mistake, there's no security. 01:30.600 --> 01:35.640 The design of Sequoia is that it's a library first approach. 01:35.640 --> 01:40.160 Now, that may be obvious, but that's the way it is. 01:40.160 --> 01:44.400 At the bottom we have a library that implements all of the OpenPQP specification. 01:44.400 --> 01:46.400 It's low level. 01:46.400 --> 01:49.040 That means that the interfaces are unopinulated. 01:49.080 --> 01:54.320 They don't tell you how to use OpenPQP, they can sort of propose the mechanisms. 01:54.320 --> 01:59.840 And we've designed the mechanisms to be safe by default, and that's really important. 01:59.840 --> 02:01.520 We think for usability. 02:01.520 --> 02:06.560 So the easy way to do something is more or less the right and safe way, which doesn't 02:06.560 --> 02:11.680 mean that you can't do things that are stupid, or dangerous, because sometimes you need 02:11.680 --> 02:18.040 to do those things, but we try to design the API so that it's safe by default. 02:18.040 --> 02:22.040 On top of the low level API, we have these mid-level services, and then we have our 02:22.040 --> 02:23.040 applications. 02:23.040 --> 02:30.600 And as you go up the stack, the interface gets more and more opinionated. 02:30.600 --> 02:33.640 That means that it's easier for the human to use, because they don't have to understand 02:33.640 --> 02:40.760 the protocol as much, and the thing that we tried really hard to do is that when somebody 02:40.760 --> 02:47.080 is using these interfaces, it's possible to say, oh, it's too opinionated, it's doing 02:47.080 --> 02:52.280 something that I don't want, I'm going to go down one level in the stack, and I don't 02:52.280 --> 02:56.440 have to rewrite all of my code, but because we're using the same data types as possible 02:56.440 --> 03:02.520 to then tweak the behavior of the higher level interfaces. 03:02.520 --> 03:06.920 We have optional services, so for instance, we have a certificate store, that's where 03:06.920 --> 03:08.840 the certificates are stored. 03:08.840 --> 03:12.120 Now, every program needs a certificate store, yes. 03:12.120 --> 03:15.800 If you're doing OpenPQP somehow, you have to be using certificates. 03:15.800 --> 03:23.480 But maybe you already have a service that has a database with a postgres table, and there's 03:23.480 --> 03:30.000 a user table, and then you just add a column for the OpenPQP certificate. 03:30.000 --> 03:31.000 All right, you're done. 03:31.000 --> 03:33.040 You don't have to use our certificate store. 03:33.040 --> 03:37.640 You already have a certificate store, because put the certificates in there. 03:37.640 --> 03:41.480 And the other thing that we were doing while we were developing Sequoia was reevaluating 03:41.480 --> 03:45.640 existing paradigms, which means that OpenPQP 03:45.640 --> 03:51.800 is over 31 years old, people have ideas about how it should be used, and we think that 03:51.800 --> 03:56.360 some of those are okay, and some of those can be improved upon, and we questioned everything, 03:56.360 --> 03:58.360 and we came up with some different answers. 03:58.360 --> 04:01.800 And I think you'll see some of that soon. 04:01.800 --> 04:02.760 So what are the components? 04:02.760 --> 04:07.480 Well, at the bottom of the tree, which is at the top of the slide, we have OpenPQP, 04:07.480 --> 04:12.680 which is our low-level library, and then we have a whole bunch of middleware on top. 04:12.680 --> 04:19.640 We have a certificate store, a web of trust engine, a network access, auto-crypt configuration 04:19.640 --> 04:24.760 policy, and there are other things that I didn't show here. 04:24.760 --> 04:28.480 And then we have, for instance, SQ, which is our command line tool, and it uses all of 04:28.480 --> 04:33.360 these high-level libraries and services and provides something even more high-level design 04:33.360 --> 04:36.360 for end users. 04:36.360 --> 04:40.320 Our PM is another program that uses Sequoia. 04:40.320 --> 04:42.600 It doesn't use all of these things. 04:42.600 --> 04:44.600 It doesn't use CQC material. 04:44.600 --> 04:46.760 It has its own certificate store implementation. 04:46.760 --> 04:51.720 It's actually using the same specification that we're using, which is the shared OpenPQP 04:51.720 --> 04:53.800 directory. 04:53.800 --> 04:58.360 Our PM has its own trust model, but it does use the configuration policy framework 04:58.360 --> 05:01.360 that we have. 05:01.440 --> 05:06.720 So finally, we're getting to SQ, which is really the meat of the topic today. 05:06.720 --> 05:08.560 It's a command line tool. 05:08.560 --> 05:10.720 It has a sub-command style interface. 05:10.720 --> 05:17.200 Two examples here are SQC Generate, so we have, for instance, T, which is sort of all 05:17.200 --> 05:24.320 of the functionality related to T management, and then you can generate our certificate. 05:24.320 --> 05:29.640 SQ Network Search, we have a whole bunch of network related functionality, search means 05:29.640 --> 05:33.960 go out on the network and find a certificate given some identifier. 05:33.960 --> 05:38.160 All right, it's a high-level interface. 05:38.160 --> 05:44.360 It's very focused on end user workflows, and if you're unhappy with that, because you want 05:44.360 --> 05:52.760 to use it in a script, which is OK, then you shouldn't be using SQ, it's not for everybody. 05:52.760 --> 05:58.440 If you really need to do the dangerous stuff, then you should be using the libraries. 05:58.440 --> 06:05.640 And SQ now has a stable CLI, released version 1.0, this past December, and the promise 06:05.640 --> 06:10.280 that we made with 1.0 is that we're not going to break the API anymore. 06:10.280 --> 06:15.280 So we have a mechanism for doing future compatible changes, and backward compatible changes, 06:15.280 --> 06:19.560 but you can now write scripts, and you can expect them to continue to work. 06:19.560 --> 06:24.720 And one of the interesting things I think is that SQ can be operated in a stateless mode, 06:24.720 --> 06:29.120 which means that you don't have to set up a home directory whenever you do some sort 06:29.120 --> 06:31.760 of operations. 06:31.760 --> 06:35.360 It can work all in memory, and you provide the files that you want to work with. 06:35.360 --> 06:39.240 For instance, the certificate can be in a file, you say use this certificate, which is in 06:39.240 --> 06:44.680 this file over here, and there's no state. 06:44.680 --> 06:45.680 So demo time. 06:45.680 --> 06:50.240 I'm going to demo SQ, specifically 1.2. 06:50.240 --> 06:53.720 If you're on Fedora, then you have 1.1. 06:53.720 --> 06:58.520 If you're on RELL, you also have or RELL 10 beta, you also have 1.1. 06:58.520 --> 07:07.240 If you're on Debian, this is a little bit older, 1.2 just came out about an hour ago. 07:07.240 --> 07:14.360 Yeah, I had to fix a few things for the slides, but due to space constraints, the output 07:14.360 --> 07:18.360 that we're going to see, it's been trimmed a little bit, but I've tried to be fair, 07:18.360 --> 07:20.040 like I'm not hiding stuff. 07:20.040 --> 07:22.840 If you run it, you're going to get slightly different output, but I had to trim this 07:22.840 --> 07:24.840 that way of fixing. 07:24.840 --> 07:28.760 All right, first thing first, let's verify a download. 07:28.760 --> 07:33.240 You don't need a certificate, you don't need a key in order to verify a download, right? 07:33.240 --> 07:36.840 And in fact, we verify downloads all the time is usually our package manager that's doing 07:36.840 --> 07:37.840 it. 07:37.840 --> 07:44.480 So if you're on Fedora, using RPM, if you're on Debian, using App, and DPKG, but if I download 07:44.480 --> 07:51.080 an ISO, for instance, of Fedora, or if I download cubes, then I have to manually verify. 07:51.080 --> 07:53.840 So how do I do that? 07:53.840 --> 07:59.000 So our goal is to download the latest version of cubes, and we want to verify the signature. 07:59.000 --> 08:05.240 We have a command, it's called SQ Download, it downloads the signature and the file, it 08:05.240 --> 08:12.360 verifies the signature, and it only releases the data if the signature is valid. 08:12.360 --> 08:15.880 So you can't accidentally use bad data. 08:15.880 --> 08:20.200 It forces you to make sure that the signature is valid, and we'll see what exactly it means, 08:20.200 --> 08:22.920 signature is valid. 08:22.920 --> 08:28.760 So first try, I completely naive, we go to the website, we find the URLs, so we do SQ Download, 08:28.760 --> 08:32.040 the first thing we put in is the signature, the Detack Signature. 08:32.040 --> 08:39.400 That's the.pgp.air.airc file, in this case, this.airc, then the URL of the file that we 08:39.400 --> 08:45.320 want to download, and then where we want to put it, dash-alput cubes that I assume. 08:45.320 --> 08:52.480 One thing that we try to do in SQ is that we don't guess, we avoid guessing, we don't 08:52.480 --> 08:57.720 do what I mean interfaces, because we find that do what I mean is a little bit dangerous. 08:57.720 --> 09:03.120 You don't want to accidentally overwrite a file, you don't want to put it someplace, wrong 09:03.120 --> 09:06.160 place, you have to be explicit. 09:06.160 --> 09:11.200 When we immediately get an error, we can't verify the signature, because we don't have 09:11.200 --> 09:14.160 certificates for any of the alleged signers. 09:14.160 --> 09:19.200 So here it's telling us the fingerprint of the certificate that's missing, but it gives 09:19.200 --> 09:20.200 us a hint. 09:20.200 --> 09:27.440 It says, here, go ahead, try this, try searching the public directories, SQ Not Work Search. 09:27.440 --> 09:32.040 And the reason that we don't do that automatically is because it's a privacy concern. 09:32.040 --> 09:36.560 When we go out onto the network, then we're revealing to the network that we're looking 09:36.560 --> 09:43.600 for this particular thing, and maybe our adversary cares that we're doing this, and then 09:43.600 --> 09:48.160 it's going to give us bad data, so that wouldn't be so great. 09:48.160 --> 09:54.520 So we get the certificate, SQ Not Work Search, just like I said, and so we're really happy, 09:54.520 --> 09:55.520 right? 09:55.520 --> 09:58.440 It says, cubes, OS, release key, sign key, that's what we're looking for. 09:58.440 --> 09:59.440 Awesome. 09:59.440 --> 10:00.440 Very good. 10:00.440 --> 10:05.320 That's the bottom, but we're going to ignore, and we're immediately going to try again. 10:05.320 --> 10:09.440 So we try again, and now it's telling us a different error message, it's saying it can't 10:09.440 --> 10:12.200 authenticate the alleged signer. 10:12.200 --> 10:19.480 Oh, no, we can't verify the signature, because we can't authenticate any of the signers. 10:19.480 --> 10:21.120 And then we get another hint. 10:21.120 --> 10:25.760 Verify one of the certificates is authenticate, authenticate, and then link it. 10:25.760 --> 10:29.480 And here's the command that we're supposed to use, SQ, PKI, link ad. 10:30.000 --> 10:32.080 OK, how do we authenticate a certificate? 10:32.080 --> 10:33.680 What does that mean? 10:33.680 --> 10:39.840 Well, authentication means figuring out what certificate belongs to a given entity. 10:39.840 --> 10:41.360 Is this really my certificate? 10:41.360 --> 10:43.200 Is this the cubes certificate? 10:43.200 --> 10:47.080 Just because there's some certificate out there that has cubes in the name doesn't mean 10:47.080 --> 10:48.520 that the cubes people created it. 10:48.520 --> 10:51.200 Anybody can create a certificate. 10:51.200 --> 10:52.840 So how do we find out? 10:52.840 --> 10:57.720 We could ask the cubes community member, could ask a friend who has cubes. 10:57.720 --> 11:02.000 We could go to the cubes stand here at Faustem, and we could say, hey, what's the certificate 11:02.000 --> 11:07.080 that you use, or we could even go to the website, and it's linked right there. 11:07.080 --> 11:13.880 Now using the website means that you add X509 to your trusted computing base, maybe you're 11:13.880 --> 11:17.160 willing to do that, maybe not, it depends on your threat model. 11:17.160 --> 11:21.360 All right, but let's say we authenticate it, we figure out what the right certificates 11:21.400 --> 11:22.360 for cubes. 11:22.360 --> 11:30.080 So we do this SQPK, I link add thing here, and it says Certification Created. 11:30.080 --> 11:31.360 What exactly happens? 11:31.360 --> 11:39.080 Well, if we take a look, we can use the SQSertList command, and we're saying, tell us information 11:39.080 --> 11:41.000 about this certificate. 11:41.000 --> 11:47.200 And we see the user ID, and there's a little checkmark saying that is authenticated. 11:47.200 --> 11:51.960 And if we look here, Sequoia is saying, well, why is it authenticated? 11:51.960 --> 11:58.680 Well, the local trust route said that this binding between the certificate and user 11:58.680 --> 12:01.600 ID is correct, and why did they say that? 12:01.600 --> 12:04.960 Well, we just did SQPK, I link add. 12:04.960 --> 12:06.400 So it's pretty straightforward. 12:06.400 --> 12:08.440 We didn't have to specify a certifier or anything. 12:08.440 --> 12:11.760 We just said, these things belong together. 12:11.760 --> 12:15.840 And the interesting thing is, is that this was modeled in the web of trust data. 12:15.840 --> 12:18.720 It's not some additional mechanism on top. 12:18.720 --> 12:21.600 It's a unified trust model. 12:21.600 --> 12:30.120 So we can use the web of trust calculus in order to compute whether or not a binding is authentic. 12:30.120 --> 12:34.120 Let's give it another try, SQ download just like before. 12:34.120 --> 12:40.160 We see that it downloaded the 6.9 gigabytes of data, finished downloading the data, it authenticated 12:40.160 --> 12:45.800 the data, it authenticated the signature, we're happy it's there, and now we can use cube. 12:45.800 --> 12:49.000 So what happened? 12:49.000 --> 12:55.640 We use the SQ download command, it combines the whole bunch of operations that are important, 12:55.640 --> 13:00.520 fetching the file, fetching the detached signature, and performing diversification. 13:00.520 --> 13:04.360 One thing that we have to do is that we have to authenticate the signer, which is a slight 13:04.360 --> 13:10.720 burden the first time, but depending on your threat model, it's very important that you do this. 13:10.720 --> 13:14.320 And if you're on devion, and you want to verify, for instance, a devion package, you 13:14.320 --> 13:18.320 don't have to look all around, you already have devion installed, and the keys are 13:18.320 --> 13:19.320 already there. 13:19.320 --> 13:22.320 So you can go ahead and immediately link those. 13:22.320 --> 13:25.800 And finally, the data is only released if it can be authenticated. 13:25.800 --> 13:31.320 You can't accidentally use something that is provided by the attacker. 13:31.320 --> 13:35.320 Alright, demo number two, let's sign a message. 13:35.320 --> 13:41.320 Well, first we need a certificate, and then somehow we have to make it available to the recipient. 13:41.320 --> 13:46.320 Alright, so here we have, out of love list, she wants to make a certificate. 13:46.320 --> 13:53.320 She puts in her name, dash dash name, dash dash email, out at example.org, and then there's 13:53.320 --> 13:58.320 this one more parameter over here, own key, which means that that's her own key, her personal key. 13:58.320 --> 14:02.320 She's fully trusted, she's not giving it access to anybody else. 14:02.320 --> 14:03.320 It's hers. 14:03.320 --> 14:06.320 It's like a CA. 14:06.320 --> 14:10.320 And then SQ key, generate conveniently prints out a little bit of information here about what 14:10.320 --> 14:17.320 was created, the fingerprint of the new certificate, and then it even tells you what to do next. 14:17.320 --> 14:22.320 If you want to attach it to an email, you would export it, or if you want to publish it, 14:22.320 --> 14:26.320 then you would use SQ network key server publish. 14:26.320 --> 14:33.320 So SQ is there for you, it's your friend, it's your guide, and now we sign the message. 14:34.320 --> 14:42.320 So we want to do echo hello, SQ sign, and then we get the PGP message out, and we can verify it. 14:42.320 --> 14:47.320 And when we do verify, it tells us not only that the message has been verified, but why, 14:47.320 --> 14:53.320 and it again it shows this path here, local trust route to this certificate. 14:53.320 --> 15:00.320 And that was because SQ key generated, created the appropriate links based on the local trust route. 15:01.320 --> 15:04.320 And we can make a detached signature. 15:04.320 --> 15:09.320 So we're going to do a release of some software, then we would sign it. 15:09.320 --> 15:17.320 Again, we use SQ sign, and then we can verify it, and we see again the path. 15:17.320 --> 15:18.320 So it's clear. 15:18.320 --> 15:20.320 All right, let's sign a certificate. 15:20.320 --> 15:25.320 We go to foster them, there's a key signing party, everybody goes, Alice meets Bob, actually it's odd 15:25.320 --> 15:30.320 and meets Bob, and she vouches that Bob has a certain certificate. 15:30.320 --> 15:38.320 And our terminology, vouch, is a public assertion, and link is a local assertion that's never exported from your computer. 15:38.320 --> 15:42.320 So this whole local trust route stuff, even though it's saved as web of trust data, 15:42.320 --> 15:46.320 it's not revealed to the network because it's only locally stored. 15:47.320 --> 15:51.320 So we search for Bob's fingerprint. 15:51.320 --> 15:54.320 We got him the business card, or whatever. 15:54.320 --> 15:56.320 And then we do SQ PKI vouch add. 15:56.320 --> 16:01.320 Here we have eight as a certificate, and then we have Bob's certificate, 16:01.320 --> 16:04.320 and then we create the certifications. 16:04.320 --> 16:10.320 And it's a little bit inconvenient here to specify the fingerprint all the time. 16:10.320 --> 16:13.320 So you can go ahead and put in your configuration file, 16:13.320 --> 16:18.320 and the state of saying certifier fingerprint, you would say certifier self. 16:18.320 --> 16:21.320 And let's look at Bob's certificate now. 16:21.320 --> 16:23.320 What do we see? 16:23.320 --> 16:27.320 Well, if we list Bob's certificate, we see at the top again the local trust route, 16:27.320 --> 16:31.320 because all of the trust starts at the trust route, it's a route. 16:31.320 --> 16:36.320 And the trust route said that oddas certificate is good, 16:36.320 --> 16:38.320 and that she's a trusted introducer. 16:38.320 --> 16:41.320 It's her own computer, it's her own certificate. 16:41.320 --> 16:45.320 And then oddas went ahead and made a vouch about Bob's certificate, 16:45.320 --> 16:48.320 and user ID, and boom, we see the path. 16:48.320 --> 16:51.320 So it's very clear what's going on, there's some transparency. 16:51.320 --> 16:55.320 And that's important for users to understand how the system works. 16:55.320 --> 16:57.320 All right, let's do some key management, right? 16:57.320 --> 17:00.320 I use a key, I created it after three years, it expires. 17:00.320 --> 17:01.320 What do I do? 17:01.320 --> 17:02.320 Actually, it's really easy. 17:02.320 --> 17:08.320 All you do is SQ PKI expire to change the expiration time. 17:08.320 --> 17:12.320 And then we're going to expire it in three years from now, and we're done. 17:12.320 --> 17:14.320 Well, that was easy. 17:14.320 --> 17:19.320 Let's imagine that your certificate is using SHA1. 17:19.320 --> 17:21.320 Everybody knows SHA1 is broken, right? 17:21.320 --> 17:23.320 That's why we don't use SHA1 anymore. 17:23.320 --> 17:24.320 Right? 17:24.320 --> 17:25.320 Red Hat? 17:25.320 --> 17:27.320 Okay. 17:27.320 --> 17:29.320 This is your homework assignment. 17:29.320 --> 17:31.320 You're going to go home, okay? 17:31.320 --> 17:34.320 And the red Hat people here. 17:34.320 --> 17:37.320 And you're going to generate some new certificates. 17:38.320 --> 17:41.320 You have to make sure that they have the same user IDs. 17:41.320 --> 17:43.320 You want them to have the same structure, right? 17:43.320 --> 17:47.320 Because if it's a signing key, then it doesn't need encryption capable sub keys. 17:47.320 --> 17:50.320 You need to create links between the two certificates. 17:50.320 --> 17:53.320 You want to cross sign them. 17:53.320 --> 17:56.320 If you made any certifications with the old certificate, 17:56.320 --> 17:59.320 you want the new one to also make the same certifications. 17:59.320 --> 18:01.320 And don't forget to retire the old certificate. 18:01.320 --> 18:03.320 That's a lot of work, right? 18:03.320 --> 18:04.320 All right. 18:04.320 --> 18:08.320 SQK rotate, you're done. 18:08.320 --> 18:11.320 It cross signs the old and the new certificates. 18:11.320 --> 18:14.320 It replays the certifications and the links. 18:14.320 --> 18:17.320 It retires the old certificate. 18:17.320 --> 18:19.320 Super easy. 18:19.320 --> 18:22.320 Let's create a certification authority. 18:22.320 --> 18:25.320 Well, I don't want to create a certification authority, 18:25.320 --> 18:29.320 because doing this whole authentication thing is a little bit annoying sometimes. 18:29.320 --> 18:34.320 So you might be a business, an organization, a family, 18:34.320 --> 18:38.320 and there is always somebody who is or an activist collective. 18:38.320 --> 18:42.320 And you got somebody who is technically savvy and other people who aren't. 18:42.320 --> 18:45.320 So you create a CA and you let them use it. 18:45.320 --> 18:49.320 The admin vouchers for the different members of the organization. 18:49.320 --> 18:51.320 You publish it. 18:51.320 --> 18:53.320 The certificates and the vouchers, in for instance, 18:53.320 --> 18:56.320 a WKD, and you have to keep them up to date, right? 18:56.320 --> 18:58.320 The first step is really easy. 18:58.320 --> 19:00.320 Everybody's willing to do that. 19:00.320 --> 19:02.320 It's been half a day, setting everything off. 19:02.320 --> 19:03.320 It's perfect. 19:03.320 --> 19:05.320 And then a year later you have to change something. 19:05.320 --> 19:06.320 And you have no idea anymore. 19:06.320 --> 19:08.320 You got to keep it up to date. 19:08.320 --> 19:09.320 All right. 19:09.320 --> 19:11.320 So first we generate a CA key. 19:11.320 --> 19:13.320 And here it's the same. 19:13.320 --> 19:15.320 It's very similar to what we did before. 19:15.320 --> 19:16.320 But we say we cannot sign. 19:16.320 --> 19:18.320 We cannot authenticate and we cannot encrypt. 19:18.320 --> 19:21.320 It's only for certification. 19:21.320 --> 19:25.320 Because your CA key doesn't need to do those other things. 19:25.320 --> 19:28.320 Then we add a vouch for auto. 19:28.320 --> 19:30.320 And now we have to set up our WKD. 19:30.320 --> 19:31.320 How do we do that? 19:31.320 --> 19:34.320 SQ network WKD publish. 19:34.320 --> 19:37.320 We specify the trust routes or our CA. 19:37.320 --> 19:39.320 The domain is example.org. 19:39.320 --> 19:43.320 And then we're going to ours sink it over to the web server. 19:43.320 --> 19:48.320 And we see it's going to do auto and the CA. 19:48.320 --> 19:50.320 And it's published on the web server and bam. 19:50.320 --> 19:51.320 We're done. 19:51.320 --> 19:52.320 Beautiful. 19:52.320 --> 19:53.320 That work. 19:53.320 --> 20:00.320 It only did the certificates that are authenticated for example.org. 20:00.320 --> 20:06.320 So even if you have a whole bunch of junk in your certificate store. 20:06.320 --> 20:10.320 If you haven't created vouchers for them or you haven't linked those certificates, 20:10.320 --> 20:11.320 they don't get published. 20:11.320 --> 20:14.320 It's completely safe to have lots of junk. 20:14.320 --> 20:18.320 SQ only works with things that are authenticated. 20:18.320 --> 20:19.320 All right. 20:19.320 --> 20:23.320 So you do this one time and then you put it in a crong shop and you're done. 20:23.320 --> 20:24.320 All right. 20:24.320 --> 20:25.320 So let's use the CA. 20:25.320 --> 20:26.320 How do we do it? 20:26.320 --> 20:30.320 We want to send an email and encrypted message to auto. 20:30.320 --> 20:34.320 We can't do it because we couldn't authenticate this certificate. 20:34.320 --> 20:35.320 All right. 20:35.320 --> 20:38.320 So instead of linking auto certificate, 20:38.320 --> 20:41.320 we link the CA's certificate here. 20:41.320 --> 20:44.320 We authorize instead of do add. 20:44.320 --> 20:46.320 And now it's the CA. 20:46.320 --> 20:48.320 And by the way, we have a scope here. 20:48.320 --> 20:49.320 Only for example.org. 20:49.320 --> 20:51.320 The CA can't be used for anything. 20:51.320 --> 20:54.320 It's not like X509 where once you trust the CA, it's like, 20:54.320 --> 20:55.320 Oh, anything. 20:55.320 --> 20:56.320 No. 20:56.320 --> 20:58.320 Very, very scope. 20:58.320 --> 20:59.320 Very tight scope. 20:59.320 --> 21:01.320 And then we do SQ and grips. 21:01.320 --> 21:02.320 Works beautiful. 21:02.320 --> 21:03.320 Everybody's happy. 21:03.320 --> 21:04.320 Easy to use. 21:04.320 --> 21:06.320 What happened here? 21:06.320 --> 21:08.320 We list autos. 21:08.320 --> 21:10.320 Certificate. 21:10.320 --> 21:12.320 Local trust route. 21:12.320 --> 21:13.320 CA. 21:13.320 --> 21:14.320 Auto. 21:14.320 --> 21:15.320 Again, that nice path. 21:15.320 --> 21:17.320 All right. 21:17.320 --> 21:18.320 Summary. 21:18.320 --> 21:20.320 SQ supports high level workloads. 21:20.320 --> 21:24.320 It guides the user with lots of hints. 21:24.320 --> 21:26.320 SQ has some new concepts. 21:26.320 --> 21:27.320 We have this local trust route. 21:27.320 --> 21:28.320 We have links. 21:28.320 --> 21:30.320 And we have mandatory authentication. 21:30.320 --> 21:32.320 There's no curated curing. 21:32.320 --> 21:34.320 And I'd be very happy if you take a look. 21:34.320 --> 21:37.320 And if you want to learn more, we have a user manual, 21:37.320 --> 21:39.320 which is really, really nice introduction. 21:39.320 --> 21:41.320 Book.sacoyatshp.org. 21:41.320 --> 21:43.320 We have man pages. 21:43.320 --> 21:55.320 And in the last one or two minutes, I'd be happy to take a couple of questions. 21:55.320 --> 21:57.320 We have three minutes for questions. 21:57.320 --> 21:59.320 There's a question on matrix. 21:59.320 --> 22:01.320 For by Thomas Mann, he's asking, I was using this. 22:01.320 --> 22:08.320 But notice that UB key support doesn't seem to be available any plans for hardware key support specific. 22:08.320 --> 22:09.320 Right. 22:09.320 --> 22:11.320 So hardware key support in SQ. 22:11.320 --> 22:14.320 The answer is that SQ actually supports multiple backends. 22:14.320 --> 22:18.320 So it has its own local key store backends. 22:18.320 --> 22:20.320 So soft keys that are stored in the file system. 22:20.320 --> 22:23.320 It automatically uses GPG agent. 22:23.320 --> 22:27.320 So if you've already configured GPG agent and you run SQ the first time, 22:27.320 --> 22:30.320 you will see your GPG keys just magically appear. 22:30.320 --> 22:35.320 Because SQ talks to GPG agents by default. 22:35.320 --> 22:38.320 It also has support for using PCSD. 22:38.320 --> 22:44.320 So if you use PCSD, then you can also use your UB key. 22:44.320 --> 22:47.320 It's a little bit problematic if you have GPG agent installed. 22:47.320 --> 22:53.320 Because by default, GPG agent will lock the OpenPGP app on your UB key. 22:53.320 --> 22:58.320 So it's kind of one or the other, which is a little bit tricky. 22:58.320 --> 23:03.320 Or you have to go into the advanced configuration for GPG agent and put into shared mode. 23:03.320 --> 23:06.320 But that's kind of dangerous because as I understand it, 23:06.320 --> 23:10.320 the locking is not guaranteed to be correct. 23:21.320 --> 23:23.320 Can you repeat the question? 23:23.320 --> 23:27.320 Can you repeat the question? 23:27.320 --> 23:30.320 OCI Container Signing is the question? 23:30.320 --> 23:31.320 Yeah. 23:31.320 --> 23:35.320 So as a whole bunch of people that are actually using Sequoia, 23:35.320 --> 23:37.320 including, for instance, Red Hat. 23:37.320 --> 23:39.320 The Red Hat people are sitting in front of me. 23:39.320 --> 23:41.320 So I'm picking on you. 23:41.320 --> 23:45.320 But there's also a little bit of work to integrate it into the OCI stuff. 23:45.320 --> 23:47.320 Dike did something there. 23:47.320 --> 23:53.320 So I don't know the exact details because that's not my priority. 23:53.320 --> 23:54.320 Yep. 23:54.320 --> 23:59.320 So I want to manage the PCHP keys of the company I'm working for. 23:59.320 --> 24:03.320 And I follow this CA creation. 24:03.320 --> 24:08.320 Can only I do it or am I the, so am I the only failing point? 24:08.320 --> 24:14.320 Or can I somehow put this in a Git repository and share it so that everyone who is 24:14.320 --> 24:20.320 competent enough to access the skit can at keys or deprecate keys? 24:20.320 --> 24:24.320 So the question was, if I'm at a company and I want to do a CA, 24:24.320 --> 24:25.320 how would I do it? 24:25.320 --> 24:27.320 Should I put it in a Git repository? 24:27.320 --> 24:31.320 And I would not put the secret key material into the Git repository. 24:31.320 --> 24:34.320 The keys that are needed for the Web Key directory. 24:34.320 --> 24:35.320 Right. 24:35.320 --> 24:37.320 So only the, the public keys. 24:37.320 --> 24:42.320 So yeah, you could put them into a, a Git. 24:42.320 --> 24:48.320 The, the way that the, the synchronization works is that it's not a one way synchronization. 24:48.320 --> 24:49.320 It's a two way synchronization. 24:49.320 --> 24:53.320 So SQ first downloads the whole Web Key directory. 24:53.320 --> 24:55.320 It adds any updates they have locally. 24:55.320 --> 24:57.320 And then it sinks it back to the server. 24:57.320 --> 25:02.320 So you can view the Web Key directory as being like half authoritative. 25:02.320 --> 25:12.320 And the actual authoritative part are the certifications that you make using the CA key. 25:12.320 --> 25:14.320 It's times up as I understand it. 25:14.320 --> 25:16.320 It's a little bit confusing. 25:16.320 --> 25:17.320 I agree. 25:17.320 --> 25:23.320 It's not that hard, but we should probably work it out and not right here. 25:23.320 --> 25:26.320 Thank you very much for your work. 25:26.320 --> 25:27.320 Thank you. 25:27.320 --> 25:28.320 Thank you. 25:28.320 --> 25:29.320 Thank you. 25:29.320 --> 25:32.320 Thank you.