WEBVTT 00:00.000 --> 00:08.000 Okay, let's get started. 00:08.000 --> 00:13.000 The final keynote of this year's false dim. 00:13.000 --> 00:16.000 As some of the older ones among you might know, 00:16.000 --> 00:20.000 you used to have to pay quite a lot of money for web server 00:20.000 --> 00:23.000 to tell us certificates. 00:23.000 --> 00:26.000 And as some of you might have heard of this famous saying, 00:26.000 --> 00:29.000 I think Einstein said that everybody knows that 00:29.000 --> 00:32.000 as it's too come to do something until somebody comes 00:32.000 --> 00:34.000 who didn't know that, and then they do that. 00:34.000 --> 00:38.000 And then these guys, I SRG represented by Josh Us here. 00:38.000 --> 00:41.000 Well, they came, they created, let's encrypt, 00:41.000 --> 00:45.000 which now serves massive amounts of web serverty. 00:45.000 --> 00:46.000 Certificates. 00:46.000 --> 00:49.000 Four free in an automated fashion. 00:49.000 --> 00:52.000 And Josh will now walk us a bit through this 10-year-long history 00:52.000 --> 00:54.000 of Latincript. 00:54.000 --> 01:01.000 Thank you. 01:01.000 --> 01:04.000 I'm Josh, I'm the executive director, 01:04.000 --> 01:06.000 and one of the co-founders of Latincript. 01:06.000 --> 01:09.000 I've been working on this for a very long time now. 01:09.000 --> 01:12.000 After he's done, Michael, I'm very close to him. 01:12.000 --> 01:15.000 All right, I'm going to keep it close. 01:15.000 --> 01:19.000 Before we get started, I want to take temperature. 01:19.000 --> 01:23.000 How many people have heard of Latincript? 01:23.000 --> 01:24.000 Great. 01:24.000 --> 01:27.000 How many people have gotten a certificate from Latincript? 01:27.000 --> 01:29.000 Wow. 01:29.000 --> 01:30.000 Great. 01:30.000 --> 01:32.000 Good to know. 01:32.000 --> 01:36.000 All right, this is a quick overview of what we'll talk about today. 01:36.000 --> 01:39.000 We'll do a little for the people who don't know how to get to work. 01:39.000 --> 01:41.000 We'll get through that very quickly. 01:41.000 --> 01:43.000 Then we'll do some history infrastructure. 01:43.000 --> 01:45.000 Then what's coming in the future? 01:45.000 --> 01:49.000 And some of the things we feel like we've learned over the past 10 years. 01:49.000 --> 01:53.000 So this is a three-slide, very quick overview of the web API. 01:53.000 --> 01:58.000 Ideally, when you connect to a website, you use a protocol called TLS. 01:58.000 --> 02:01.000 TLS plus HTTP gives you a GPS. 02:01.000 --> 02:03.000 And TLS gives you two different things. 02:03.000 --> 02:07.000 It gives you encryption, which is scrambling the bits on the wire. 02:07.000 --> 02:13.000 It also gives you authentication, so that you are talking to the entity you think you're talking to. 02:13.000 --> 02:18.000 It doesn't do you a lot of good to have encryption if you have no idea who you're talking to. 02:18.000 --> 02:20.000 You're on the other side of the encrypted line. 02:20.000 --> 02:25.000 You really need both of these things to be secure. 02:25.000 --> 02:30.000 And digital TLS certificates are the mechanism for authentication in TLS. 02:30.000 --> 02:35.000 It's how you know that you're talking to the website that you think that you're talking to. 02:35.000 --> 02:41.000 And a certificate is a digital file that basically contains the four things at the bottom. 02:41.000 --> 02:44.000 It contains the domains that it applies to. 02:44.000 --> 02:47.000 It contains the cryptographic public key for those domains. 02:47.000 --> 02:50.000 Some other stuff that we don't need to talk about. 02:50.000 --> 02:53.000 And then a signature from a CA over that content. 02:53.000 --> 03:00.000 So it's a CA signing and saying, these public, this public key belongs to these domains. 03:00.000 --> 03:04.000 And you get these certificates from certificate authorities like let's encrypt. 03:04.000 --> 03:07.000 But there are dozens to a hundred more out there. 03:07.000 --> 03:09.000 There are many options. 03:09.000 --> 03:14.000 And this whole ecosystem is called the web public key infrastructure or web PKI. 03:14.000 --> 03:18.000 We have to make it complicated with the wording. 03:18.000 --> 03:23.000 So that probably enough details to get you through this talk. 03:23.000 --> 03:30.000 So before 2015, the web PKI was mostly made up of complex manual processes. 03:30.000 --> 03:36.000 Even if you had the money to get a cert, it was a frustrating process for a lot of people. 03:36.000 --> 03:38.000 It was also expensive. 03:38.000 --> 03:46.000 And there were a lot of people out there who weren't really convinced of the necessity of getting certificates and enabling the HGPS. 03:46.000 --> 03:51.000 And the result of all this is that about 39% of page loads use HGPS. 03:51.000 --> 03:53.000 Now that's page loads. 03:53.000 --> 04:00.000 But those page loads of 39% were really concentrated on a small number of very popular websites. 04:00.000 --> 04:05.000 So the percentage of websites, we don't know what that is or how we would have calculated that at the time. 04:05.000 --> 04:07.000 But it's a lot lower than 39%. 04:07.000 --> 04:14.000 So not a lot going on in HPS in 2015. 04:14.000 --> 04:16.000 So what's the problem then, right? 04:16.000 --> 04:21.000 Everybody knows that if you don't use TLS, your data is visible. 04:21.000 --> 04:23.000 That's obviously bad for some things. 04:23.000 --> 04:26.000 But you can imagine a website where the data is not sensitive at all, right? 04:26.000 --> 04:30.000 It could just be a joke with an image and you don't care people see that on the internet. 04:30.000 --> 04:35.000 So it's not obvious to people that encryption should be used everywhere. 04:35.000 --> 04:40.000 But the thing that I like to remind people is that traffic that is not encrypted is modifiable. 04:40.000 --> 04:47.000 So even if you're visiting a website where the content is not important in terms of privacy, 04:47.000 --> 04:55.000 you have no idea if the data that you are getting back and loading your web browser is what actually was sent by the server. 04:55.000 --> 04:59.000 So you could be fed on anything from fishing, advertising, whatever else it is. 04:59.000 --> 05:07.000 So the modifiability to me is really the biggest issue with not using encryption. 05:07.000 --> 05:12.000 And before I started a lesson script, I worked on a web browser. 05:12.000 --> 05:16.000 And part of what I supposed to do there is make the networking more secure. 05:16.000 --> 05:27.000 And if the content you're loading is not secure, you don't know for sure where the data come from or if it's even the right data or anything. 05:27.000 --> 05:38.000 Working the other parts of the network stacks, you know, it's not totally pointless, but it definitely feels like it, you know, it's putting bars on a house with no door. 05:38.000 --> 05:46.000 So that really got me thinking a lot about what do we need to do it, like we have to solve this problem. 05:46.000 --> 05:50.000 So we wanted a solution that would get the web close to 100% HGBOS. 05:50.000 --> 05:54.000 And we were thinking, we want to get it done in five years or less. 05:54.000 --> 06:00.000 That five years seemed like, you know, the fastest amount of time within the realm of possibility. 06:00.000 --> 06:05.000 We didn't have a way to do this in one year for sure, but five years maybe. 06:05.000 --> 06:08.000 And ultimately, it comes down to the fact that there are a lot of web servers out there. 06:08.000 --> 06:11.000 And you're going to have to convince all of them to take some action. 06:11.000 --> 06:15.000 And that's going to take a lot of time, no matter what that action is. 06:15.000 --> 06:21.000 We did not want the IPv6 and DNS sec adoption timelines that was not acceptable. 06:21.000 --> 06:25.000 And sort of get seemed to read the roadblock that seemed to be the issue. 06:25.000 --> 06:30.000 It's not that hard to just flip the switch and engineer or Apache and turn on TLS, but you need to sort. 06:30.000 --> 06:33.000 And that's what people are missing. 06:33.000 --> 06:37.000 So we thought a lot about what what are we going to do here. 06:37.000 --> 06:43.000 And the only feasible solution that we could come up with was to start a new CA. 06:43.000 --> 06:45.000 And that's a lot of work. 06:45.000 --> 06:47.000 So in that sense, it wasn't an ideal solution. 06:47.000 --> 06:53.000 It would be nice if we could get a thought of something clever that got us to our goal in a faster and cheaper way. 06:53.000 --> 06:57.000 But this is what we felt like we had to do. 06:57.000 --> 07:01.000 So in 2013, we started planning. 07:01.000 --> 07:08.000 In 2014, we incorporated a nonprofit, integrated security research group to be the sort of home of lots and 07:08.000 --> 07:09.000 developed. 07:09.000 --> 07:12.000 We got a bunch of great initial sponsors. 07:12.000 --> 07:17.000 And you know, these sponsors were really important to us. 07:17.000 --> 07:23.000 Like these people saw the vision and believed in what we were doing way before it became a reality. 07:23.000 --> 07:26.000 And I give them a lot of credit for that. 07:26.000 --> 07:31.000 So we spent a very frantic year starting to build a CA. 07:31.000 --> 07:34.000 And I did not know how to build a CA when we started doing this. 07:34.000 --> 07:38.000 I had to spend a lot of time on the phone of people who knew what they were doing. 07:38.000 --> 07:40.000 It was a bit overwhelming at times. 07:40.000 --> 07:41.000 We got there. 07:41.000 --> 07:46.000 And we announced lots of encrypt when we were far enough along that we thought, yeah, this is really going to happen. 07:46.000 --> 07:53.000 And then in 2015, we issued our first certificate. 07:53.000 --> 07:56.000 So fast for over today, we've had a lot of growth. 07:56.000 --> 07:59.000 We're serving about 500 million websites. 07:59.000 --> 08:02.000 And because each certificate can have multiple websites on it, 08:02.000 --> 08:04.000 there's a slightly lower number of certificates. 08:04.000 --> 08:06.000 That's the bar in the middle. 08:06.000 --> 08:10.000 And then the green one at the bottom is registered domains. 08:10.000 --> 08:15.000 So that would be the TLD plus one. 08:15.000 --> 08:19.000 Whereas sort of an active is like including all sub domains. 08:19.000 --> 08:21.000 So there's been a lot of growth. 08:21.000 --> 08:23.000 We've come a long way since 2015. 08:23.000 --> 08:27.000 And the web is much more encrypted than it used to be. 08:27.000 --> 08:30.000 So this is what our infrastructure looks like today. 08:30.000 --> 08:35.000 And we'll start with the organizational infrastructure. 08:35.000 --> 08:39.000 So ISRG has about 25 staff total. 08:39.000 --> 08:42.000 And that includes engineers, fundraising, 08:42.000 --> 08:44.000 comms, finance, management. 08:44.000 --> 08:48.000 We have three profits, lots of encrypted, which is by far our most well-known one. 08:48.000 --> 08:52.000 We have another one around data privacy, 08:52.000 --> 08:54.000 metrics, privacy called Divyup. 08:54.000 --> 08:59.000 And we have a third one that deals with memory safety for critical infrastructure. 08:59.000 --> 09:01.000 called ProsMO. 09:01.000 --> 09:05.000 And the total budget for our org is about $6.7 million for a year. 09:05.000 --> 09:12.000 And we get a lot of our funding from corporate sponsors, individuals, and some grants. 09:12.000 --> 09:16.000 Now I'm going to focus just on the Let's Encrypt CA infrastructure. 09:16.000 --> 09:19.000 So it's operated by 12 engineers. 09:19.000 --> 09:22.000 It's a lot or a little depending on you look at it. 09:22.000 --> 09:25.000 I tend to think it's not that many engineers. 09:25.000 --> 09:28.000 I think we've done a pretty good job of trying to keep our costs low here. 09:28.000 --> 09:32.000 But three or four of those 12 in a given time are running CA software. 09:32.000 --> 09:34.000 And the rest are operating infrastructure. 09:34.000 --> 09:37.000 They're essentially SREs. 09:37.000 --> 09:43.000 And they're of course supported by the rest of the staff and the organization. 09:43.000 --> 09:49.000 For a physical infrastructure, we have about three full racks of hardware across two different locations. 09:49.000 --> 09:53.000 That's HSM's hardware security modules. 09:53.000 --> 09:57.000 Compute servers, database, networking and stuff like that. 09:57.000 --> 10:00.000 Physical security is a bit more intense than a normal data center. 10:00.000 --> 10:03.000 We're in data centers that we share with other people. 10:03.000 --> 10:08.000 But we have more secure situations than our normal. 10:08.000 --> 10:11.000 Extra layers. 10:11.000 --> 10:14.000 We do use the cloud, but only for some ancillary systems. 10:14.000 --> 10:20.000 All of our core issuance and stuff comes off of our own on-prem servers. 10:20.000 --> 10:24.000 That's required by the rules for being a CA. 10:24.000 --> 10:27.000 You can't use the cloud to issue certificates. 10:27.000 --> 10:30.000 But even if it wasn't the rule, I think we would still do it. 10:30.000 --> 10:35.000 It's pretty cost efficient and it's worked out well for us. 10:35.000 --> 10:38.000 We use a CDN. 10:38.000 --> 10:44.000 And some of the spaces that we have, the physical spaces, also accommodate key ceremonies, 10:44.000 --> 10:49.000 which is where we need to generate the route and intermediate keys for the state of authority. 10:49.000 --> 10:59.000 We take a lot of care about visibility, EM radiation, things like that when we're generating keys. 10:59.000 --> 11:01.000 This is our software stack. 11:01.000 --> 11:04.000 Most of it is pretty common stuff. 11:04.000 --> 11:07.000 At the bottom there, we write our own CA software. 11:07.000 --> 11:08.000 It's called Boulder. 11:08.000 --> 11:14.000 It's open source. 11:14.000 --> 11:20.000 We've also been trying to move some of what we do to more memory-said code. 11:20.000 --> 11:22.000 Our CA software is written in Go. 11:22.000 --> 11:23.000 It's memory-said. 11:23.000 --> 11:27.000 But a lot of the pieces of our infrastructure are not memory-said. 11:27.000 --> 11:29.000 And we'd like to get there. 11:29.000 --> 11:32.000 So we're focused on some of the most important components. 11:32.000 --> 11:33.000 We started with NTP. 11:33.000 --> 11:40.000 That's like an easy, a relatively easy place to get going in and introduce a new program into the system. 11:40.000 --> 11:43.000 We have it working great. 11:43.000 --> 11:48.000 The trifecta tech foundation is doing a great job maintaining that software that we built with them. 11:48.000 --> 11:49.000 It's working great. 11:49.000 --> 11:50.000 A lot of some crypts. 11:50.000 --> 11:57.000 Later this year, we're going to replace our C-based DNS resolver with a memory-said DNS resolver called Hickory DNS. 11:57.000 --> 12:02.000 We're going to swap out open-s to cell and friends for a Russells as well. 12:02.000 --> 12:08.000 And then we're in the beginning stages of figuring out a better solution for a reverse proxy. 12:08.000 --> 12:12.000 So I'm glad that we have a memory-said strategy for the org. 12:12.000 --> 12:14.000 It's going to take years to execute on. 12:14.000 --> 12:19.000 But a few years from now, most of our critical commands will be memory-said. 12:19.000 --> 12:25.000 So the output of all this infrastructure that I just talked about is that we issue about six million certificates per day. 12:25.000 --> 12:31.000 That covers about 500 million websites over the lifetime in the days. 12:31.000 --> 12:34.000 We handle just some other numbers for OCSP. 12:34.000 --> 12:36.000 It's a protocol for checking on revocation. 12:36.000 --> 12:39.000 We do 15,000 requests per second at the origin. 12:39.000 --> 12:42.000 139,000 requests per second at the edge. 12:42.000 --> 12:47.000 It's like 80 something billion requests per week. 12:47.000 --> 12:51.000 And we also run certificate transparency logs for a lot of encrypt. 12:51.000 --> 12:54.000 But we also accept sorts from other CAs. 12:54.000 --> 13:01.000 And the cost of lots encrypt, you know, separated from the larger organization of budget is about $4.5 million a year. 13:01.000 --> 13:06.000 So I'll talk about what's coming. 13:06.000 --> 13:09.000 Some of the changes we're making. 13:09.000 --> 13:13.000 Since we started to be issued certificates with a lifetime of 90 days. 13:13.000 --> 13:16.000 At the time, a lot of people thought that was short. 13:16.000 --> 13:21.000 Now it's, I don't know, something close to standard, right? 13:21.000 --> 13:24.000 People have, the rest of the industry has moved more towards 90 days. 13:24.000 --> 13:29.000 But we're about to introduce the option to get six days certificates. 13:30.000 --> 13:31.000 There are a lot shorter. 13:31.000 --> 13:34.000 If you're automated though, this shouldn't really be an issue. 13:34.000 --> 13:37.000 You renew your certificate every two or three days. 13:37.000 --> 13:40.000 And then if something goes wrong, get a few days to fix it. 13:40.000 --> 13:43.000 We're doing this because shorter lifetimes are better for security. 13:43.000 --> 13:45.000 He compromises pretty common. 13:45.000 --> 13:51.000 It's not always just, you know, malicious actors hacking into your stuff. 13:51.000 --> 13:57.000 Sometimes you just mess up with get and upload your private keys to get have and now you have a problem. 13:58.000 --> 14:05.000 So shorter lifetimes mean that, you know, if you do have a key compromise issue, you recover a lot faster. 14:05.000 --> 14:10.000 No, people aren't going to be able to use your cert for as long. 14:10.000 --> 14:13.000 We're also going to add IP address support. 14:13.000 --> 14:17.000 So right now, you can get certificates for domains only. 14:17.000 --> 14:23.000 But once we do this, you will be able to use TLS against an IP address. 14:23.000 --> 14:26.000 You won't need to domain name at all. 14:26.000 --> 14:29.000 This will only be available in the six day sorts. 14:29.000 --> 14:36.000 We don't want to enable this for 90 days sorts because IP addresses tend to be a bit more transient than domains are. 14:36.000 --> 14:40.000 So that's another reason we want to get some shorter lifetimes out there. 14:40.000 --> 14:44.000 I don't, honestly, I don't not totally sure what the demand is. 14:44.000 --> 14:53.000 We know there's going to be some demand for this, but I'm very curious to see how many people actually use this. 14:53.000 --> 14:59.000 Another change we're going to make is we're going to end OCSP or support. 14:59.000 --> 15:01.000 I think it's not a very well-loved protocol. 15:01.000 --> 15:04.000 I don't imagine too many people are going to cry for this. 15:04.000 --> 15:09.000 We're excited to not serve 84 billion responses a week. 15:09.000 --> 15:12.000 It's going to save us time and money. 15:12.000 --> 15:21.000 They also take up a lot of our HSM capacity when you think about the cryptographic signatures that CAs need to do. 15:21.000 --> 15:32.000 OCSP dominates for us signing OCSP objects as opposed to the actual certificates or maybe 20% of our HSM capacity. 15:32.000 --> 15:36.000 OCSP is also a pretty problematic for privacy. 15:36.000 --> 15:45.000 If you're using an OCSP enabled piece of software, every time you visit a website, it asks us whether the certificate is revoked from your IP address. 15:45.000 --> 15:50.000 It means in theory, we could know the IP address of visitors to websites. 15:50.000 --> 16:00.000 In reality, we throw that stuff out, but we don't want to know, we don't want that surface area there. 16:00.000 --> 16:08.000 So we're going to turn it off and people who want revocation information can get it from certificate revocation lists or CRLs. 16:08.000 --> 16:17.000 Instead, we're going to continue pushing hard on something we introduced a couple of years ago called Act Me Renewal Info. 16:17.000 --> 16:21.000 And this is an API for knowing when you need to renew your search. 16:21.000 --> 16:26.000 So the way most clients work now is they calculate a percentage of the search lifetime. 16:26.000 --> 16:33.000 So if you have a 90 days search, they'll say two thirds of the way through or 60 days go get a new search. 16:33.000 --> 16:37.000 That doesn't work that well when we have to for some reason revoke your search. 16:37.000 --> 16:42.000 If you have key compromise with those compliance incidents or something, we need to revoke your search. 16:42.000 --> 16:46.000 We feel bad about that because we can take your service down, we revoke the search. 16:46.000 --> 16:51.000 With this, we can notify you before we're going to revoke the search for whatever the reason is. 16:51.000 --> 16:56.000 And your client can get a new search before that gets pulled up from under you. 16:57.000 --> 17:02.000 So it's a very important part of resilience for the future of the WebPKI. 17:02.000 --> 17:09.000 If you, you should check if you're using lots and crypt as your client support ARI. 17:09.000 --> 17:16.000 It could be a stability issue for you in the future and it's good to try to find when that does support it. 17:17.000 --> 17:28.000 So I'm going to talk about some of the principles that I think have helped us be successful over the past 10 years or make it to 10 years. 17:28.000 --> 17:33.000 A big one for us is simplicity. 17:33.000 --> 17:37.000 All the WebPKI requirements, we can run it on a single machine. 17:37.000 --> 17:45.000 It does have replicas so we can fail over, but we have not needed to shard or cluster anything like that yet. 17:45.000 --> 17:49.000 That might change, like in the next couple of years we're probably going to have to change that. 17:49.000 --> 17:53.000 We've grown to the point where a single machine we're not going to be able to do it anymore. 17:53.000 --> 17:58.000 Even though the machine we're working we're talking about is very large, like we make it into that a bit later. 17:58.000 --> 18:03.000 But it's a big expensive piece of hardware, but it can't handle the whole database by itself. 18:03.000 --> 18:05.000 That has been great for us over the past 10 years. 18:05.000 --> 18:14.000 As expensive as that hardware is, the staff time to manage more complex and clustered database situation would have been much more. 18:14.000 --> 18:22.000 So we kept it really easy by just buying nicer hardware and having a single database machine. 18:28.000 --> 18:31.000 It's a finalized example here is our website. 18:31.000 --> 18:33.000 Our website is really simple. 18:33.000 --> 18:36.000 It's just a static site built with Hugo. 18:36.000 --> 18:43.000 We don't have security vulnerabilities, we don't worry about, you know, it's saved us a lot of time to do that. 18:43.000 --> 18:51.000 So the next principle here is very related to simplicity. 18:51.000 --> 18:56.000 We want to be efficient and we want to be efficient because it has our financial reality. 18:56.000 --> 18:59.000 We don't have a ton of money to throw around. 18:59.000 --> 19:02.000 It is not that easy to get more money. 19:02.000 --> 19:05.000 So it's also the right thing to do. 19:05.000 --> 19:10.000 We should do the most good that we can with the public benefit dollars that are entrusted to us. 19:10.000 --> 19:12.000 And we think about that a lot. 19:12.000 --> 19:17.000 So we don't want to be wasteful. 19:17.000 --> 19:19.000 We think a lot about scaling. 19:19.000 --> 19:25.000 You know, earlier we looked at a graph that goes up and up and up and up at the moment is looking, you know, somewhat exponential. 19:25.000 --> 19:27.000 We cannot do that with our staff. 19:27.000 --> 19:29.000 Our staff cannot grow at that rate. 19:29.000 --> 19:38.000 So every year we need to get quite a bit more efficient so that we can have no to minimal new engineers while keeping up with more and more traffic. 19:38.000 --> 19:42.000 So we started out with about four full-time engineers in 2015. 19:42.000 --> 19:45.000 And now we're at 10 years later. 19:45.000 --> 19:48.000 We're issuing far more sorts than we were back then. 19:48.000 --> 19:49.000 And we have 12 engineers. 19:49.000 --> 19:51.000 They're doing a great job. 19:59.000 --> 20:03.000 Yeah, simplicity and efficiency are very related. 20:03.000 --> 20:07.000 So I think the last principle here is transparency. 20:08.000 --> 20:17.000 A good example of that is we started filing really detailed public incident reports all long time ago before it was really common to do that. 20:17.000 --> 20:21.000 Now the industry has sort of moved to a point where it's required to do these things. 20:21.000 --> 20:25.000 But back when we started doing it, it was not as common. 20:25.000 --> 20:34.000 And at the time we sort of wonder like are we airing too much dirty laundry here and we wondered if it would lead to more or less trust. 20:35.000 --> 20:38.000 But I think it showed that we really understand the problems. 20:38.000 --> 20:42.000 And we showed exactly how we were stunned responded to those problems. 20:42.000 --> 20:45.000 And the end it definitely led to more trust. 20:45.000 --> 20:48.000 So let's work out well for us. 20:48.000 --> 20:50.000 Another example. 20:50.000 --> 20:53.000 Our open source CA software. 20:53.000 --> 20:56.000 Doing it publicly has been great for the web PKI. 20:56.000 --> 20:58.000 People can really see how this stuff works. 20:58.000 --> 21:02.000 If you want to find out how a certificate authority functions and issues certificates, 21:02.000 --> 21:09.000 you can go to this repository and you can find all the dirty details written up and go. 21:09.000 --> 21:12.000 It also has helped our client developers in the ecosystem. 21:12.000 --> 21:15.000 So we don't actually make a client for lots and groups. 21:15.000 --> 21:17.000 The community does that. 21:17.000 --> 21:26.000 And if they want to know what's happening on the server side, they can just look up the code and read it. 21:26.000 --> 21:29.000 Here's some lessons. 21:29.000 --> 21:32.000 The first one was just me by an engineer. 21:32.000 --> 21:34.000 About a week ago. 21:34.000 --> 21:39.000 Who's saying it's a very good thing that let's think of this not in the hot path of every TLS connection. 21:39.000 --> 21:40.000 Right. 21:40.000 --> 21:43.000 We give you a syrup but then you make a lot of. 21:43.000 --> 21:47.000 Maybe it seemed obvious to you but it's not obvious to all people who designed systems. 21:47.000 --> 21:52.000 There's one exception here which is that OCS P thing that we're going to kill off soon. 21:52.000 --> 21:57.000 Many times in a connection people ask for OCS P data but we're going to get rid of that. 21:57.000 --> 22:06.000 So if you're designing larger systems like a WebPKF something else thinking about whether critical components are or not in the hot path is really important. 22:06.000 --> 22:09.000 This is an important. 22:09.000 --> 22:14.000 A big part of why lots and groups possible. 22:14.000 --> 22:16.000 Open standards can help. 22:16.000 --> 22:26.000 What I mean by this is oftentimes you'll see people say like out of principle I want to engage with open standards or it's like a nice thing to do or it seems like. 22:26.000 --> 22:31.000 The ethical thing to do or something but it's also actually been very helpful for us. 22:31.000 --> 22:34.000 It's not just not just a good vibe. 22:34.000 --> 22:37.000 So building on an open standard helps a community build a client ecosystem. 22:37.000 --> 22:40.000 That's more vibrant than we could ever build ourselves. 22:40.000 --> 22:44.000 We thought about building clients at the beginning of lesson crypt. 22:44.000 --> 22:50.000 And actually we started to build on before we turned it over to FF and they built Serpa. 22:50.000 --> 22:54.000 But we realized pretty quickly that on our budget with our resources. 22:54.000 --> 22:58.000 There are so many deployment environments out there. 22:58.000 --> 23:02.000 We're not going to be able to make a client that works for enough people. 23:02.000 --> 23:03.000 We could never do that. 23:03.000 --> 23:06.000 We can only succeed here with the community. 23:06.000 --> 23:12.000 So we sort of switched our attention to making it as easy as possible for the community to enable them. 23:12.000 --> 23:20.000 And building on an open API really helped with that. 23:21.000 --> 23:26.000 This is sort of along the simplicity lines again, but we really have to focus on what's important. 23:26.000 --> 23:29.000 You can't do it all, especially if you want to be efficient. 23:29.000 --> 23:31.000 So we say no to stuff all the time. 23:31.000 --> 23:33.000 We don't do OVE, we don't do EV. 23:33.000 --> 23:36.000 We have some fairly limited support options. 23:36.000 --> 23:43.000 The forum is really wonderful, but there's not the kind of support options that you might get from another commercial provider. 23:43.000 --> 23:46.000 There's some other things on this list. 23:50.000 --> 23:52.000 Thanks for watching. 24:20.000 --> 24:35.000 Thanks for watching. 24:35.000 --> 24:40.000 First of all, no one that was dealing with this problem with me. 24:40.000 --> 24:43.000 I knew how to build a CA. 24:43.000 --> 24:50.000 I've got to create a legal entity, hire staff, figure out the CA's work, get trust in bail, the browser, raise a bunch of money every year. 24:50.000 --> 24:54.000 It's an intimidating thought that that's the path you might need to go down. 24:54.000 --> 24:56.000 And it's not really short and that network work, right? 24:56.000 --> 25:01.000 You can get pretty far into this before you realize this is just not going to play out the way we wanted it to. 25:01.000 --> 25:05.000 But sometimes you've got to do this to have nice things. 25:05.000 --> 25:12.000 So I guess the point here is, if you see other things in the world that are missing, 25:12.000 --> 25:15.000 it seems hard to do them. 25:15.000 --> 25:16.000 Sometimes it's worth it. 25:16.000 --> 25:18.000 You should consider it. 25:18.000 --> 25:22.000 It was a lot of work, but it was not an insurmountable amount of work. 25:22.000 --> 25:24.000 And it was totally worth it. 25:24.000 --> 25:30.000 Billions of people experiences significantly more secure in privacy, respecting web now. 25:30.000 --> 25:33.000 So this is our 10th anniversary. 25:33.000 --> 25:37.000 We issued our first certain 2015. 25:37.000 --> 25:40.000 And here's how you can help us celebrate that. 25:40.000 --> 25:44.000 You can help us convince any remaining 9HGPS websites to make the switch. 25:44.000 --> 25:48.000 You can donate plots and cook or get your company in response to us. 25:48.000 --> 25:50.000 You can contribute to an acne client. 25:50.000 --> 25:57.000 I would suggest that a very good task is to help acne clients implement that AI protocol that I talked about earlier. 25:57.000 --> 26:00.000 You can help people in our community form. 26:00.000 --> 26:03.000 People ask questions there or staff try to answer them. 26:03.000 --> 26:09.000 But, you know, we do depend on community contributions to do a good job there. 26:10.000 --> 26:16.000 And you can help make the next piece of public benefit and infrastructure the web needs. 26:16.000 --> 26:20.000 So thank all of our sponsors. 26:20.000 --> 26:23.000 We're very lucky to have them. 26:28.000 --> 26:30.000 That's it. 26:31.000 --> 26:48.000 Thank you very much Josh. 26:48.000 --> 26:53.000 We've got a lot of time for questions so don't be shy. 26:53.000 --> 26:54.000 Go ahead. 27:00.000 --> 27:02.000 Hello, thanks for the talk. 27:02.000 --> 27:14.000 I was wondering, say hypothetically, if everyone at some point switched from 90 days to 60 days, which is an understandable. 27:14.000 --> 27:21.000 Wouldn't that add a lot more quickly than anticipated? 27:21.000 --> 27:24.000 Yeah, so the question is, if everybody switches to 60 days, 27:24.000 --> 27:28.000 we're going to have to issue a lot more sorts and we're ready for that kind of strain. 27:28.000 --> 27:32.000 It is definitely true in something we think about a lot of these days. 27:32.000 --> 27:37.000 I haven't done the math in a little while, but I think it's about if everybody switched today, which they won't. 27:37.000 --> 27:43.000 But if they did, I think it'd be about 20 times many sorts. 27:43.000 --> 27:44.000 I don't know for a rainy day. 27:44.000 --> 27:46.000 We're going to slowly ramp it up. 27:46.000 --> 27:49.000 We're going to issue some six day sorts for ourselves first. 27:49.000 --> 27:55.000 Then we're going to enroll sort of a set of early adopters and see how that goes. 27:55.000 --> 27:56.000 We'll ramp it up for there. 27:56.000 --> 27:57.000 We will be ready. 27:57.000 --> 28:01.000 The main constraint on scalability for us is our database. 28:01.000 --> 28:05.000 There are so many thousands of rights per second happening on that. 28:05.000 --> 28:08.000 Not to mention tens of thousands of reads every second. 28:08.000 --> 28:11.000 So the database is always a scalability issue for us. 28:11.000 --> 28:15.000 So the only question for us is does our database have the capacity. 28:15.000 --> 28:19.000 We have a plan for adding it as we need it. 28:19.000 --> 28:23.000 So quickly, if you're leaving, please use the doors in the back of the auditorium. 28:23.000 --> 28:27.000 So don't disrupt the answering of the questions and do try to keep it quiet. 28:27.000 --> 28:32.000 Thank you in advance. 28:32.000 --> 28:34.000 Thanks for the presentation. 28:34.000 --> 28:38.000 You mentioned the key compromises happen far more often than we realize. 28:38.000 --> 28:44.000 Do you perhaps know any numbers or any data from where this assertion comes from? 28:44.000 --> 28:53.000 That's a tough one because we only know about the key compromises that get reported to us. 28:53.000 --> 28:59.000 And we don't usually have like our own live investigations. 28:59.000 --> 29:03.000 We only know when people request revocation of a certificate. 29:03.000 --> 29:05.000 We also don't know exactly why they did it. 29:05.000 --> 29:10.000 Do they suspect key compromises or with actual key compromises or it's just some other reason 29:10.000 --> 29:12.000 that are reporting as key compromises. 29:12.000 --> 29:15.000 I don't really know the answer. 29:15.000 --> 29:20.000 But one of the public ways you can see this happens more often than others is there are 29:20.000 --> 29:28.000 There are people who go and told get a hover positurized looking for private keys and they find them way more often than you would think that they would. 29:28.000 --> 29:31.000 I also sort of remember and tell them quote me on this. 29:31.000 --> 29:38.000 But I think they remember that there are about six months ago we had about 35,000 revokes certificates. 29:38.000 --> 29:41.000 And that doesn't mean they were all revoked because of key compromises. 29:41.000 --> 29:47.000 But out of all the certificates we had outstanding it was 35,000, which is another one of those numbers. 29:47.000 --> 29:49.000 It's a lot or a little depending on how you look at it. 29:49.000 --> 29:53.000 But key compromises I think is pretty widely under-reported. 29:53.000 --> 29:57.000 I think people's immediate response is not necessarily to successfully revoke a certificate. 29:57.000 --> 30:01.000 So I don't think our numbers say too much about it. 30:01.000 --> 30:04.000 Sorry I don't have a more clear answer. 30:05.000 --> 30:09.000 Hi, I still have to trust other CA's. 30:09.000 --> 30:15.000 And it's really hard to pin which CA each domain uses. 30:15.000 --> 30:18.000 Do you think there is any solution to that? 30:18.000 --> 30:24.000 Because lots of people want to say, oh, when I talk to this server, I'll always want to use only. 30:24.000 --> 30:26.000 Let's encrypt CA and no other CA. 30:26.000 --> 30:29.000 And it doesn't scale right now. 30:29.000 --> 30:33.000 And I built Linux distribution so I can ship it for everybody. 30:33.000 --> 30:39.000 Can I ask clarifying question, do you mean can you as a visitor to a website or acquire a certain CA's? 30:39.000 --> 30:42.000 Or do you mean it's kind of website or acquire all these certain? 30:42.000 --> 30:43.000 Both. 30:43.000 --> 30:48.000 But ideally for clients to be able to self enforce it. 30:48.000 --> 30:52.000 I don't know how to self enforce it on a like per website basis. 30:52.000 --> 30:56.000 Certainly you can edit the trust list in your operating system and just delete all the CA's. 30:56.000 --> 30:57.000 You don't want to trust. 30:57.000 --> 31:01.000 Then I don't know how to do it on a per website basis on the client side. 31:01.000 --> 31:04.000 And the server that side the answer is CA records. 31:10.000 --> 31:11.000 This is my turn. 31:11.000 --> 31:14.000 Okay, so I don't actually have a question. 31:14.000 --> 31:16.000 I just wanted to thank you guys. 31:16.000 --> 31:20.000 You are doing amazing shit and I'm totally grateful for it. 31:20.000 --> 31:21.000 Thank you. 31:21.000 --> 31:22.000 Thank you. 31:31.000 --> 31:40.000 How did you get all the major websites to actually trust you? 31:40.000 --> 31:43.000 So I couldn't hear the question very well. 31:43.000 --> 31:49.000 How did you convince all the major browsers to trust you? 31:49.000 --> 31:58.000 If you want to get trusted by browsers, you can go one of two routes or both routes at the same time. 31:58.000 --> 32:01.000 One option is you can create or sort of get authority to make it compliant. 32:01.000 --> 32:02.000 You can get an audit. 32:02.000 --> 32:05.000 It's called a web trust audit to compliance audit. 32:05.000 --> 32:09.000 And you can just apply to the root programs at the various browsers. 32:09.000 --> 32:14.000 The major ones that everybody is concerned with are Apple, Microsoft, 32:14.000 --> 32:17.000 Mozilla, Google. 32:17.000 --> 32:19.000 I'm sure I'm forgetting one. 32:19.000 --> 32:23.000 But yeah, you can apply to these four or five different root programs out there. 32:23.000 --> 32:30.000 And then, you know, that'll take anywhere from a month to a few months to make a decision. 32:30.000 --> 32:37.000 And if they agree to trust your route, then you often have to wait for that trust to propagate. 32:37.000 --> 32:43.000 So like, for example, if you get trusted by Android and they ship your route in the next version of Android, 32:43.000 --> 32:50.000 you have to wait for all the people who use them who have older versions of Android to update to a version that trust you. 32:50.000 --> 32:58.000 And I would say going down that path, probably the fastest you could get ubiquitous trust is about seven and a half years. 32:58.000 --> 33:01.000 You used to be 10. It's a little better now. 33:01.000 --> 33:10.000 So if you're a new CA, you don't really want to pay the money to become compliant and then maintain compliance for seven years, 33:10.000 --> 33:13.000 while you wait for your stuff to be trusted. 33:13.000 --> 33:22.000 So most people will get to a compliance status, finish their audit, and then they'll get cross signed by another CA. 33:22.000 --> 33:30.000 So you have to make a deal with another CA where they take a route that's already trusted, and then they cross sign your route, so that I mean, 33:30.000 --> 33:35.000 anybody running across your stuff will trust you via that other CA. 33:35.000 --> 33:47.000 That is, I mean, at a minimum, it's expensive, and it's expensive, not for random reasons, expensive because the cross signing CA is taking on the liability of your compliance. 33:47.000 --> 33:54.000 So if you cross sign a new CA, and that CA becomes non-compliant, you are also non-compliant. 33:54.000 --> 34:01.000 That's a big risk for an organization that's already trusted to take, so it's expensive to get cross signed. 34:01.000 --> 34:04.000 It's hard to quote numbers that's really a bespoke situation. 34:04.000 --> 34:11.000 In our case, we found an existing CA called IdentTrust that really understood what we were trying to do, and it was happy to work with us. 34:11.000 --> 34:19.000 And so we got cross signed by IdentTrust in 2015 before we, well, when we issued our first publicly trusted search. 34:19.000 --> 34:24.000 So we were trusted by one of these like widely trusted identity search. 34:24.000 --> 34:30.000 And right away, and not only ended in September of 2024. 34:30.000 --> 34:40.000 So we kept that cross sign for almost 10 years, and then we didn't renew it, because lots of cryptos now finally widely enough trusted. 34:40.000 --> 35:01.000 All right, you mentioned that you don't have any idea how many people will adopt these six day certificates, but we do have a very large audience here. 35:01.000 --> 35:11.000 First, wondering if we could maybe show some hands to figure out how many people in this audience would like to switch to six day certificates. 35:11.000 --> 35:17.000 All right, who would use a six day certificate if you got it tomorrow? 35:17.000 --> 35:19.000 All right, that's a lot of trust. 35:19.000 --> 35:28.000 I mean, I'd say trust because really the issue is trust, most of the concern that people have is, you know, do you have time to renew a certificate of physical problem? 35:28.000 --> 35:34.000 Or if the CA goes down, likely we've never been down for very long, but could be an issue. Let me ask one more question now. 35:34.000 --> 35:38.000 How many people would use IP address sorts if they are available? 35:38.000 --> 35:42.000 That's way more people than I thought, okay. 35:42.000 --> 36:05.000 Do you ever fear that you will become a single point of failure for the entire internet, especially with the growing numbers you've seen, and do you have any plans or ideas about that? 36:05.000 --> 36:08.000 I'm sorry, I can't hear clearly enough. 36:08.000 --> 36:16.000 Do you have concerns that you might become a single point of failure for the entire internet at some point? 36:16.000 --> 36:20.000 Not the first time I've heard this question. 36:20.000 --> 36:29.000 I think there are enough organizations out there that have an interest in doing this that we are not going to become a single point of failure. 36:29.000 --> 36:38.000 I don't know how many CA's is too few, but we've definitely been in a situation where we had too many, but I don't think it's going to come down. 36:38.000 --> 36:50.000 I think there, you know, AWS Trust, Google Trust are relatively new entrants, they're doing fine. I don't think it's going to come down, which is lots in crypt. 36:50.000 --> 37:07.000 I got one more comment about that though, because CA's are moving towards this really automated model on a standard protocol, if there was a problem right, it becomes much easier than it ever has been before for somebody to pick up the slack if somebody else stops. 37:07.000 --> 37:17.000 Like, in theory, if one of the CA's, like, that's a group of somebody else that disappeared, somebody else can open up their API endpoint, you're acting me client that direction in your good shape. 37:17.000 --> 37:25.000 So it's easier than ever, I mean, the web PKI in general is a lot more resilient now. 37:25.000 --> 37:38.000 In a very early slide, you had a thing where you said you would want to migrate away from MariaDB to MayaSQL. Could you shed some light on that? 37:38.000 --> 37:53.000 Yeah, we push, we push both of these things very hard. We once told, really be people, the metrics for database, and they were like, oh, that's the big one. 37:53.000 --> 38:05.000 The reason we're moving is not because our problem with MariaDB itself, it's because we're going to need to switch to a more closer solution, and we're probably going to use the test. 38:05.000 --> 38:17.000 And so we're doing switching from MariaDB to my SQL for the better of the test compatibility, not because of an issue, it's like how MariaDB works on its own. 38:17.000 --> 38:32.000 In your personal opinion, what do you feel the biggest gap or area for improvement is in the security of the web PKI? What worries you? 38:32.000 --> 38:41.000 The question is, what do I think is the biggest gap in security? 38:41.000 --> 38:56.000 I don't know if this is security the way you mean it, but certainly AI that protocol I keep talking about, like the automated renewal of sorts of specific times that resiliency measure is important for the security of servers around the internet. 38:56.000 --> 39:21.000 For CS themselves, one issue is the integrity of the validation process, so when we do a validation check whether or not you are the website that you say you are, there's vulnerability is something called a BGP attack, where people can use fake BGP notices to redirect traffic. 39:21.000 --> 39:31.000 We've known about this for a while, there's a team at Princeton that can do it for you live and demand, not in all situations, mercifully, but it's a scary demo of you. 39:31.000 --> 39:47.000 So if you've known about that for a while, we worked with that team at Princeton to develop something we called multi-perspective validation, which so if you get a certificate from Watson Cup today, instead of getting one validation request from our primary data centers, you'll get four or five or six requests. 39:47.000 --> 39:52.000 And they're all going to come from different parts of the world and different parts of the internet. 39:52.000 --> 40:07.000 And the goal here is if you use BGP to redirect traffic on one path, that's not going to work because you're going to have to pull that off on six completely different paths and different geographies all the same time in order to trick us into issuing your assert. 40:07.000 --> 40:12.000 That is pretty effective, it's not perfect, but it's pretty effective. 40:12.000 --> 40:19.000 The only way to be better about this would be ubiquitous DNS sec, but I think that's basically never going to happen. 40:19.000 --> 40:26.000 And I'm not sure that it should happen, even if it was possible, DNS sec is pretty problematic in a lot of ways. 40:26.000 --> 40:35.000 So one of the things we're looking at is to try to see if we can bring encryption to recursive DNS. 40:35.000 --> 40:40.000 So it's not exactly the same set of guarantees that DNS sec gives you. 40:40.000 --> 40:53.000 But if we and our recursive DNS lookups could get the authoritative servers speak essentially DOH with quicker DOQ or something like that, that would help us a lot with network attacks. 40:53.000 --> 41:01.000 So a long answer, but I think probably my answer is the integrity BGP attack vulnerability. 41:02.000 --> 41:06.000 For TLS to work, local time is important. 41:06.000 --> 41:17.000 Can you help with adopting NTS, which is network protocol secure over NTP over TLS basically, or do you want to host a pool? 41:17.000 --> 41:22.000 Because right now there's only like 20 servers on the internet. 41:22.000 --> 41:24.000 IP search will help. 41:25.000 --> 41:31.000 Yes, NTS adoption, it's basically HGPS, but for NTP. 41:31.000 --> 41:39.000 There's some people here from trying to detect foundation, like I mentioned before, that maintain NTP software that we helped build. 41:39.000 --> 41:45.000 It supports NTS very well, the more people that make the switch, the better we switch up, lots of encrypt. 41:45.000 --> 41:51.000 I think they are helping add people to the pool with their NTP implementations. 41:51.000 --> 42:03.000 So I agree, it would be a good thing to do. It is not the fastest moving ecosystem as far as I can tell. 42:03.000 --> 42:14.000 Thanks. Before it's encrypt, certificates were hard to get, and they were expensive. 42:14.000 --> 42:27.000 And so someone could say, well, if you see a green padlock on the address bar, that means the website has paid for the certificate, and therefore it's trustworthy. 42:27.000 --> 42:35.000 That could have been maybe used as an argument against democratizing these certificates. 42:35.000 --> 42:43.000 I think the argument is 40, but maybe you did encounter it when it's encrypted, did you encounter it? 42:43.000 --> 42:50.000 I'm really sorry, I'm having hard time hearing the questions, like fuzzy kind of. 42:50.000 --> 43:04.000 Before it's encrypted, people could say that the padlock meant that the website was trustworthy, because it was expensive to get. 43:04.000 --> 43:09.000 Sorry, I just can't make out the question, I can't hear well enough. 43:09.000 --> 43:28.000 Sorry. 43:28.000 --> 43:36.000 Yeah, I think there has been skepticism about, can you trust a free certificate as much as you trust a paid one? 43:36.000 --> 43:46.000 It's definitely come up. I heard a lot from about 2015 to 2018, 2019, but I think I haven't heard too many complaints about it in years. 43:46.000 --> 43:52.000 The browsers did a lot of good work with their interfaces to clarify things for people. 43:52.000 --> 43:56.000 Some of the browser UI is back in 2015. 43:56.000 --> 44:00.000 I think created more confusion than clarity. 44:00.000 --> 44:06.000 So I credit them a lot with clearing that situation up, and I don't hear about it much anymore. 44:06.000 --> 44:08.000 Thank you. 44:17.000 --> 44:24.000 I lost you. Thank you. 44:24.000 --> 44:29.000 I was wondering about the post quantum crypto era. 44:29.000 --> 44:37.000 Are you worried that it will give you more work or give your systems more work or your people? 44:38.000 --> 44:47.000 Yeah, so the question is, I think, what are we going to do about post quantum stuff and are we worried about whether or not it will work? 44:47.000 --> 44:56.000 In the context of TLS in general, the most important thing to do is have post quantum hand shakes for TLS or key exchange. 44:56.000 --> 44:58.000 That's available now. 44:58.000 --> 45:01.000 Certificate authorities like us, we don't need to do anything about that. 45:01.000 --> 45:09.000 And that's sort of okay because the reason you want PQ hand shakes now is that people can't save your TLS data now and decrypt it later. 45:09.000 --> 45:13.000 But whether or not we do post quantum doesn't change that fact. 45:13.000 --> 45:16.000 It's only useful at the moment of authentication. 45:16.000 --> 45:21.000 So we don't really need to do it as a PQI too far in advance. 45:21.000 --> 45:26.000 But there are people who have an opinion that is going to take so long to do that we should get started now. 45:26.000 --> 45:29.000 I don't know, ultimately comes down to the size of the certificates. 45:29.000 --> 45:40.000 If you have a post quantum certificate, the signature is much longer and it can break handshake packets and TLS into multiple packets and introduce latency. 45:40.000 --> 45:49.000 And there are a lot of people out there correlating, you know, tiny fractions of a second with millions of dollars of income or something like that. 45:49.000 --> 45:52.000 So there's a lot of concern about doing it now. 45:52.000 --> 45:59.000 And if you don't panic about it yet, even if it was something that we wanted to do and the standards allowed it, which they don't allow it. 45:59.000 --> 46:05.000 At this point, like CA's aren't allowed to use post quantum signatures, it's not included in the set of allowable algorithms. 46:05.000 --> 46:07.000 We have a ways to go before we actually could. 46:07.000 --> 46:14.000 So for example, we generate all of our root and intermediate keys inside of HSM's hardware security modules, 46:14.000 --> 46:17.000 basically like special computers up protect private keys. 46:17.000 --> 46:21.000 And those things don't support post quantum algorithms yet either. 46:21.000 --> 46:26.000 So even if we were going to do it, we don't have HSM's that can do it yet. 46:26.000 --> 46:31.000 And not only do we need HSM's, we need HSM's that can do tens of thousands of signatures per second, 46:31.000 --> 46:36.000 which means hardware implementations and I can do that on a CPU. 46:36.000 --> 46:42.000 So there are a lot of steps between us and getting there and there's a lot of debate about how quickly we need to do that. 46:42.000 --> 46:48.000 And personally, I think we just need to wait a little while for the algorithms to work out, 46:48.000 --> 46:51.000 see if we can make the signatures smaller. 46:51.000 --> 46:58.000 I don't think it's an issue too much at the moment. 46:58.000 --> 47:03.000 We can perhaps do one more question if anybody's got any. 47:03.000 --> 47:08.000 One more. 47:09.000 --> 47:12.000 Okay, we go one. 47:26.000 --> 47:35.000 Do you think that there will be someday something similar to let's encrypt for email communication and encryption and stuff like this? 47:35.000 --> 47:37.000 What kind of communication encryption? 47:37.000 --> 47:39.000 For emails. 47:39.000 --> 47:40.000 Email. 47:40.000 --> 47:41.000 Yeah. 47:41.000 --> 47:44.000 We got that. 47:44.000 --> 47:51.000 That comes up a lot with this crowd. 47:51.000 --> 47:59.000 I think the reason I assume you're talking basically about SMI and certificates and whether or not we might issue those. 47:59.000 --> 48:05.000 It's quite expensive to add a new compliance regime and another system right simplicity. 48:05.000 --> 48:13.000 So we try not to do things that require a lot of work until we're confident that they're going to be widely adopted. 48:13.000 --> 48:21.000 So right now, as much as this does not make some people happy to sit here, I think SMI is kind of a niche thing right now. 48:21.000 --> 48:24.000 Not that many people use it. 48:24.000 --> 48:31.000 I think we would need to understand that there's a plan for a lot wider adoption to make it worthwhile for us to get into that game. 48:31.000 --> 48:34.000 I think we all know who the major providers are. 48:34.000 --> 48:37.000 I think they're going to have to be a part of that plan. 48:37.000 --> 48:43.000 So we need to clearly understand that there's a path towards wider adoption and there's a path towards. 48:43.000 --> 48:46.000 You know, a lot of people using these certificates that we make them available. 48:46.000 --> 48:49.000 I think it's possible for that to exist. 48:49.000 --> 48:54.000 I'm not too much personally in the email world, so I don't know how likely it is. 48:54.000 --> 48:58.000 We'll have to see. I don't know. 48:58.000 --> 49:09.000 But yeah, it really boils down to whether or not we believe it can break out of just being a niche technology or not. 49:09.000 --> 49:10.000 Thank you. 49:10.000 --> 49:11.000 That's all. Thanks.