0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/448 Thanks! 1 00:00:09,620 --> 00:00:10,969 Thanks. Good afternoon. 2 00:00:10,970 --> 00:00:12,499 I hope everyone's had a great Congress. 3 00:00:12,500 --> 00:00:15,049 We're getting quite close to the end and 4 00:00:15,050 --> 00:00:16,339 it's been a lot of fun for me and it's 5 00:00:16,340 --> 00:00:17,839 great to be here. 6 00:00:17,840 --> 00:00:19,369 I'm s I'm from the Electronic Frontier 7 00:00:19,370 --> 00:00:21,529 Foundation, and I'm here to talk 8 00:00:21,530 --> 00:00:22,909 about a project that we've been working 9 00:00:22,910 --> 00:00:25,249 on actually for about three years 10 00:00:25,250 --> 00:00:26,329 in some secrecy. 11 00:00:26,330 --> 00:00:28,489 And it's really excellent to have this 12 00:00:28,490 --> 00:00:30,199 public and to be able to talk about it 13 00:00:30,200 --> 00:00:32,508 and to be able to share our ideas 14 00:00:32,509 --> 00:00:33,529 and our plans with everyone. 15 00:00:34,670 --> 00:00:36,379 So there are a lot of acronyms in this 16 00:00:36,380 --> 00:00:38,359 space and this is really only a tiny 17 00:00:38,360 --> 00:00:39,529 selection. 18 00:00:39,530 --> 00:00:41,059 And I just wanted to start by letting 19 00:00:41,060 --> 00:00:43,129 people know if there are people who don't 20 00:00:43,130 --> 00:00:45,469 work with certificates or with 21 00:00:45,470 --> 00:00:47,899 Web encryption a lot the really 22 00:00:47,900 --> 00:00:49,549 most fundamental acronyms that occur the 23 00:00:49,550 --> 00:00:50,539 most. 24 00:00:50,540 --> 00:00:52,609 So the protocol that we used 25 00:00:52,610 --> 00:00:55,609 to use as a security layer on top of TCP 26 00:00:55,610 --> 00:00:58,279 was called the SSL when it was invented. 27 00:00:58,280 --> 00:01:00,649 The proper name today is TLS. 28 00:01:00,650 --> 00:01:02,419 That refers to the same protocol and it's 29 00:01:02,420 --> 00:01:03,420 more recent versions. 30 00:01:04,610 --> 00:01:07,729 And of course, when you put that 31 00:01:07,730 --> 00:01:09,799 on top of your underneath your 32 00:01:09,800 --> 00:01:12,499 Web connection, you've got HTP. 33 00:01:12,500 --> 00:01:13,879 We've also got the format of the 34 00:01:13,880 --> 00:01:16,009 certificates for 35 00:01:16,010 --> 00:01:18,349 exchanging the public keys that we use 36 00:01:18,350 --> 00:01:19,639 in these connections. 37 00:01:19,640 --> 00:01:21,859 That's called X five or nine. 38 00:01:21,860 --> 00:01:24,139 The infrastructure that that forms 39 00:01:24,140 --> 00:01:25,759 the basis of is called the public key 40 00:01:25,760 --> 00:01:28,129 infrastructure or pecky 41 00:01:28,130 --> 00:01:30,009 and the entities that. 42 00:01:30,010 --> 00:01:32,169 Publish that sign, the certificates 43 00:01:32,170 --> 00:01:34,419 within the PKK are called certificate 44 00:01:34,420 --> 00:01:36,579 authorities or case 45 00:01:36,580 --> 00:01:38,259 there are many more acronyms out there, 46 00:01:38,260 --> 00:01:39,849 but I'll try not to use too many of them. 47 00:01:42,150 --> 00:01:44,279 So this is a technology for us as privacy 48 00:01:44,280 --> 00:01:46,590 advocates that is really fundamental. 49 00:01:47,600 --> 00:01:48,829 That's really important to them that 50 00:01:48,830 --> 00:01:50,269 we've been advocating for a long time 51 00:01:51,560 --> 00:01:53,839 and we started from a place where people 52 00:01:53,840 --> 00:01:56,089 had this sort of Web 53 00:01:56,090 --> 00:01:58,369 security folklore, that 54 00:01:58,370 --> 00:01:59,839 you need a secure connection to your 55 00:01:59,840 --> 00:02:02,329 website if the user is entering financial 56 00:02:02,330 --> 00:02:05,059 data like a credit card number. 57 00:02:05,060 --> 00:02:07,309 And that's really weird 58 00:02:07,310 --> 00:02:08,629 because credit card numbers are not 59 00:02:08,630 --> 00:02:10,339 really that sensitive. 60 00:02:10,340 --> 00:02:11,749 There are a lot of other things that are 61 00:02:11,750 --> 00:02:13,909 obviously much more sensitive 62 00:02:13,910 --> 00:02:15,139 than a credit card number. 63 00:02:15,140 --> 00:02:16,999 But the folklore persisted for many, many 64 00:02:17,000 --> 00:02:19,129 years that that's what this technology is 65 00:02:19,130 --> 00:02:20,779 about. That's where this technology is 66 00:02:20,780 --> 00:02:23,059 needed, that you use it 67 00:02:23,060 --> 00:02:24,499 when you're accepting credit card numbers 68 00:02:24,500 --> 00:02:26,029 and otherwise not. 69 00:02:26,030 --> 00:02:27,409 And in the last few years, the Web 70 00:02:27,410 --> 00:02:29,689 community has said, OK, also, if the user 71 00:02:29,690 --> 00:02:31,579 is logging in, we need to protect the 72 00:02:31,580 --> 00:02:33,259 username and password. 73 00:02:33,260 --> 00:02:35,149 And OK, after the user has logged in, we 74 00:02:35,150 --> 00:02:36,319 need to protect the authentication 75 00:02:36,320 --> 00:02:37,249 cookie. 76 00:02:37,250 --> 00:02:39,049 So gradually there has been an expansion 77 00:02:39,050 --> 00:02:40,729 of the recognition that this technology 78 00:02:40,730 --> 00:02:42,169 is important. 79 00:02:42,170 --> 00:02:43,579 But I think we need to go much further 80 00:02:43,580 --> 00:02:44,580 than that. 81 00:02:45,500 --> 00:02:46,759 And I don't really think that I have to 82 00:02:46,760 --> 00:02:48,559 convince this audience of that. 83 00:02:48,560 --> 00:02:49,909 But I think we need to convince other 84 00:02:49,910 --> 00:02:51,859 audiences of this that we need a much 85 00:02:51,860 --> 00:02:54,019 stronger vision, that the things 86 00:02:54,020 --> 00:02:56,329 around us, our communications networks, 87 00:02:56,330 --> 00:02:58,489 are actually attacking us all the time 88 00:02:58,490 --> 00:03:01,189 on a large scale routinely, 89 00:03:01,190 --> 00:03:03,649 that these networks are untrustworthy 90 00:03:03,650 --> 00:03:04,849 and that we need to protect our 91 00:03:04,850 --> 00:03:07,009 communications against them for many 92 00:03:07,010 --> 00:03:08,809 reasons, for many threat models against 93 00:03:08,810 --> 00:03:10,279 many attackers in many different 94 00:03:10,280 --> 00:03:11,269 situations. 95 00:03:11,270 --> 00:03:12,919 And there isn't just one reason for that. 96 00:03:12,920 --> 00:03:14,360 There's a whole panoply of reasons 97 00:03:15,590 --> 00:03:17,269 why we ought to think of networks as 98 00:03:17,270 --> 00:03:18,769 untrustworthy and why we ought to think 99 00:03:18,770 --> 00:03:20,629 of network protocols as needing to 100 00:03:20,630 --> 00:03:21,949 protect communications against the 101 00:03:21,950 --> 00:03:22,950 networks. 102 00:03:23,510 --> 00:03:25,609 And plain HTP was never intended 103 00:03:25,610 --> 00:03:27,079 to protect communications against the 104 00:03:27,080 --> 00:03:28,789 network in any way. 105 00:03:28,790 --> 00:03:30,019 It's totally unsecured. 106 00:03:30,020 --> 00:03:32,059 The information is totally in the clear. 107 00:03:32,060 --> 00:03:33,619 The network operator, everyone along the 108 00:03:33,620 --> 00:03:35,719 path has the full ability to spy 109 00:03:35,720 --> 00:03:37,549 on everything that you do and to modify 110 00:03:37,550 --> 00:03:38,629 it and to inject things. 111 00:03:39,770 --> 00:03:41,479 So just to be concrete and this is just a 112 00:03:41,480 --> 00:03:43,999 quick representative sample, not the 113 00:03:44,000 --> 00:03:46,519 full set of reasons why we want secure 114 00:03:46,520 --> 00:03:48,019 connections. 115 00:03:48,020 --> 00:03:49,759 We've got issues like skyjacking and 116 00:03:49,760 --> 00:03:51,079 location tracking. 117 00:03:51,080 --> 00:03:53,749 So if you have a cookie, it might be 118 00:03:53,750 --> 00:03:55,639 an authentication cookie. 119 00:03:55,640 --> 00:03:58,819 It might just be a tracking cookie. 120 00:03:58,820 --> 00:04:01,219 If someone else can see that cookie, 121 00:04:01,220 --> 00:04:03,409 that cookie can be repurposed to steal 122 00:04:03,410 --> 00:04:05,479 your session, to impersonate you or 123 00:04:05,480 --> 00:04:07,039 just to recognize that that's you. 124 00:04:08,360 --> 00:04:10,609 And we heard last year that governments 125 00:04:10,610 --> 00:04:12,499 noticed that and that there is a lot of 126 00:04:12,500 --> 00:04:14,269 infrastructure that's been created to 127 00:04:14,270 --> 00:04:16,639 say, OK, that cookie wasn't meant 128 00:04:16,640 --> 00:04:18,739 to be personally identifiable, but it is 129 00:04:18,740 --> 00:04:20,989 to us because we know who that person 130 00:04:20,990 --> 00:04:23,239 was. And therefore, whenever we see that 131 00:04:23,240 --> 00:04:25,250 cookie sent to that site, 132 00:04:26,300 --> 00:04:27,229 we know who that is. 133 00:04:27,230 --> 00:04:28,369 We know where that person is. 134 00:04:28,370 --> 00:04:29,979 We can recognize that device immediately. 135 00:04:31,670 --> 00:04:33,769 There are also software downloads. 136 00:04:33,770 --> 00:04:35,569 I was just hearing about a really popular 137 00:04:35,570 --> 00:04:37,639 tool for creating 138 00:04:37,640 --> 00:04:40,489 installation media for Linux systems. 139 00:04:40,490 --> 00:04:42,829 And you use this tool and you create 140 00:04:42,830 --> 00:04:44,929 bootable USB media. 141 00:04:44,930 --> 00:04:46,429 And I looked at how does it get the 142 00:04:46,430 --> 00:04:49,399 images for your installation media? 143 00:04:49,400 --> 00:04:51,499 And the answer is there's a hard coded 144 00:04:51,500 --> 00:04:53,869 list of 261 145 00:04:53,870 --> 00:04:56,239 URLs from which ISO 146 00:04:56,240 --> 00:04:57,529 images can be downloaded. 147 00:04:57,530 --> 00:04:59,629 According to what operating system do 148 00:04:59,630 --> 00:05:00,829 you want to install? 149 00:05:00,830 --> 00:05:03,079 What version do you want to install? 150 00:05:03,080 --> 00:05:05,659 None of those 261 URLs 151 00:05:05,660 --> 00:05:07,489 is a secure origin. 152 00:05:07,490 --> 00:05:09,559 All of them are HTP 153 00:05:09,560 --> 00:05:11,659 or FTP with no checks on 154 00:05:11,660 --> 00:05:13,819 verification and no signature 155 00:05:13,820 --> 00:05:15,229 verification. 156 00:05:15,230 --> 00:05:16,939 So you're making installation media for 157 00:05:16,940 --> 00:05:19,009 your operating system and your tools 158 00:05:19,010 --> 00:05:20,299 are going out there and getting your 159 00:05:20,300 --> 00:05:22,429 operating system over a completely 160 00:05:22,430 --> 00:05:24,019 unauthenticated, completely insecure 161 00:05:24,020 --> 00:05:24,919 connection. 162 00:05:24,920 --> 00:05:26,659 And you're installing not necessarily 163 00:05:26,660 --> 00:05:27,949 what you wanted, but whatever your 164 00:05:27,950 --> 00:05:30,049 network operator wanted you to install. 165 00:05:30,050 --> 00:05:31,609 And that pattern is repeated over and 166 00:05:31,610 --> 00:05:34,429 over again with all kinds of software. 167 00:05:34,430 --> 00:05:36,739 People are downloading unauthenticated 168 00:05:36,740 --> 00:05:39,019 software and installing it and entrusting 169 00:05:39,020 --> 00:05:40,399 their computers and trusting all their 170 00:05:40,400 --> 00:05:42,559 communications to software every 171 00:05:42,560 --> 00:05:43,560 day. 172 00:05:44,320 --> 00:05:45,729 Reader privacy is another really 173 00:05:45,730 --> 00:05:47,169 significant one. 174 00:05:47,170 --> 00:05:50,109 So sometimes we hear from 175 00:05:50,110 --> 00:05:51,489 people who publish websites like 176 00:05:51,490 --> 00:05:54,039 newspapers, they say 177 00:05:54,040 --> 00:05:55,629 all of the content on our website is 178 00:05:55,630 --> 00:05:56,630 public. 179 00:05:57,070 --> 00:05:59,529 There is nothing secret on our Web site. 180 00:05:59,530 --> 00:06:00,469 We don't need it. 181 00:06:00,470 --> 00:06:01,470 Setpiece. 182 00:06:03,690 --> 00:06:05,519 The confidentiality of the sensitivity 183 00:06:05,520 --> 00:06:07,739 there, as with so many other sites, 184 00:06:07,740 --> 00:06:10,619 is not in the secrecy of the content, 185 00:06:10,620 --> 00:06:13,049 it's the sensitivity of the association 186 00:06:13,050 --> 00:06:15,209 of the reader with what the reader 187 00:06:15,210 --> 00:06:16,270 is choosing to read. 188 00:06:17,700 --> 00:06:20,189 Librarians understand this very well. 189 00:06:20,190 --> 00:06:22,379 Every book in the library, of course, 190 00:06:22,380 --> 00:06:23,819 is completely public. 191 00:06:23,820 --> 00:06:26,249 Anyone can walk in and read the contents 192 00:06:26,250 --> 00:06:27,579 of the book in the library. 193 00:06:27,580 --> 00:06:29,849 There is no attempt to say that this 194 00:06:29,850 --> 00:06:31,979 library books are secret, but 195 00:06:31,980 --> 00:06:33,509 the librarians understand it as a 196 00:06:33,510 --> 00:06:35,729 fundamental ethical responsibility 197 00:06:35,730 --> 00:06:37,889 to protect the association 198 00:06:37,890 --> 00:06:40,229 of the book with the reader, to protect 199 00:06:40,230 --> 00:06:42,569 the fact of who is reading 200 00:06:42,570 --> 00:06:43,570 what. 201 00:06:44,160 --> 00:06:45,749 Librarians have articulated this a long 202 00:06:45,750 --> 00:06:47,939 time ago, and website operators 203 00:06:47,940 --> 00:06:50,219 and publishers need to articulate this to 204 00:06:50,220 --> 00:06:51,269 everything on your website. 205 00:06:51,270 --> 00:06:53,159 May maybe public your readers have a 206 00:06:53,160 --> 00:06:55,439 really important privacy interest in 207 00:06:55,440 --> 00:06:57,329 the selection of what they read on your 208 00:06:57,330 --> 00:06:58,330 site. 209 00:06:59,880 --> 00:07:02,159 Another significant point is 210 00:07:02,160 --> 00:07:03,629 content based censorship built into 211 00:07:03,630 --> 00:07:05,669 networks, a lot of people are familiar 212 00:07:05,670 --> 00:07:07,979 with this through the Golden Shield 213 00:07:07,980 --> 00:07:10,139 Project in China, where if 214 00:07:10,140 --> 00:07:12,029 you access a website that mentions 215 00:07:12,030 --> 00:07:14,219 certain keywords, the Golden Shield 216 00:07:14,220 --> 00:07:15,659 will actually interrupt your connection 217 00:07:15,660 --> 00:07:16,949 to prevent you from reading about that 218 00:07:16,950 --> 00:07:18,869 topic. Unfortunately, more and more 219 00:07:18,870 --> 00:07:20,459 countries are building that kind of 220 00:07:20,460 --> 00:07:22,679 censorship infrastructure directly into 221 00:07:22,680 --> 00:07:23,819 their networks. 222 00:07:23,820 --> 00:07:25,799 And so we need as an anti censorship 223 00:07:25,800 --> 00:07:27,899 measure to prevent 224 00:07:27,900 --> 00:07:29,489 the network operators from being able to 225 00:07:29,490 --> 00:07:30,779 see what we're doing and what we're 226 00:07:30,780 --> 00:07:32,729 communicating about and with whom we're 227 00:07:32,730 --> 00:07:33,730 communicating online. 228 00:07:34,890 --> 00:07:36,449 And just recently, we've been hearing 229 00:07:36,450 --> 00:07:38,819 more and more about mobile 230 00:07:38,820 --> 00:07:42,149 carriers injecting headers 231 00:07:42,150 --> 00:07:44,729 and broadband carriers, injecting 232 00:07:44,730 --> 00:07:46,739 advertisements into people's Web 233 00:07:46,740 --> 00:07:47,999 connections. 234 00:07:48,000 --> 00:07:50,219 So your ISP will advertise to you 235 00:07:50,220 --> 00:07:51,659 by actually tampering with your Web 236 00:07:51,660 --> 00:07:53,999 connection and putting an ad banner in. 237 00:07:54,000 --> 00:07:56,279 Or your mobile 238 00:07:56,280 --> 00:07:58,019 carrier will say, I want to help sites 239 00:07:58,020 --> 00:07:59,309 track you. So I'm going to put in a 240 00:07:59,310 --> 00:08:01,379 header that shows who you 241 00:08:01,380 --> 00:08:02,380 are. 242 00:08:03,570 --> 00:08:05,129 So all of these forms of tampering and 243 00:08:05,130 --> 00:08:07,289 these skell all the way up from these 244 00:08:07,290 --> 00:08:09,419 commercial motives, of course, to 245 00:08:09,420 --> 00:08:11,609 government surveillance motive's 246 00:08:11,610 --> 00:08:13,439 where we heard last year at the Congress 247 00:08:13,440 --> 00:08:15,479 about governments creating massive 248 00:08:15,480 --> 00:08:17,939 infrastructure to actively inject content 249 00:08:17,940 --> 00:08:20,159 into people's Web connections as a way of 250 00:08:20,160 --> 00:08:21,509 delivering malware, as a way of 251 00:08:21,510 --> 00:08:23,369 compromising people's devices. 252 00:08:23,370 --> 00:08:25,259 So it's a widespread tactic that a lot of 253 00:08:25,260 --> 00:08:26,459 people are interested in for a lot of 254 00:08:26,460 --> 00:08:27,809 reasons. 255 00:08:27,810 --> 00:08:30,029 So we need a vision of a secure 256 00:08:30,030 --> 00:08:31,739 web that can defend users against these 257 00:08:31,740 --> 00:08:33,899 things of really routine use of 258 00:08:33,900 --> 00:08:34,900 encryption. 259 00:08:36,200 --> 00:08:37,308 There are a lot of barriers to this. 260 00:08:37,309 --> 00:08:38,389 We've talked to a lot of website 261 00:08:38,390 --> 00:08:40,709 operators about why don't you use 262 00:08:40,710 --> 00:08:41,869 HD on your site? 263 00:08:41,870 --> 00:08:43,308 Why don't you have a secure connection to 264 00:08:43,309 --> 00:08:44,449 your site? 265 00:08:44,450 --> 00:08:45,619 And we hear a lot of things. 266 00:08:45,620 --> 00:08:47,779 And one is the traditional view that it's 267 00:08:47,780 --> 00:08:49,999 slow, that it makes it adds 268 00:08:50,000 --> 00:08:52,099 latency to the process of 269 00:08:52,100 --> 00:08:54,169 establishing a session when the user 270 00:08:54,170 --> 00:08:55,909 first connects to the site or that it 271 00:08:55,910 --> 00:08:58,429 puts a lot of demands on the CPU 272 00:08:58,430 --> 00:08:59,959 of the server. 273 00:08:59,960 --> 00:09:01,459 For some people who have a complicated 274 00:09:01,460 --> 00:09:03,049 server side configuration with load 275 00:09:03,050 --> 00:09:04,999 balancers, there are additional 276 00:09:05,000 --> 00:09:06,619 complexities about engineering 277 00:09:06,620 --> 00:09:08,269 considerations with key management. 278 00:09:09,540 --> 00:09:11,389 But the one that we hear over and over 279 00:09:11,390 --> 00:09:13,579 again most often. 280 00:09:13,580 --> 00:09:15,859 Is all about the difficulty and 281 00:09:15,860 --> 00:09:17,989 the cost of obtaining and 282 00:09:17,990 --> 00:09:19,999 keeping up to date and keeping accurate 283 00:09:20,000 --> 00:09:21,979 and keeping non expired, these 284 00:09:21,980 --> 00:09:24,079 certificates that you need in order to 285 00:09:24,080 --> 00:09:26,209 let the browser establish a secure 286 00:09:26,210 --> 00:09:27,210 connection to your site. 287 00:09:28,460 --> 00:09:30,349 And we've talked to people who are 288 00:09:30,350 --> 00:09:32,269 technically sophisticated, people who 289 00:09:32,270 --> 00:09:34,459 understand what a crypto key 290 00:09:34,460 --> 00:09:36,559 is and they understand what a Web 291 00:09:36,560 --> 00:09:38,839 server is and they understand what 292 00:09:38,840 --> 00:09:40,519 a digital certificate is and they 293 00:09:40,520 --> 00:09:42,439 understand why they need it. 294 00:09:42,440 --> 00:09:44,839 People who understand all of that 295 00:09:44,840 --> 00:09:47,359 still typically take an hour 296 00:09:47,360 --> 00:09:49,069 to actually go through the process and 297 00:09:49,070 --> 00:09:51,199 actually get and deploy the cert if 298 00:09:51,200 --> 00:09:52,459 it's not something that they do on a 299 00:09:52,460 --> 00:09:53,729 regular basis. 300 00:09:53,730 --> 00:09:55,219 Obviously, if it's something that you do 301 00:09:55,220 --> 00:09:57,409 every day or every week, you become 302 00:09:57,410 --> 00:09:58,699 more accustomed to it and more familiar 303 00:09:58,700 --> 00:10:00,649 with it and you can get faster at it. 304 00:10:00,650 --> 00:10:02,839 But we've heard over and over again from 305 00:10:02,840 --> 00:10:04,429 system administrators who only have to 306 00:10:04,430 --> 00:10:07,009 deal with this, say, once a year 307 00:10:07,010 --> 00:10:09,379 that they have to go and look up a recipe 308 00:10:09,380 --> 00:10:11,029 on some website about how do you get a 309 00:10:11,030 --> 00:10:13,039 cert. And they have to go through all of 310 00:10:13,040 --> 00:10:15,439 these steps, creating a key, creating 311 00:10:15,440 --> 00:10:17,239 a certificate status request. 312 00:10:17,240 --> 00:10:19,219 They have to deal with the syntax of open 313 00:10:19,220 --> 00:10:20,870 SSL command line binary 314 00:10:23,270 --> 00:10:23,599 dash. 315 00:10:23,600 --> 00:10:25,669 No doubt some 316 00:10:25,670 --> 00:10:26,670 of you will appreciate that. 317 00:10:28,070 --> 00:10:29,070 Yeah, no doubt. 318 00:10:31,040 --> 00:10:32,269 All right. 319 00:10:32,270 --> 00:10:34,219 So this is this is a complex process 320 00:10:34,220 --> 00:10:35,539 that's really a deterrent to people. 321 00:10:35,540 --> 00:10:36,979 And, of course, there's a financial cost 322 00:10:36,980 --> 00:10:38,509 associated with it, too. 323 00:10:38,510 --> 00:10:40,819 And that's typically a financial cost per 324 00:10:40,820 --> 00:10:41,899 subject, domain names. 325 00:10:43,160 --> 00:10:45,259 And even then, of course, a 326 00:10:45,260 --> 00:10:47,059 year later, it's going to expire and all 327 00:10:47,060 --> 00:10:48,589 of your users are suddenly going to get a 328 00:10:48,590 --> 00:10:50,779 certain error or you're going to add 329 00:10:50,780 --> 00:10:53,119 some virtual hosts, some subdomains 330 00:10:53,120 --> 00:10:54,529 that you didn't think of at the time that 331 00:10:54,530 --> 00:10:55,939 you didn't include in the search. 332 00:10:55,940 --> 00:10:57,349 And users are going to get a certain 333 00:10:57,350 --> 00:10:58,789 error in their browsers when they go to 334 00:10:58,790 --> 00:11:00,149 those subdomains. 335 00:11:00,150 --> 00:11:01,609 And so there's a lot of complexity and 336 00:11:01,610 --> 00:11:03,589 there's a lot of purely administrative 337 00:11:03,590 --> 00:11:05,569 difficulty in keeping these things up to 338 00:11:05,570 --> 00:11:07,969 date, keeping these things deployed, 339 00:11:07,970 --> 00:11:10,099 remembering which cues are 340 00:11:10,100 --> 00:11:11,569 for which sites, which certs are for 341 00:11:11,570 --> 00:11:12,839 which sites. 342 00:11:12,840 --> 00:11:14,509 Where does that go in the Web server 343 00:11:14,510 --> 00:11:16,669 configuration, all of this complexity. 344 00:11:16,670 --> 00:11:18,799 We believe that overall this 345 00:11:18,800 --> 00:11:20,899 is the biggest barrier to adoption on 346 00:11:20,900 --> 00:11:22,309 the part of people who have an interest 347 00:11:22,310 --> 00:11:24,229 in making a secure Web site. 348 00:11:24,230 --> 00:11:26,389 And this is the barrier that we intend to 349 00:11:26,390 --> 00:11:28,669 address and eliminate. 350 00:11:28,670 --> 00:11:30,319 So we've created this project called 351 00:11:30,320 --> 00:11:31,579 Let's Encrypt, and this is a 352 00:11:31,580 --> 00:11:32,569 collaboration. 353 00:11:32,570 --> 00:11:34,099 And we started working with the 354 00:11:34,100 --> 00:11:36,289 University of Michigan on 355 00:11:36,290 --> 00:11:37,219 the idea. 356 00:11:37,220 --> 00:11:39,439 We started about three years ago working 357 00:11:39,440 --> 00:11:40,879 on the idea that there could and should 358 00:11:40,880 --> 00:11:43,069 be a completely automated certificate 359 00:11:43,070 --> 00:11:45,289 authority that can issue 360 00:11:45,290 --> 00:11:47,359 certificates to anyone 361 00:11:47,360 --> 00:11:49,520 quickly at no charge. 362 00:11:51,110 --> 00:11:52,669 And we worked on this project for a 363 00:11:52,670 --> 00:11:54,679 couple of years and we happened to learn 364 00:11:54,680 --> 00:11:56,659 that Mozilla was actually working on the 365 00:11:56,660 --> 00:11:57,799 same project in parallel. 366 00:11:58,940 --> 00:12:00,709 So fortunately, we were able to combine 367 00:12:00,710 --> 00:12:03,349 forces and be 368 00:12:03,350 --> 00:12:05,059 stronger and more effective together and 369 00:12:05,060 --> 00:12:07,009 have a single project among these three 370 00:12:07,010 --> 00:12:09,229 organizations to 371 00:12:09,230 --> 00:12:10,819 bring this vision into practice. 372 00:12:10,820 --> 00:12:13,039 And the vision is also that 373 00:12:13,040 --> 00:12:14,749 we should be better than the existing 374 00:12:14,750 --> 00:12:16,939 CERT authorities, at least for 375 00:12:16,940 --> 00:12:18,739 the portion of the Certificate Authority 376 00:12:18,740 --> 00:12:20,839 space that we occupy in every 377 00:12:20,840 --> 00:12:22,219 way. We should be cheaper. 378 00:12:22,220 --> 00:12:23,899 We should be easier to use, we should be 379 00:12:23,900 --> 00:12:25,549 more convenient and we should be more 380 00:12:25,550 --> 00:12:26,550 secure. 381 00:12:27,260 --> 00:12:28,909 And for our launch, we have commercial 382 00:12:28,910 --> 00:12:30,409 partners, Akamai and Cisco. 383 00:12:30,410 --> 00:12:32,509 And I don't trust and thanks 384 00:12:32,510 --> 00:12:34,189 to them, it's going to be possible for us 385 00:12:34,190 --> 00:12:36,379 to have publicly trusted certificates 386 00:12:36,380 --> 00:12:37,759 that will be accepted by browsers. 387 00:12:47,050 --> 00:12:48,849 So just to be clear about that point, 388 00:12:48,850 --> 00:12:50,949 thanks, just to 389 00:12:50,950 --> 00:12:52,389 be clear about that point, this is the 390 00:12:52,390 --> 00:12:54,249 question that we got the most. 391 00:12:54,250 --> 00:12:55,749 Are users going to have to install 392 00:12:55,750 --> 00:12:57,219 something in their browser in order to 393 00:12:57,220 --> 00:12:58,269 accept your search? 394 00:12:58,270 --> 00:12:59,859 And the answer is no. 395 00:12:59,860 --> 00:13:01,959 The users browsers will trust our cert 396 00:13:01,960 --> 00:13:03,999 authority and its certificates out of the 397 00:13:04,000 --> 00:13:05,259 box. 398 00:13:05,260 --> 00:13:06,759 And for people who aren't familiar with 399 00:13:06,760 --> 00:13:07,859 the intermediate 400 00:13:08,920 --> 00:13:10,929 mechanism, a certificate authority can 401 00:13:10,930 --> 00:13:13,059 delegate its power to another 402 00:13:13,060 --> 00:13:15,249 CERT authority by issuing 403 00:13:15,250 --> 00:13:17,739 a certificate that says this other 404 00:13:17,740 --> 00:13:19,029 entity is also. 405 00:13:20,110 --> 00:13:21,309 And this is something that happens 406 00:13:21,310 --> 00:13:22,899 routinely on a large scale. 407 00:13:22,900 --> 00:13:24,489 We have another project called the SSL 408 00:13:24,490 --> 00:13:26,649 Observatory that showed that, in fact, 409 00:13:26,650 --> 00:13:28,899 there are hundreds of entities that have 410 00:13:28,900 --> 00:13:30,639 hundreds of names, that list of entities 411 00:13:30,640 --> 00:13:32,799 that have had this power delegated to 412 00:13:32,800 --> 00:13:34,209 them by certificate authorities. 413 00:13:35,440 --> 00:13:37,599 And in fact, normally when 414 00:13:37,600 --> 00:13:39,909 you get a certificate for an identity 415 00:13:39,910 --> 00:13:42,339 for a website, it's almost always signed 416 00:13:42,340 --> 00:13:44,499 by an intermediate certificate authority, 417 00:13:44,500 --> 00:13:46,749 not directly by a root certificate. 418 00:13:46,750 --> 00:13:48,849 Authority or authority will 419 00:13:48,850 --> 00:13:50,469 be cross signed by I then trust, meaning 420 00:13:50,470 --> 00:13:52,779 that trust will delegate to us 421 00:13:52,780 --> 00:13:53,780 this 422 00:13:55,810 --> 00:13:57,759 ability to be recognized as a certificate 423 00:13:57,760 --> 00:13:59,559 authority, which means that mainstream 424 00:13:59,560 --> 00:14:00,999 browsers will trust our certificates 425 00:14:01,000 --> 00:14:02,000 immediately. 426 00:14:04,280 --> 00:14:06,529 So within the Kyuki, there 427 00:14:06,530 --> 00:14:08,089 are various forms and levels of 428 00:14:08,090 --> 00:14:10,369 validation that the certificate 429 00:14:10,370 --> 00:14:11,370 authorities perform. 430 00:14:12,690 --> 00:14:15,119 They verify or confirm 431 00:14:15,120 --> 00:14:17,249 or validate different kinds of 432 00:14:17,250 --> 00:14:19,379 information, depending on what 433 00:14:19,380 --> 00:14:20,729 information they're going to put in the 434 00:14:20,730 --> 00:14:22,829 certificate, the lowest level 435 00:14:22,830 --> 00:14:25,469 of validation is domain validation 436 00:14:25,470 --> 00:14:27,899 in domain validation, the certificate 437 00:14:27,900 --> 00:14:29,189 authority says. 438 00:14:29,190 --> 00:14:31,829 I checked that the applicant, 439 00:14:31,830 --> 00:14:33,629 the person requesting the certificate 440 00:14:33,630 --> 00:14:35,279 controls this domain name. 441 00:14:36,810 --> 00:14:38,849 And in domain validation, the authority 442 00:14:38,850 --> 00:14:41,009 explicitly does not confirm 443 00:14:41,010 --> 00:14:42,089 who the applicant is. 444 00:14:43,110 --> 00:14:45,329 They explicitly don't say 445 00:14:45,330 --> 00:14:47,189 this is such and such an organization 446 00:14:47,190 --> 00:14:49,559 based on such and such a city, 447 00:14:49,560 --> 00:14:51,269 they say we don't know, but this 448 00:14:51,270 --> 00:14:52,890 applicant controls this domain name. 449 00:14:54,000 --> 00:14:55,559 There are other forms of validation that 450 00:14:55,560 --> 00:14:58,319 certificate authorities do in the UK, 451 00:14:58,320 --> 00:15:00,419 such as organizational validation and 452 00:15:00,420 --> 00:15:02,459 extended validation, where they do, in 453 00:15:02,460 --> 00:15:05,339 fact, say, we're going to go 454 00:15:05,340 --> 00:15:07,319 find out about the human being who 455 00:15:07,320 --> 00:15:09,419 requested the cert and we're going to put 456 00:15:09,420 --> 00:15:10,919 other contact information and other 457 00:15:10,920 --> 00:15:12,130 identity information in the search. 458 00:15:13,200 --> 00:15:15,419 So an advantage of domain 459 00:15:15,420 --> 00:15:18,029 validation is that since it refers to 460 00:15:18,030 --> 00:15:20,369 confirming control to validate 461 00:15:20,370 --> 00:15:22,439 and control of the domain name, 462 00:15:22,440 --> 00:15:23,789 we believe that we can replace the 463 00:15:23,790 --> 00:15:25,829 Certificate Authority with a very small 464 00:15:25,830 --> 00:15:26,830 shell script. 465 00:15:28,360 --> 00:15:29,979 OK, so actually, the industry has a lot 466 00:15:29,980 --> 00:15:31,869 of rules, so the Shell script may not be 467 00:15:31,870 --> 00:15:34,899 that small, but 468 00:15:34,900 --> 00:15:37,209 and it may actually be written and go, 469 00:15:37,210 --> 00:15:38,210 but, 470 00:15:39,790 --> 00:15:41,889 uh, we have to comply with all of these 471 00:15:41,890 --> 00:15:42,960 industry standards, right. 472 00:15:44,140 --> 00:15:45,729 As a condition of being a certificate 473 00:15:45,730 --> 00:15:47,949 authority. We have to actually go through 474 00:15:47,950 --> 00:15:49,149 and have an audit. 475 00:15:49,150 --> 00:15:51,399 We have to show what our procedural 476 00:15:51,400 --> 00:15:52,719 controls are. We have to show what our 477 00:15:52,720 --> 00:15:53,949 technical controls are. 478 00:15:53,950 --> 00:15:55,749 We have to show what our policies are. 479 00:15:55,750 --> 00:15:57,789 And so we're developing all of these 480 00:15:57,790 --> 00:15:59,559 aspects, but. 481 00:16:00,590 --> 00:16:02,689 The point that remains is that the 482 00:16:02,690 --> 00:16:04,789 process can be fully automated 483 00:16:04,790 --> 00:16:06,769 for the most common cases, it can be 484 00:16:06,770 --> 00:16:08,239 performed by machines. 485 00:16:08,240 --> 00:16:09,679 There doesn't need to be a human being in 486 00:16:09,680 --> 00:16:11,329 the loop. And so that's what we're going 487 00:16:11,330 --> 00:16:12,330 to do. 488 00:16:13,660 --> 00:16:15,249 So just to describe a little further how 489 00:16:15,250 --> 00:16:18,339 this works, you have your client 490 00:16:18,340 --> 00:16:20,209 this is kind of confusing, like with the 491 00:16:20,210 --> 00:16:22,269 ex Windows system, the server is the 492 00:16:22,270 --> 00:16:23,259 client, right? 493 00:16:23,260 --> 00:16:26,499 OK, you have your Web server, 494 00:16:26,500 --> 00:16:29,289 which is the let's encrypt client, 495 00:16:29,290 --> 00:16:31,029 which is connecting to the CERT 496 00:16:31,030 --> 00:16:33,309 authorities server, using 497 00:16:33,310 --> 00:16:34,839 an application that we expect will be 498 00:16:34,840 --> 00:16:37,449 bundled with the server operating system 499 00:16:37,450 --> 00:16:40,029 or maybe offered by a hosting provider 500 00:16:40,030 --> 00:16:41,739 and they speak to each other, a protocol 501 00:16:41,740 --> 00:16:43,869 that we're developing called ACME, the 502 00:16:43,870 --> 00:16:45,099 Automated Certificate Management 503 00:16:45,100 --> 00:16:47,259 Environment, and they talk about 504 00:16:47,260 --> 00:16:49,119 the certificate issuance process and the 505 00:16:49,120 --> 00:16:50,390 steps that need to be performed. 506 00:16:52,510 --> 00:16:54,429 So to simplify the process a little bit, 507 00:16:54,430 --> 00:16:56,529 we can say the client says, I 508 00:16:56,530 --> 00:16:58,599 control these names and I want to search 509 00:16:58,600 --> 00:16:59,529 for them. 510 00:16:59,530 --> 00:17:01,389 And the server says, OK, in order to 511 00:17:01,390 --> 00:17:02,770 prove that you should do this. 512 00:17:03,930 --> 00:17:05,909 And the client says, all right, I've done 513 00:17:05,910 --> 00:17:08,358 so, here's the proof. 514 00:17:08,359 --> 00:17:09,979 And the server says, all right, here's 515 00:17:09,980 --> 00:17:12,108 the certificate, and 516 00:17:12,109 --> 00:17:13,578 in the coming case, it ought to be just 517 00:17:13,579 --> 00:17:14,630 about as simple as that. 518 00:17:17,160 --> 00:17:19,499 Army is Jason structured protocol 519 00:17:19,500 --> 00:17:21,179 that's being developed. 520 00:17:21,180 --> 00:17:22,858 It was primarily invented by our 521 00:17:22,859 --> 00:17:25,259 colleague Richard Barnes at Mozilla 522 00:17:25,260 --> 00:17:27,598 and it goes through each step 523 00:17:27,599 --> 00:17:29,099 in the process of issuing a search 524 00:17:29,100 --> 00:17:30,100 through DV. 525 00:17:33,020 --> 00:17:34,189 Just to talk briefly about the 526 00:17:34,190 --> 00:17:36,379 organizational aspect, we've 527 00:17:36,380 --> 00:17:38,869 incorporated, a California nonprofit 528 00:17:38,870 --> 00:17:41,119 corporation called the Internet Security 529 00:17:41,120 --> 00:17:43,189 Research Group, or ISG, which is the 530 00:17:43,190 --> 00:17:44,549 entity that will operate the Let's 531 00:17:44,550 --> 00:17:45,979 encrypt CIA. 532 00:17:45,980 --> 00:17:48,079 We're preparing for the audits and 533 00:17:48,080 --> 00:17:50,359 the other process, other 534 00:17:50,360 --> 00:17:51,859 processes that are required for the build 535 00:17:51,860 --> 00:17:52,969 out of ACA. 536 00:17:52,970 --> 00:17:55,069 And we're expecting to have the 537 00:17:55,070 --> 00:17:56,719 ability to issue certificates to the 538 00:17:56,720 --> 00:17:59,959 public around June of 2015. 539 00:17:59,960 --> 00:18:01,789 So what we have right now is a technology 540 00:18:01,790 --> 00:18:04,159 review. So you can get our code, 541 00:18:04,160 --> 00:18:05,809 you can contribute to our code, you can 542 00:18:05,810 --> 00:18:07,009 try out our code. 543 00:18:07,010 --> 00:18:08,390 But just to 544 00:18:10,100 --> 00:18:12,319 warn you, certificate's that you get 545 00:18:12,320 --> 00:18:13,939 with our code right now won't be publicly 546 00:18:13,940 --> 00:18:16,009 trusted at the present time. 547 00:18:16,010 --> 00:18:18,289 We can only issue test certificates, 548 00:18:18,290 --> 00:18:20,119 but we welcome people to experiment with 549 00:18:20,120 --> 00:18:21,319 our technology and try out our 550 00:18:21,320 --> 00:18:22,320 technology. 551 00:18:24,220 --> 00:18:25,629 I wanted to talk a little bit about this 552 00:18:25,630 --> 00:18:27,789 validation method that we've developed 553 00:18:27,790 --> 00:18:29,859 called device and I and we think that 554 00:18:29,860 --> 00:18:31,689 device, an eye is stronger in some ways 555 00:18:31,690 --> 00:18:34,179 than the mechanisms that a lot of TV guys 556 00:18:34,180 --> 00:18:35,180 are using today. 557 00:18:36,010 --> 00:18:38,199 The basic idea is that the verifier 558 00:18:38,200 --> 00:18:40,359 asks the applicant to post 559 00:18:40,360 --> 00:18:42,759 a certain self signed shirt 560 00:18:42,760 --> 00:18:44,409 containing certain information that the 561 00:18:44,410 --> 00:18:45,489 verifier provides. 562 00:18:46,930 --> 00:18:48,999 The verifier then makes an 563 00:18:49,000 --> 00:18:51,939 appeals connection to 564 00:18:51,940 --> 00:18:54,159 the server of the 565 00:18:54,160 --> 00:18:56,419 applicant and checks that 566 00:18:56,420 --> 00:18:58,269 that self censored is actually present 567 00:18:58,270 --> 00:18:59,589 and actually contains the requested 568 00:18:59,590 --> 00:19:00,819 information. 569 00:19:00,820 --> 00:19:03,669 And if you have a live 570 00:19:03,670 --> 00:19:05,859 HSDPA site, this doesn't have 571 00:19:05,860 --> 00:19:07,629 to interfere with that site. 572 00:19:07,630 --> 00:19:09,849 You don't have to replace your cert 573 00:19:09,850 --> 00:19:11,349 with the sort of the site because we're 574 00:19:11,350 --> 00:19:13,569 using the same mechanism server 575 00:19:13,570 --> 00:19:14,949 name indication. 576 00:19:14,950 --> 00:19:17,139 So when we connect, we'll ask 577 00:19:17,140 --> 00:19:19,359 about a particular invalid domain 578 00:19:19,360 --> 00:19:21,249 name. And the self-defined search should 579 00:19:21,250 --> 00:19:23,539 be served in response to that request. 580 00:19:23,540 --> 00:19:25,089 It doesn't get served in response to 581 00:19:25,090 --> 00:19:26,169 other requests. 582 00:19:26,170 --> 00:19:28,599 So, again, if you have a live site, 583 00:19:28,600 --> 00:19:30,729 we won't interfere with your live 584 00:19:30,730 --> 00:19:33,129 site. It can keep working just as normal 585 00:19:33,130 --> 00:19:34,749 while we do this verification in 586 00:19:34,750 --> 00:19:35,750 parallel. 587 00:19:36,310 --> 00:19:38,379 And the bottom line of this is 588 00:19:38,380 --> 00:19:41,329 that it proves control of the Web server. 589 00:19:41,330 --> 00:19:43,419 It proves that you have the ability 590 00:19:43,420 --> 00:19:45,159 to reconfigure the Web server that's 591 00:19:45,160 --> 00:19:47,229 listening on that domain 592 00:19:47,230 --> 00:19:49,299 to the point of posting new 593 00:19:49,300 --> 00:19:50,300 certs. 594 00:19:51,130 --> 00:19:52,479 And we think this is a very strong 595 00:19:52,480 --> 00:19:54,429 validation method and we're expecting 596 00:19:54,430 --> 00:19:56,169 this to be the primary or a primary 597 00:19:56,170 --> 00:19:57,640 method of validation. 598 00:19:59,380 --> 00:20:00,789 Again, users don't have to worry about 599 00:20:00,790 --> 00:20:02,049 that very much because we're providing 600 00:20:02,050 --> 00:20:04,689 client software that handles all of this 601 00:20:04,690 --> 00:20:06,249 and we believe that client software is 602 00:20:06,250 --> 00:20:07,689 going to be very convenient. 603 00:20:07,690 --> 00:20:09,159 And that's really an essential part of 604 00:20:09,160 --> 00:20:10,419 this vision. 605 00:20:10,420 --> 00:20:11,739 We think it's going to be 606 00:20:13,270 --> 00:20:14,859 at most this difficult 607 00:20:16,480 --> 00:20:17,480 to get your cert 608 00:20:18,610 --> 00:20:19,660 and it ought to take. 609 00:20:27,280 --> 00:20:28,899 It ought to take less than a minute to 610 00:20:28,900 --> 00:20:30,939 get the cert and install it. 611 00:20:30,940 --> 00:20:32,919 So I want to show you a video. 612 00:20:36,770 --> 00:20:38,029 I want to show you an excerpt from a 613 00:20:38,030 --> 00:20:39,739 video that was prepared by 614 00:20:41,330 --> 00:20:42,919 my colleague, James Kastin from the 615 00:20:42,920 --> 00:20:44,989 University of Michigan, who's the primary 616 00:20:44,990 --> 00:20:47,089 author of the client application, 617 00:20:49,280 --> 00:20:50,959 and I'll try to narrate it and see if I 618 00:20:50,960 --> 00:20:52,879 can keep up with what James is saying in 619 00:20:52,880 --> 00:20:54,559 the video here. 620 00:20:54,560 --> 00:20:56,390 But this is just a demo of the 621 00:20:58,250 --> 00:21:00,079 client application as it existed a little 622 00:21:00,080 --> 00:21:02,089 while ago. So the idea is you might have 623 00:21:02,090 --> 00:21:04,739 a site and the site doesn't have it. 624 00:21:04,740 --> 00:21:06,769 So when people go to that site, they get 625 00:21:06,770 --> 00:21:08,209 an error, right? 626 00:21:08,210 --> 00:21:09,749 There's an invalid cert or there's no 627 00:21:09,750 --> 00:21:11,359 cert at all. So you have this let's 628 00:21:11,360 --> 00:21:13,549 encrypt application and you say Sudo, 629 00:21:13,550 --> 00:21:15,169 let's encrypt. 630 00:21:15,170 --> 00:21:17,029 This is a warning that the search that 631 00:21:17,030 --> 00:21:19,339 you get won't be publicly trusted, OK? 632 00:21:19,340 --> 00:21:21,439 It passes your Apache configuration and 633 00:21:21,440 --> 00:21:23,599 detects which virtual host you have 634 00:21:23,600 --> 00:21:25,519 and it offers to get you certs for all of 635 00:21:25,520 --> 00:21:27,229 the virtual hosts that you have. 636 00:21:27,230 --> 00:21:28,999 And then it says, OK, I'm generating a 637 00:21:29,000 --> 00:21:31,549 key, I'm generating a certificate request 638 00:21:31,550 --> 00:21:33,529 and I'm connecting to the server. 639 00:21:33,530 --> 00:21:35,029 And actually, while I was explaining that 640 00:21:35,030 --> 00:21:37,279 it got the cert and installed it, so 641 00:21:37,280 --> 00:21:38,389 it finished. 642 00:21:44,050 --> 00:21:45,050 And it actually 643 00:21:46,690 --> 00:21:48,459 it actually reconfigured a patsy and then 644 00:21:48,460 --> 00:21:50,709 it asks whether you want to redirect 645 00:21:50,710 --> 00:21:52,899 its GDP in that Apache configuration, 646 00:21:52,900 --> 00:21:55,059 virtual host to its GDP or not. 647 00:21:57,130 --> 00:21:58,659 Now, James is going to do this again, 648 00:21:58,660 --> 00:22:00,459 showing that if you know exactly what you 649 00:22:00,460 --> 00:22:02,379 want ahead of time, there's actually a 650 00:22:02,380 --> 00:22:04,539 non interactive mode where you can just 651 00:22:04,540 --> 00:22:06,369 say exactly what you want and then you 652 00:22:06,370 --> 00:22:08,319 won't be prompted interactively. 653 00:22:08,320 --> 00:22:09,460 So he's just saying 654 00:22:11,950 --> 00:22:12,950 sorry. 655 00:22:13,870 --> 00:22:14,870 Yeah. 656 00:22:16,630 --> 00:22:19,180 So he just wants to assert. 657 00:22:20,820 --> 00:22:23,129 For encryption example, demo, 658 00:22:23,130 --> 00:22:24,629 and it generated the key, generated the 659 00:22:24,630 --> 00:22:26,909 request, configured Apache 660 00:22:26,910 --> 00:22:29,069 to answer the device and I challenge 661 00:22:29,070 --> 00:22:31,019 received the challenge, got the cert, 662 00:22:31,020 --> 00:22:33,599 deployed it and reconfigured Apache 663 00:22:33,600 --> 00:22:35,789 with a V host that redirects the 664 00:22:35,790 --> 00:22:38,159 HTP to its GDP. 665 00:22:38,160 --> 00:22:40,589 So now if he reloads the HTP, 666 00:22:40,590 --> 00:22:41,779 Apache redirects to its. 667 00:22:54,830 --> 00:22:56,959 And so all of this is reliant, of 668 00:22:56,960 --> 00:22:59,029 course, on the ability of the client to 669 00:22:59,030 --> 00:23:01,519 pass and to write to the 670 00:23:01,520 --> 00:23:03,499 Apache configuration and the 671 00:23:03,500 --> 00:23:06,199 configuration files of other Web servers. 672 00:23:06,200 --> 00:23:07,939 And that's an ongoing effort that we're 673 00:23:07,940 --> 00:23:09,919 involved with to try to make this as 674 00:23:09,920 --> 00:23:11,269 convenient as possible for people, 675 00:23:11,270 --> 00:23:12,589 regardless of what server software 676 00:23:12,590 --> 00:23:13,590 they're using. 677 00:23:14,330 --> 00:23:17,359 I'm also working on a standalone version 678 00:23:17,360 --> 00:23:19,279 which will just get the cert and save it 679 00:23:19,280 --> 00:23:20,569 into a file. 680 00:23:20,570 --> 00:23:22,759 So if you have some application, 681 00:23:22,760 --> 00:23:24,409 some server that you want to install the 682 00:23:24,410 --> 00:23:26,479 search into, that's not supported by our 683 00:23:26,480 --> 00:23:28,639 software for automatic 684 00:23:28,640 --> 00:23:30,949 configuration, you can just get the cert 685 00:23:30,950 --> 00:23:33,229 and have it in a file in your directory 686 00:23:33,230 --> 00:23:34,579 and then you can do what you want with 687 00:23:34,580 --> 00:23:35,539 it. 688 00:23:35,540 --> 00:23:37,429 So we will have a standalone mode that 689 00:23:37,430 --> 00:23:39,499 doesn't require you to let 690 00:23:39,500 --> 00:23:41,719 our software edit your Web server 691 00:23:41,720 --> 00:23:43,339 configuration live. 692 00:23:43,340 --> 00:23:45,349 But when it does edit your Web server 693 00:23:45,350 --> 00:23:47,119 configuration, it has a very careful 694 00:23:47,120 --> 00:23:49,339 configuration file backup mechanism 695 00:23:49,340 --> 00:23:51,169 and check pointing and roback mechanism. 696 00:23:52,550 --> 00:23:54,559 So it's not going to change your 697 00:23:54,560 --> 00:23:56,029 configuration file and not give you a 698 00:23:56,030 --> 00:23:57,800 copy of how it was before, you know. 699 00:24:00,020 --> 00:24:02,449 And we care a lot about the security 700 00:24:02,450 --> 00:24:04,699 of the cert system. 701 00:24:04,700 --> 00:24:06,109 In fact, a lot of people working on this 702 00:24:06,110 --> 00:24:08,029 project are people who've done previous 703 00:24:08,030 --> 00:24:10,369 research and previous analysis about 704 00:24:10,370 --> 00:24:11,899 concerns about the safety of the 705 00:24:11,900 --> 00:24:14,059 Certificate Authority system and concerns 706 00:24:14,060 --> 00:24:15,999 about the safety and security of it. 707 00:24:16,000 --> 00:24:18,469 Yes, we're very well aware 708 00:24:18,470 --> 00:24:20,149 of the risks of mis issuance. 709 00:24:20,150 --> 00:24:22,579 We're very well aware of 710 00:24:22,580 --> 00:24:24,469 the concerns that certificate authorities 711 00:24:24,470 --> 00:24:26,809 could get tricked into issuing something 712 00:24:26,810 --> 00:24:28,369 that someone could try to legally compel 713 00:24:28,370 --> 00:24:30,889 them to issue a inaccurate 714 00:24:30,890 --> 00:24:33,469 cert, that someone could try to hack them 715 00:24:33,470 --> 00:24:35,089 and steal their key. 716 00:24:37,550 --> 00:24:38,809 All of these are concerns that are 717 00:24:38,810 --> 00:24:40,459 certainly very much on our mind and we're 718 00:24:40,460 --> 00:24:42,649 not trying to minimize 719 00:24:42,650 --> 00:24:43,819 them or sweep them under the rug. 720 00:24:43,820 --> 00:24:45,019 We think that CEOs have a big 721 00:24:45,020 --> 00:24:47,059 responsibility and 722 00:24:48,230 --> 00:24:49,669 we want to be very careful with that 723 00:24:49,670 --> 00:24:51,319 responsibility. 724 00:24:51,320 --> 00:24:52,969 We think that transparency is a really 725 00:24:52,970 --> 00:24:55,519 important part of this within the context 726 00:24:55,520 --> 00:24:58,039 of the existing system. 727 00:24:58,040 --> 00:25:00,259 And so we're likely to adopt something 728 00:25:00,260 --> 00:25:01,909 along the lines of Google's CERT 729 00:25:01,910 --> 00:25:03,859 transparency system, where all of the 730 00:25:03,860 --> 00:25:05,269 certs that are ever issued by the 731 00:25:05,270 --> 00:25:07,879 authority are published publicly, 732 00:25:07,880 --> 00:25:09,529 and where we can actually say that if the 733 00:25:09,530 --> 00:25:11,089 certificate has not been published 734 00:25:11,090 --> 00:25:13,130 publicly, it should not be accepted. 735 00:25:14,600 --> 00:25:15,979 And there are other mechanisms that we're 736 00:25:15,980 --> 00:25:17,479 looking at and talking about in terms of 737 00:25:17,480 --> 00:25:19,549 transparency, in terms of being able to 738 00:25:19,550 --> 00:25:21,739 say to people, why did we issue 739 00:25:21,740 --> 00:25:23,629 that search? What sites have we issued? 740 00:25:23,630 --> 00:25:24,630 What do they say? 741 00:25:25,730 --> 00:25:27,619 Um, we're also very interested in 742 00:25:27,620 --> 00:25:29,539 exploring ways that we can decline to 743 00:25:29,540 --> 00:25:31,669 issue things that there is some 744 00:25:31,670 --> 00:25:33,019 reason to believe that we shouldn't be 745 00:25:33,020 --> 00:25:34,009 issuing. 746 00:25:34,010 --> 00:25:36,379 And so one policy that we're exploring is 747 00:25:36,380 --> 00:25:38,449 if there is a valid search 748 00:25:38,450 --> 00:25:40,849 already for a particular 749 00:25:40,850 --> 00:25:42,979 name that's still within its period 750 00:25:42,980 --> 00:25:45,199 of validity, we may say that 751 00:25:45,200 --> 00:25:47,629 we won't automatically issue 752 00:25:47,630 --> 00:25:49,819 a new search for that name 753 00:25:49,820 --> 00:25:51,589 unless the applicant can prove that they 754 00:25:51,590 --> 00:25:53,659 control the private key that's 755 00:25:53,660 --> 00:25:55,039 in the existing search. 756 00:25:55,040 --> 00:25:57,079 And so then we could say, OK, well, if 757 00:25:57,080 --> 00:25:59,149 there is some HSDPA site out there 758 00:25:59,150 --> 00:26:00,380 that's working fine right now, 759 00:26:01,790 --> 00:26:03,379 we're not just going to issue a search 760 00:26:03,380 --> 00:26:05,059 for that name to some stranger who comes 761 00:26:05,060 --> 00:26:07,099 along who doesn't control the property of 762 00:26:07,100 --> 00:26:08,779 that valid functioning HSDPA site. 763 00:26:09,830 --> 00:26:11,149 And there are other mechanisms that we 764 00:26:11,150 --> 00:26:13,489 can use where domains can say 765 00:26:13,490 --> 00:26:15,559 we don't want your to ever issue 766 00:26:15,560 --> 00:26:17,269 a search for our name and we can respect 767 00:26:17,270 --> 00:26:18,270 that request. 768 00:26:19,450 --> 00:26:21,069 So, again, we're very concerned about 769 00:26:21,070 --> 00:26:22,599 avoiding this issue and exploring 770 00:26:22,600 --> 00:26:24,609 technical means that we can use to 771 00:26:24,610 --> 00:26:26,109 mitigate the risks of mis issuance. 772 00:26:29,510 --> 00:26:31,639 We'd like to be really widely integrated 773 00:26:31,640 --> 00:26:33,199 so that this is a really routine thing 774 00:26:33,200 --> 00:26:34,639 that people can use conveniently and 775 00:26:34,640 --> 00:26:36,119 expect to have them to rely on. 776 00:26:37,850 --> 00:26:39,529 So we'd like to be in every server 777 00:26:39,530 --> 00:26:40,939 operating system. 778 00:26:40,940 --> 00:26:42,889 We'd like to be integrated with every Web 779 00:26:42,890 --> 00:26:44,329 server application. 780 00:26:44,330 --> 00:26:45,829 We'd like to be integrated with every 781 00:26:45,830 --> 00:26:47,989 hosting and application platforms. 782 00:26:47,990 --> 00:26:49,519 So we'd like to have a situation where 783 00:26:49,520 --> 00:26:51,589 when you sign up for a hosting provider, 784 00:26:51,590 --> 00:26:53,809 the hosting provider gives you a 785 00:26:53,810 --> 00:26:55,639 single click or maybe zero click 786 00:26:55,640 --> 00:26:57,829 mechanism where you'll get a 787 00:26:57,830 --> 00:26:59,720 valid search from us if you want one. 788 00:27:02,670 --> 00:27:04,739 And of course, our protocol is an open 789 00:27:04,740 --> 00:27:06,689 standard that's likely to be submitted to 790 00:27:06,690 --> 00:27:08,759 standardization at IETF and you 791 00:27:08,760 --> 00:27:10,169 can implement the protocol in your own 792 00:27:10,170 --> 00:27:12,209 software. You don't need to use our 793 00:27:12,210 --> 00:27:14,309 software to request or obtain a 794 00:27:14,310 --> 00:27:15,640 cert from RCA. 795 00:27:16,650 --> 00:27:18,899 And so if you are or work with 796 00:27:18,900 --> 00:27:21,179 a hosting provider and you don't 797 00:27:21,180 --> 00:27:22,829 like our client or it doesn't fit your 798 00:27:22,830 --> 00:27:24,449 architecture, you can write your own 799 00:27:24,450 --> 00:27:26,609 client. Right. You can do 800 00:27:26,610 --> 00:27:27,869 what you like. 801 00:27:27,870 --> 00:27:29,969 You don't need to directly coordinate 802 00:27:29,970 --> 00:27:31,439 with us. You don't need a contractual 803 00:27:31,440 --> 00:27:32,699 relationship with us. 804 00:27:32,700 --> 00:27:34,529 You can just get these certs from us by 805 00:27:34,530 --> 00:27:36,059 speaking our protocol to us. 806 00:27:36,060 --> 00:27:37,380 And we hope that people will do that. 807 00:27:38,460 --> 00:27:40,139 If you are an organization that finds 808 00:27:40,140 --> 00:27:41,669 this valuable and wants to make sure that 809 00:27:41,670 --> 00:27:43,619 it can exist, we welcome financial 810 00:27:43,620 --> 00:27:44,549 sponsorship. 811 00:27:44,550 --> 00:27:46,829 But that's absolutely not a condition 812 00:27:46,830 --> 00:27:48,659 or a requirement of integrating with us 813 00:27:48,660 --> 00:27:49,649 in any way. 814 00:27:49,650 --> 00:27:51,899 It's just something that you can do to 815 00:27:51,900 --> 00:27:53,160 support Internet security. 816 00:27:56,100 --> 00:27:58,289 So that's actually about it, I wanted to 817 00:27:58,290 --> 00:28:00,479 acknowledge these are the folks 818 00:28:00,480 --> 00:28:01,859 who've been working on the original 819 00:28:01,860 --> 00:28:04,229 technical concept with us from Mozilla, 820 00:28:04,230 --> 00:28:05,759 from EFF friend from the University of 821 00:28:05,760 --> 00:28:06,760 Michigan. 822 00:28:07,260 --> 00:28:08,579 And of course, as the project has 823 00:28:08,580 --> 00:28:10,079 developed, we now have even more 824 00:28:10,080 --> 00:28:12,179 colleagues from these organizations and 825 00:28:12,180 --> 00:28:14,399 even some volunteers from outside who 826 00:28:14,400 --> 00:28:16,019 are working on developing other aspects 827 00:28:16,020 --> 00:28:17,399 of the CIA and other aspects of the 828 00:28:17,400 --> 00:28:18,400 technology. 829 00:28:19,530 --> 00:28:21,059 So it's a great collaboration. 830 00:28:21,060 --> 00:28:23,189 You can go take a look at our 831 00:28:23,190 --> 00:28:25,319 code, help develop it, help 832 00:28:25,320 --> 00:28:27,119 test it, help critique it. 833 00:28:27,120 --> 00:28:29,369 Um, we'd be very grateful for public 834 00:28:29,370 --> 00:28:31,110 involvement. So thanks very much. 835 00:28:43,910 --> 00:28:46,249 And I think we have actually 836 00:28:46,250 --> 00:28:47,479 quite a bit of time for questions, 837 00:28:47,480 --> 00:28:48,709 because I think that was only half an 838 00:28:48,710 --> 00:28:50,329 hour, but I know people tend to have 839 00:28:50,330 --> 00:28:52,699 questions about this project, so I'm 840 00:28:52,700 --> 00:28:54,109 very happy to hear them. 841 00:28:54,110 --> 00:28:55,819 So I thought you would speak a little bit 842 00:28:55,820 --> 00:28:56,820 longer. 843 00:28:57,290 --> 00:28:58,980 Yeah, but thank you. 844 00:29:00,020 --> 00:29:02,209 And I think that actually a lot 845 00:29:02,210 --> 00:29:03,169 of questions. 846 00:29:03,170 --> 00:29:05,569 So maybe it's a good thing that you 847 00:29:05,570 --> 00:29:07,789 have left or some time for this. 848 00:29:07,790 --> 00:29:09,560 So is there a question from the Internet? 849 00:29:10,640 --> 00:29:11,869 OK, let me start with this. 850 00:29:16,990 --> 00:29:19,329 OK, first first question, does 851 00:29:19,330 --> 00:29:21,100 this only work with Apache? 852 00:29:22,510 --> 00:29:25,089 So it depends what you mean by work with 853 00:29:25,090 --> 00:29:26,090 us. 854 00:29:28,540 --> 00:29:30,609 So in terms of the ability to do what we 855 00:29:30,610 --> 00:29:32,769 see in the video where you run 856 00:29:32,770 --> 00:29:34,869 the program and it gets the cert 857 00:29:34,870 --> 00:29:36,609 and then configures the cert on your 858 00:29:36,610 --> 00:29:39,309 website automatically, 859 00:29:39,310 --> 00:29:41,649 in the current version of our software, 860 00:29:41,650 --> 00:29:43,269 Apache is the only thing that we've 861 00:29:43,270 --> 00:29:45,369 integrated with yet in 862 00:29:45,370 --> 00:29:46,479 that way. 863 00:29:46,480 --> 00:29:49,599 And so today 864 00:29:49,600 --> 00:29:51,009 you would only be able to have that 865 00:29:51,010 --> 00:29:53,349 automated experience with Apache. 866 00:29:53,350 --> 00:29:54,969 We're actively working on integrating 867 00:29:54,970 --> 00:29:57,129 with Engine X and of course, we 868 00:29:57,130 --> 00:29:59,259 want to integrate with every other Web 869 00:29:59,260 --> 00:30:01,359 server. So we welcome other people to 870 00:30:01,360 --> 00:30:03,579 help write that integration. 871 00:30:03,580 --> 00:30:05,349 There's no technical reason that it can't 872 00:30:05,350 --> 00:30:07,029 work with any and every Web server. 873 00:30:07,030 --> 00:30:08,739 It just requires us to write the code 874 00:30:08,740 --> 00:30:10,629 that deals with reconfiguring the Web 875 00:30:10,630 --> 00:30:12,099 server in an appropriate way. 876 00:30:12,100 --> 00:30:13,689 And that code, unfortunately, will be 877 00:30:13,690 --> 00:30:15,639 different for each and every Web server 878 00:30:15,640 --> 00:30:16,640 application. 879 00:30:17,350 --> 00:30:19,659 OK, before we go further, 880 00:30:19,660 --> 00:30:22,059 I see that we are sitting right 881 00:30:22,060 --> 00:30:23,919 at the moment, but we have learned that 882 00:30:23,920 --> 00:30:26,559 people try to stand up and go out 883 00:30:26,560 --> 00:30:27,819 to the kitchen. 884 00:30:27,820 --> 00:30:29,909 If you need to do so, please be quiet 885 00:30:29,910 --> 00:30:31,639 and don't speak. And we will continue 886 00:30:31,640 --> 00:30:32,649 with succession. 887 00:30:32,650 --> 00:30:35,229 I think I start with 888 00:30:35,230 --> 00:30:36,579 I don't know who was first. 889 00:30:36,580 --> 00:30:38,299 I think I go one. 890 00:30:40,120 --> 00:30:40,919 Yeah, that's you. 891 00:30:40,920 --> 00:30:43,089 Yeah. OK, there are several 892 00:30:43,090 --> 00:30:44,269 questions. 893 00:30:44,270 --> 00:30:46,479 The first one, is there a possibility 894 00:30:46,480 --> 00:30:49,179 to revoke a certificate and 895 00:30:49,180 --> 00:30:51,369 what bring all the other commercial 896 00:30:51,370 --> 00:30:52,930 theories about your work 897 00:30:54,130 --> 00:30:55,130 on. 898 00:31:00,190 --> 00:31:02,169 I'm actually sorry that I cut off the 899 00:31:02,170 --> 00:31:04,389 demo video so quickly, maybe 900 00:31:04,390 --> 00:31:06,099 I'll put that back on while talking about 901 00:31:06,100 --> 00:31:07,599 this, because the next thing that happens 902 00:31:07,600 --> 00:31:10,009 in the demo video is let's encrypt 903 00:31:10,010 --> 00:31:11,449 dash revoke. 904 00:31:11,450 --> 00:31:13,329 And it demonstrates revocation, which has 905 00:31:13,330 --> 00:31:14,679 actually already been implemented. 906 00:31:15,730 --> 00:31:17,709 Revocation is actually just about as 907 00:31:17,710 --> 00:31:19,149 quick as issuance. 908 00:31:19,150 --> 00:31:20,829 In fact, it may be faster because you 909 00:31:20,830 --> 00:31:23,129 don't have to test, 910 00:31:23,130 --> 00:31:25,239 uh, you just have to prove 911 00:31:25,240 --> 00:31:27,699 cryptographic control of the name of the 912 00:31:27,700 --> 00:31:29,829 subject's key and then you can 913 00:31:29,830 --> 00:31:31,929 revoke. So, yes, revocation is already 914 00:31:31,930 --> 00:31:33,969 implemented and is, of course, a very 915 00:31:33,970 --> 00:31:35,979 important part of the public key 916 00:31:35,980 --> 00:31:36,980 infrastructure. 917 00:31:42,700 --> 00:31:44,049 And I don't think that we've heard 918 00:31:44,050 --> 00:31:46,629 directly from any of the other case, 919 00:31:46,630 --> 00:31:48,069 I saw that one person from one of the 920 00:31:48,070 --> 00:31:50,019 other CEOs posted on a public mailing 921 00:31:50,020 --> 00:31:51,939 list when this was first announced, 922 00:31:51,940 --> 00:31:54,039 something like, um, well, I 923 00:31:54,040 --> 00:31:55,359 assume they're going to comply with all 924 00:31:55,360 --> 00:31:57,009 the industry rules. Right. 925 00:31:57,010 --> 00:31:58,959 Um, and so far, that's the only comment 926 00:31:58,960 --> 00:32:00,219 that I've heard from others. 927 00:32:00,220 --> 00:32:01,220 Yes. 928 00:32:01,660 --> 00:32:03,969 OK, well then I think to. 929 00:32:05,130 --> 00:32:06,959 Thanks. Great stuff, I really look 930 00:32:06,960 --> 00:32:08,699 forward to this ruling. 931 00:32:08,700 --> 00:32:10,829 What are the rules of 932 00:32:10,830 --> 00:32:13,289 the other partners, Akamai 933 00:32:13,290 --> 00:32:15,089 and Cisco, in this work? 934 00:32:17,650 --> 00:32:19,179 I think that their main role at the 935 00:32:19,180 --> 00:32:21,099 outset is providing financial sponsorship 936 00:32:21,100 --> 00:32:22,440 because they think this is important. 937 00:32:23,760 --> 00:32:25,259 I'm hoping that they'll find it 938 00:32:25,260 --> 00:32:27,689 technically useful as a thing 939 00:32:27,690 --> 00:32:29,819 that will help their customers, but 940 00:32:29,820 --> 00:32:32,069 their initial role is just allowing 941 00:32:32,070 --> 00:32:33,659 it to happen financially. 942 00:32:33,660 --> 00:32:35,459 Great. More people should do that 943 00:32:37,320 --> 00:32:38,460 than the fall. 944 00:32:40,070 --> 00:32:42,359 Um, can I issue a certificate 945 00:32:42,360 --> 00:32:44,489 that's only valid for a few days so I 946 00:32:44,490 --> 00:32:46,939 could forego the entire vacation mess 947 00:32:46,940 --> 00:32:47,940 and 948 00:32:49,080 --> 00:32:51,209 do it that way and issue 949 00:32:51,210 --> 00:32:53,609 new certificate every few days? 950 00:32:53,610 --> 00:32:55,079 So we have a lot of interest in the 951 00:32:55,080 --> 00:32:57,089 proposals for so-called short lived 952 00:32:57,090 --> 00:32:58,979 certificates, where 953 00:33:00,270 --> 00:33:01,859 some people view that as an alternative 954 00:33:01,860 --> 00:33:03,149 to XP. 955 00:33:03,150 --> 00:33:04,409 And I'm sorry to throw out another 956 00:33:04,410 --> 00:33:06,659 acronym that's not in the chart, 957 00:33:06,660 --> 00:33:08,969 but there 958 00:33:08,970 --> 00:33:11,009 is a lot of difficulty about how in 959 00:33:11,010 --> 00:33:13,319 practice browsers should check 960 00:33:13,320 --> 00:33:14,909 whether certificates that have been 961 00:33:14,910 --> 00:33:17,009 issued are still valid 962 00:33:17,010 --> 00:33:18,989 and a mechanism was created for that. 963 00:33:18,990 --> 00:33:20,699 That doesn't work very well. 964 00:33:20,700 --> 00:33:24,059 Um, is that an attacker can 965 00:33:24,060 --> 00:33:26,489 defeat, uh, 966 00:33:26,490 --> 00:33:28,649 and so an alternative might be issuing 967 00:33:28,650 --> 00:33:29,999 certificates that have a very short 968 00:33:30,000 --> 00:33:32,129 period of validity and that 969 00:33:32,130 --> 00:33:34,379 might be much more convenient, 970 00:33:34,380 --> 00:33:36,479 relatively with our technology, 971 00:33:36,480 --> 00:33:38,549 because we have the ability to 972 00:33:38,550 --> 00:33:41,249 install the new certificate 973 00:33:41,250 --> 00:33:43,169 into the configuration on a regular 974 00:33:43,170 --> 00:33:45,989 basis. We would have the ability to 975 00:33:45,990 --> 00:33:48,179 provide automated renewal and automated 976 00:33:48,180 --> 00:33:50,309 installation and updating of the 977 00:33:50,310 --> 00:33:51,749 certificate. So I think that's something 978 00:33:51,750 --> 00:33:53,640 that could be achieved more easily. 979 00:33:54,690 --> 00:33:56,699 We have not finished making policy 980 00:33:56,700 --> 00:33:58,799 decisions about how 981 00:33:58,800 --> 00:34:00,449 or whether short lived certificates will 982 00:34:00,450 --> 00:34:01,739 be used in our system. 983 00:34:01,740 --> 00:34:04,049 So I can't actually answer the question 984 00:34:04,050 --> 00:34:05,609 except to say it's something that we find 985 00:34:05,610 --> 00:34:06,610 quite interesting. 986 00:34:07,660 --> 00:34:09,059 And then there's another question from 987 00:34:09,060 --> 00:34:10,649 the Internet. Yeah. 988 00:34:10,650 --> 00:34:12,749 Is there a plan to address uses for 989 00:34:12,750 --> 00:34:14,819 certificates other than titles 990 00:34:14,820 --> 00:34:17,039 such as SS Age certificates 991 00:34:17,040 --> 00:34:19,109 to enable peak usage with 992 00:34:19,110 --> 00:34:20,110 S.H.? 993 00:34:22,139 --> 00:34:23,789 I don't think that we'll be able to do 994 00:34:23,790 --> 00:34:26,579 that before we address the primary 995 00:34:26,580 --> 00:34:29,158 case with the webpage. 996 00:34:29,159 --> 00:34:31,769 I, I think that 997 00:34:31,770 --> 00:34:33,959 if this model proves to work 998 00:34:33,960 --> 00:34:36,299 well, as we think it will, then 999 00:34:36,300 --> 00:34:37,979 I Asaji would be very interested in 1000 00:34:37,980 --> 00:34:39,178 figuring out whether there are other 1001 00:34:39,179 --> 00:34:41,069 parts of cryptographic infrastructure 1002 00:34:41,070 --> 00:34:42,689 that we can help provide for the 1003 00:34:42,690 --> 00:34:43,979 Internet. 1004 00:34:43,980 --> 00:34:46,198 I think this case is going to be our 1005 00:34:46,199 --> 00:34:48,599 first test case and 1006 00:34:48,600 --> 00:34:49,600 this is where we're starting. 1007 00:34:51,199 --> 00:34:52,760 When we go to the three, 1008 00:34:54,679 --> 00:34:57,739 not sure if you know that currently 1009 00:34:57,740 --> 00:35:00,139 World Wide Web consortium, technical 1010 00:35:00,140 --> 00:35:02,449 architecture group, so the 1011 00:35:02,450 --> 00:35:04,579 tax preparers publishing the 1012 00:35:04,580 --> 00:35:06,949 finding about ETPs recommending 1013 00:35:06,950 --> 00:35:09,439 it, do you find it useful to document 1014 00:35:09,440 --> 00:35:11,089 it? And if there's already some 1015 00:35:11,090 --> 00:35:12,919 collaboration about what to include in 1016 00:35:12,920 --> 00:35:13,920 such note? 1017 00:35:14,810 --> 00:35:17,329 We're really grateful to the TFG 1018 00:35:17,330 --> 00:35:19,459 for making that recommendation. 1019 00:35:19,460 --> 00:35:22,129 We think they are totally correct and 1020 00:35:22,130 --> 00:35:24,259 very timely and 1021 00:35:24,260 --> 00:35:25,489 not sure what else to say. 1022 00:35:25,490 --> 00:35:27,409 But I appreciate that they said what they 1023 00:35:27,410 --> 00:35:29,029 said. And I appreciate that a lot of 1024 00:35:29,030 --> 00:35:30,229 people in the Internet standards 1025 00:35:30,230 --> 00:35:32,449 community are really starting to 1026 00:35:32,450 --> 00:35:34,639 say that cryptography is 1027 00:35:34,640 --> 00:35:36,739 a fundamental, essential part of Internet 1028 00:35:36,740 --> 00:35:39,139 standards and technology standards. 1029 00:35:39,140 --> 00:35:40,939 And it's not that you design something 1030 00:35:40,940 --> 00:35:42,439 and then you make the optional crypto 1031 00:35:42,440 --> 00:35:45,019 version. A few years later, 1032 00:35:45,020 --> 00:35:46,969 the crypto and the privacy features and 1033 00:35:46,970 --> 00:35:49,129 the security features should be a part 1034 00:35:49,130 --> 00:35:50,539 of the network protocols and the 1035 00:35:50,540 --> 00:35:51,829 communications protocols from the 1036 00:35:51,830 --> 00:35:52,999 beginning. 1037 00:35:53,000 --> 00:35:54,000 Yeah. 1038 00:35:56,750 --> 00:35:58,459 I think people here agree to this, 1039 00:35:59,960 --> 00:36:02,269 OK, then I think the six. 1040 00:36:03,700 --> 00:36:05,919 First, thanks again for the project 1041 00:36:05,920 --> 00:36:07,319 I'm really happy about. 1042 00:36:07,320 --> 00:36:09,689 So with this first word and also 1043 00:36:09,690 --> 00:36:11,789 support certificates for non 1044 00:36:11,790 --> 00:36:14,069 web like EXPE, 1045 00:36:14,070 --> 00:36:16,859 SMTP or whatever. 1046 00:36:16,860 --> 00:36:18,539 Yeah, so we've had some discussions about 1047 00:36:18,540 --> 00:36:19,119 that. 1048 00:36:19,120 --> 00:36:21,269 Um, it appears that 1049 00:36:21,270 --> 00:36:23,910 right now in most 1050 00:36:25,140 --> 00:36:27,479 Tillawi implementations, the same 1051 00:36:27,480 --> 00:36:29,669 certificate will be accepted 1052 00:36:29,670 --> 00:36:31,169 for any application. 1053 00:36:31,170 --> 00:36:33,539 In other words, the subject 1054 00:36:33,540 --> 00:36:35,429 entity is just a common name for the 1055 00:36:35,430 --> 00:36:38,159 domain name and is not explicitly 1056 00:36:38,160 --> 00:36:40,439 bound to a specific protocol or limited 1057 00:36:40,440 --> 00:36:42,509 to a specific protocol. 1058 00:36:42,510 --> 00:36:44,639 Maybe it should be according 1059 00:36:44,640 --> 00:36:46,739 to some security arguments, but it's not. 1060 00:36:46,740 --> 00:36:48,389 And so you have the ability to take a 1061 00:36:48,390 --> 00:36:50,669 certificate that was issued for 1062 00:36:50,670 --> 00:36:52,799 a Web server in some sense, if you 1063 00:36:52,800 --> 00:36:54,419 want to think of it that way and use it 1064 00:36:54,420 --> 00:36:56,429 for an exemption for use it for a mail 1065 00:36:56,430 --> 00:36:57,449 server. 1066 00:36:57,450 --> 00:36:59,759 And we expect that people 1067 00:36:59,760 --> 00:37:01,919 will be able to do that. 1068 00:37:01,920 --> 00:37:04,079 If someone wants to write a 1069 00:37:04,080 --> 00:37:06,479 patch that actually installs 1070 00:37:06,480 --> 00:37:08,459 it in other servers that you have on your 1071 00:37:08,460 --> 00:37:10,319 system, that would be useful 1072 00:37:10,320 --> 00:37:11,320 functionality. 1073 00:37:12,660 --> 00:37:14,759 I think a common case for people who 1074 00:37:14,760 --> 00:37:17,159 only run something like an exemplar 1075 00:37:17,160 --> 00:37:18,779 server is that they would run the 1076 00:37:18,780 --> 00:37:20,969 standalone client, which would 1077 00:37:20,970 --> 00:37:23,069 temporarily start a 1078 00:37:23,070 --> 00:37:23,969 listening process. 1079 00:37:23,970 --> 00:37:26,039 Listening on Port 443, 1080 00:37:26,040 --> 00:37:28,199 the CIA would perform the validation 1081 00:37:28,200 --> 00:37:30,689 with Port 443 and issue the CERT 1082 00:37:30,690 --> 00:37:32,039 and then the cert would be saved as a 1083 00:37:32,040 --> 00:37:33,749 file, which the system administrator 1084 00:37:33,750 --> 00:37:36,689 could then install in another service. 1085 00:37:36,690 --> 00:37:38,189 But again, if people want to help make 1086 00:37:38,190 --> 00:37:40,049 that process more automated, we'd love to 1087 00:37:40,050 --> 00:37:41,050 have that help. 1088 00:37:41,820 --> 00:37:43,899 OK, then the five. 1089 00:37:43,900 --> 00:37:45,630 OK, thanks for the talk. 1090 00:37:46,740 --> 00:37:49,139 Do you plan to support wild 1091 00:37:49,140 --> 00:37:51,299 card and multi domain name 1092 00:37:51,300 --> 00:37:52,319 certificates? 1093 00:37:53,610 --> 00:37:55,019 So for multi domain name. 1094 00:37:55,020 --> 00:37:57,059 Yes, we support that right now 1095 00:37:58,170 --> 00:37:59,669 and it works great. 1096 00:37:59,670 --> 00:38:01,439 You just request all the names that you 1097 00:38:01,440 --> 00:38:03,659 want in the server and it validates 1098 00:38:03,660 --> 00:38:05,789 all of them. And we actually have some 1099 00:38:05,790 --> 00:38:06,900 additional features. 1100 00:38:08,520 --> 00:38:10,919 For people who expect to have to 1101 00:38:10,920 --> 00:38:13,079 reissue the search with more names 1102 00:38:13,080 --> 00:38:15,209 or fewer names in the future, there's 1103 00:38:15,210 --> 00:38:17,309 a technical way to avoid repeating 1104 00:38:17,310 --> 00:38:19,559 the validation for each name, every time 1105 00:38:19,560 --> 00:38:21,479 you make changes to the search. 1106 00:38:21,480 --> 00:38:23,879 Wild cards are a more difficult case. 1107 00:38:23,880 --> 00:38:25,230 We don't really know 1108 00:38:26,250 --> 00:38:28,469 how to use the validation mechanisms 1109 00:38:28,470 --> 00:38:29,470 that we have now 1110 00:38:30,870 --> 00:38:32,549 to perform a validation that would be 1111 00:38:32,550 --> 00:38:34,799 meaningful and appropriate for issuing 1112 00:38:34,800 --> 00:38:36,359 a wild card cert. 1113 00:38:36,360 --> 00:38:37,829 It's a question that's come up quite a 1114 00:38:37,830 --> 00:38:40,019 bit, and 1115 00:38:40,020 --> 00:38:42,389 I think that the answer is right 1116 00:38:42,390 --> 00:38:44,429 now we don't know how to do it. 1117 00:38:44,430 --> 00:38:46,229 And so right now we are not going to do 1118 00:38:46,230 --> 00:38:48,239 it. And if someone wants to propose a 1119 00:38:48,240 --> 00:38:50,399 mechanism through which we 1120 00:38:50,400 --> 00:38:53,159 could safely issue wild card certs, 1121 00:38:53,160 --> 00:38:54,749 our board of directors would be willing 1122 00:38:54,750 --> 00:38:56,399 to consider that mechanism. 1123 00:38:56,400 --> 00:38:57,929 One thing that one person said at a prior 1124 00:38:57,930 --> 00:39:00,239 talk about that is that if 1125 00:39:00,240 --> 00:39:02,609 we can reissue a certain automatically 1126 00:39:02,610 --> 00:39:04,709 in less than one minute 1127 00:39:04,710 --> 00:39:06,599 with a different selection of names, 1128 00:39:06,600 --> 00:39:08,669 perhaps the argument or the necessity for 1129 00:39:08,670 --> 00:39:10,739 wild card service decreases. 1130 00:39:10,740 --> 00:39:12,689 If you say, oh, I have a new virtual 1131 00:39:12,690 --> 00:39:13,619 host. Well, that's all right. 1132 00:39:13,620 --> 00:39:15,509 I'll just take 30 seconds and add that to 1133 00:39:15,510 --> 00:39:16,510 my cert. 1134 00:39:17,690 --> 00:39:19,370 OK, then the question from the Internet. 1135 00:39:20,450 --> 00:39:22,609 Are you aware that Tara Rescorla 1136 00:39:22,610 --> 00:39:25,069 coauthored a standard that contained and 1137 00:39:25,070 --> 00:39:26,070 a back door? 1138 00:39:30,830 --> 00:39:32,899 So I'm definitely aware of that report, 1139 00:39:32,900 --> 00:39:35,209 and I don't 1140 00:39:35,210 --> 00:39:37,579 know a lot about the details 1141 00:39:37,580 --> 00:39:39,919 of that, but Eric is 1142 00:39:39,920 --> 00:39:41,479 a very active person. 1143 00:39:41,480 --> 00:39:43,219 So the reason that someone is asking me 1144 00:39:43,220 --> 00:39:45,379 about this is probably that Eric 1145 00:39:45,380 --> 00:39:46,939 is someone, I think, on this slide, who's 1146 00:39:46,940 --> 00:39:48,049 one of our colleagues who's working 1147 00:39:48,050 --> 00:39:49,789 directly on this project with us. 1148 00:39:49,790 --> 00:39:52,189 And Eric is someone who's very active in 1149 00:39:52,190 --> 00:39:54,529 Internet standards, is the editor 1150 00:39:54,530 --> 00:39:56,539 of The Standard and the chair of the Task 1151 00:39:56,540 --> 00:39:58,489 Working Group, and has a lot of 1152 00:39:58,490 --> 00:39:59,660 experience with 1153 00:40:00,830 --> 00:40:02,840 all areas of Internet standardization. 1154 00:40:03,860 --> 00:40:05,479 So I don't know the circumstances 1155 00:40:05,480 --> 00:40:07,609 surrounding that incident, but 1156 00:40:07,610 --> 00:40:09,859 my impression is that Eric was 1157 00:40:09,860 --> 00:40:11,989 asked to edit that document as a result 1158 00:40:11,990 --> 00:40:13,939 of his role as the chair of the Task 1159 00:40:13,940 --> 00:40:16,789 Working Group, and not because he 1160 00:40:16,790 --> 00:40:18,739 thought that that technology was a 1161 00:40:18,740 --> 00:40:20,899 technology that he personally recommended 1162 00:40:20,900 --> 00:40:23,269 that everyone use as 1163 00:40:23,270 --> 00:40:25,279 much as other people working in Internet 1164 00:40:25,280 --> 00:40:26,839 standardization have ended up with their 1165 00:40:26,840 --> 00:40:28,969 names as editors of a lot of things 1166 00:40:28,970 --> 00:40:31,399 like John Postell, who didn't personally 1167 00:40:31,400 --> 00:40:33,529 invent each and every standard but was 1168 00:40:33,530 --> 00:40:35,809 called upon to edit them and to issue 1169 00:40:35,810 --> 00:40:36,810 them. 1170 00:40:37,490 --> 00:40:38,629 Then the phone. 1171 00:40:40,830 --> 00:40:43,169 How does your effort relate 1172 00:40:43,170 --> 00:40:45,239 to using certificates from 1173 00:40:45,240 --> 00:40:47,339 DNS, as in DAINE, and what do 1174 00:40:47,340 --> 00:40:48,359 you think about that? 1175 00:40:48,360 --> 00:40:50,879 Is that something that might come 1176 00:40:50,880 --> 00:40:53,639 into play in a couple of years? 1177 00:40:53,640 --> 00:40:55,769 Maybe so. 1178 00:40:55,770 --> 00:40:57,179 A lot of people have been interested in 1179 00:40:57,180 --> 00:40:58,800 putting cryptographic using DNS 1180 00:40:59,820 --> 00:41:01,289 and there are a lot of mechanisms for 1181 00:41:01,290 --> 00:41:02,290 that. 1182 00:41:03,250 --> 00:41:04,539 There are different schools of thought 1183 00:41:04,540 --> 00:41:06,639 about whether it would make sense 1184 00:41:06,640 --> 00:41:07,900 to replace 1185 00:41:09,040 --> 00:41:11,379 certificate authority issuance 1186 00:41:11,380 --> 00:41:12,380 with. 1187 00:41:13,350 --> 00:41:16,679 Intense SEC delivered keys 1188 00:41:16,680 --> 00:41:19,110 or, um, 1189 00:41:20,280 --> 00:41:22,859 whether you would use it 1190 00:41:22,860 --> 00:41:24,030 sort of to limit 1191 00:41:25,590 --> 00:41:27,389 whether you use it as an alternative or 1192 00:41:27,390 --> 00:41:28,619 whether you use it as an additional 1193 00:41:28,620 --> 00:41:31,109 mechanism to confirm the information 1194 00:41:31,110 --> 00:41:32,089 in the search. 1195 00:41:32,090 --> 00:41:33,090 Um. 1196 00:41:34,470 --> 00:41:35,999 I mean, I guess the answer is that we 1197 00:41:36,000 --> 00:41:37,949 don't have a specific technical plan 1198 00:41:37,950 --> 00:41:40,169 about how that relates to our work, 1199 00:41:40,170 --> 00:41:41,699 and it's obviously an important 1200 00:41:41,700 --> 00:41:42,929 development. 1201 00:41:42,930 --> 00:41:45,239 Certainly if there are defense 1202 00:41:45,240 --> 00:41:48,359 mechanisms that are relevant to 1203 00:41:48,360 --> 00:41:50,549 issuance decisions, then we ought 1204 00:41:50,550 --> 00:41:51,869 to know about them and we ought to take 1205 00:41:51,870 --> 00:41:52,870 account of them, as I say. 1206 00:41:54,950 --> 00:41:57,259 Then the question from to so 1207 00:41:57,260 --> 00:41:59,030 thank you for this work, I really like it 1208 00:42:00,500 --> 00:42:02,329 fully automated systems have a tendency 1209 00:42:02,330 --> 00:42:04,429 to feel badly and 1210 00:42:04,430 --> 00:42:06,559 well. You've taken out two of the 1211 00:42:06,560 --> 00:42:08,729 non automated parts of CERT issuance. 1212 00:42:08,730 --> 00:42:10,519 So the human interaction and the 1213 00:42:10,520 --> 00:42:12,619 financial commitment, do 1214 00:42:12,620 --> 00:42:14,599 you feel confident that you've prevented 1215 00:42:14,600 --> 00:42:15,619 any bad failures? 1216 00:42:17,160 --> 00:42:19,349 So I think different people envision 1217 00:42:19,350 --> 00:42:21,719 different failure modes, 1218 00:42:21,720 --> 00:42:23,309 I mean, some people envision a failure 1219 00:42:23,310 --> 00:42:25,829 mode like a private key compromise 1220 00:42:25,830 --> 00:42:27,959 of the CIA and then some 1221 00:42:27,960 --> 00:42:29,909 people envision that failure mode, like 1222 00:42:29,910 --> 00:42:33,149 someone succeeds in obtaining issuance. 1223 00:42:33,150 --> 00:42:35,369 Um, I think 1224 00:42:35,370 --> 00:42:38,519 that existing DVE 1225 00:42:38,520 --> 00:42:40,589 series run the risk 1226 00:42:40,590 --> 00:42:42,509 of mis issuance if someone is able to 1227 00:42:42,510 --> 00:42:43,510 compromise 1228 00:42:45,000 --> 00:42:46,000 the site. 1229 00:42:46,950 --> 00:42:48,479 Because someone who's able to compromise 1230 00:42:48,480 --> 00:42:50,759 a seat can perform the D.V. 1231 00:42:50,760 --> 00:42:52,889 verification steps as if that 1232 00:42:52,890 --> 00:42:54,719 person were the legitimate operator of 1233 00:42:54,720 --> 00:42:55,889 the site. 1234 00:42:55,890 --> 00:42:58,619 And so there is a risk of mis issuance 1235 00:42:58,620 --> 00:43:00,909 there even today, right? 1236 00:43:03,810 --> 00:43:05,969 I think that we are confident that. 1237 00:43:07,170 --> 00:43:09,269 We won't make that kind of risk 1238 00:43:09,270 --> 00:43:11,669 systematically worse, the CIA system 1239 00:43:11,670 --> 00:43:13,679 always has the weakest link issue. 1240 00:43:13,680 --> 00:43:15,479 If you can compromise any CIA, you can 1241 00:43:15,480 --> 00:43:17,699 get that CIA to miss issue for any 1242 00:43:17,700 --> 00:43:19,979 name, even if it's entities 1243 00:43:19,980 --> 00:43:21,239 that have had no prior relationship 1244 00:43:21,240 --> 00:43:23,429 whatsoever, as in the Senate, 1245 00:43:23,430 --> 00:43:24,649 are compromised. 1246 00:43:24,650 --> 00:43:26,639 For example, there was no prior 1247 00:43:26,640 --> 00:43:27,989 relationship with Google, but they were 1248 00:43:27,990 --> 00:43:29,120 able to issue for Google. 1249 00:43:30,780 --> 00:43:32,129 So there's this really fundamental 1250 00:43:32,130 --> 00:43:33,130 weakest link issue. 1251 00:43:34,010 --> 00:43:35,819 So I think what we can say is that with 1252 00:43:35,820 --> 00:43:37,289 respect to the revalidation, 1253 00:43:38,310 --> 00:43:40,169 we don't think that there is a way in 1254 00:43:40,170 --> 00:43:42,509 which our design makes things any worse. 1255 00:43:42,510 --> 00:43:44,039 We think that our validation and our 1256 00:43:44,040 --> 00:43:46,139 transparency is stronger than 1257 00:43:46,140 --> 00:43:47,210 existing Devco. 1258 00:43:48,880 --> 00:43:50,019 Then from the fall, 1259 00:43:51,280 --> 00:43:53,709 you're already removing the hazards 1260 00:43:53,710 --> 00:43:55,869 for getting the cert and deploying it 1261 00:43:55,870 --> 00:43:56,589 and so on. 1262 00:43:56,590 --> 00:43:58,359 And would you please also remove the 1263 00:43:58,360 --> 00:44:00,759 hazards for creating the debris records 1264 00:44:00,760 --> 00:44:03,109 and maybe automatically of 1265 00:44:03,110 --> 00:44:05,499 some flag, just create the 1266 00:44:05,500 --> 00:44:08,289 record, which somebody can copy to his 1267 00:44:08,290 --> 00:44:09,999 name server configuration? 1268 00:44:10,000 --> 00:44:11,979 I think that would be very valuable. 1269 00:44:11,980 --> 00:44:14,109 Um, it's 1270 00:44:14,110 --> 00:44:16,209 often not the same server, 1271 00:44:16,210 --> 00:44:17,949 the like the Web server and the DNS 1272 00:44:17,950 --> 00:44:20,289 server. And so the 1273 00:44:20,290 --> 00:44:21,819 I guess you're just suggesting creating 1274 00:44:21,820 --> 00:44:23,829 the configuration that someone might then 1275 00:44:23,830 --> 00:44:26,859 import to another machine. 1276 00:44:26,860 --> 00:44:29,049 So I think that would be great and I 1277 00:44:29,050 --> 00:44:30,699 would welcome someone writing a patch for 1278 00:44:30,700 --> 00:44:31,700 that. 1279 00:44:33,100 --> 00:44:34,960 Then again, from the Internet, 1280 00:44:37,810 --> 00:44:39,489 is there a limit of requested sign 1281 00:44:39,490 --> 00:44:40,989 certificates per domain 1282 00:44:42,040 --> 00:44:42,789 or limit? 1283 00:44:42,790 --> 00:44:44,619 What's that a limit of? 1284 00:44:45,810 --> 00:44:47,969 Requested sign certificates per 1285 00:44:47,970 --> 00:44:48,970 domain. 1286 00:44:49,850 --> 00:44:51,769 Well, I don't know if you can ask for 1287 00:44:51,770 --> 00:44:53,749 clarification back to the person or not, 1288 00:44:53,750 --> 00:44:56,779 but is the question like 1289 00:44:56,780 --> 00:44:59,119 how many times you can 1290 00:44:59,120 --> 00:45:01,609 ask for a new certificate related 1291 00:45:01,610 --> 00:45:03,649 to a particular domain or 1292 00:45:04,760 --> 00:45:05,760 in a time frame? 1293 00:45:08,600 --> 00:45:09,600 So. 1294 00:45:10,770 --> 00:45:12,539 I don't think that we have any policy 1295 00:45:12,540 --> 00:45:13,640 developed about that right now. 1296 00:45:15,190 --> 00:45:16,270 Then the six. 1297 00:45:17,710 --> 00:45:19,510 Do you think that the CIA 1298 00:45:21,250 --> 00:45:23,619 did you think that Sharat horses were 1299 00:45:23,620 --> 00:45:25,689 trying to idea of Africa and 1300 00:45:25,690 --> 00:45:28,089 gift certificates 1301 00:45:28,090 --> 00:45:29,860 for free to their users or. 1302 00:45:31,120 --> 00:45:32,799 Sorry, I didn't understand the beginning 1303 00:45:32,800 --> 00:45:34,989 of the question that who would 1304 00:45:34,990 --> 00:45:37,059 do that share horses like one 1305 00:45:37,060 --> 00:45:38,409 and one are? 1306 00:45:38,410 --> 00:45:40,389 Oh, they shared hosting providers. 1307 00:45:40,390 --> 00:45:41,739 Yes, yes. 1308 00:45:43,000 --> 00:45:44,739 We would definitely really like that. 1309 00:45:44,740 --> 00:45:46,929 And we would consider it a very 1310 00:45:46,930 --> 00:45:49,329 appropriate and desirable 1311 00:45:49,330 --> 00:45:51,729 use of our services if those companies 1312 00:45:51,730 --> 00:45:53,499 would integrate with us. 1313 00:45:53,500 --> 00:45:55,119 And we would love to have conversations 1314 00:45:55,120 --> 00:45:57,939 with any and all of them or 1315 00:45:57,940 --> 00:46:00,729 second best. We'd love to be surprised 1316 00:46:00,730 --> 00:46:02,829 that when we launch, all of them 1317 00:46:02,830 --> 00:46:04,419 have actually already written it and it 1318 00:46:04,420 --> 00:46:05,949 already works. 1319 00:46:05,950 --> 00:46:07,989 So the first best case is that they tell 1320 00:46:07,990 --> 00:46:10,299 us the second 1321 00:46:10,300 --> 00:46:11,949 best case is that we launch and then we 1322 00:46:11,950 --> 00:46:13,599 find out that people go and get a shared 1323 00:46:13,600 --> 00:46:15,699 hosting account and they got 1324 00:46:15,700 --> 00:46:17,049 a certain from Let's encrypt, looks like 1325 00:46:17,050 --> 00:46:18,050 someone integrated. 1326 00:46:19,180 --> 00:46:21,579 So I see that you're wondering 1327 00:46:21,580 --> 00:46:23,529 what we have to wait. 1328 00:46:23,530 --> 00:46:25,269 Um, OK. 1329 00:46:25,270 --> 00:46:26,270 It's a six. 1330 00:46:31,520 --> 00:46:34,369 OK, then the five things, 1331 00:46:34,370 --> 00:46:36,529 first of all, yes, you can use 1332 00:46:36,530 --> 00:46:38,599 Web services certificates for mail 1333 00:46:38,600 --> 00:46:40,879 service. I'm doing that with DOT SSL 1334 00:46:40,880 --> 00:46:42,049 certificates. 1335 00:46:42,050 --> 00:46:45,379 And then my first question is, 1336 00:46:45,380 --> 00:46:48,109 how does the long run finances 1337 00:46:48,110 --> 00:46:49,759 look like? 1338 00:46:49,760 --> 00:46:51,949 For example, when are you going to accept 1339 00:46:51,950 --> 00:46:53,030 private donations? 1340 00:46:54,470 --> 00:46:56,629 And the second question is, will 1341 00:46:56,630 --> 00:46:57,979 you document and publish the 1342 00:46:57,980 --> 00:46:59,469 infrastructure this year? 1343 00:47:02,990 --> 00:47:05,359 So the second question, I'm not sure 1344 00:47:05,360 --> 00:47:07,099 which parts of the infrastructure will be 1345 00:47:07,100 --> 00:47:08,150 publicly documented, 1346 00:47:09,290 --> 00:47:11,749 the certificate authority 1347 00:47:11,750 --> 00:47:14,039 code itself. 1348 00:47:14,040 --> 00:47:15,629 Or at least a candidate version written 1349 00:47:15,630 --> 00:47:17,789 in gold has just been published last 1350 00:47:17,790 --> 00:47:19,489 week on our GitHub account, 1351 00:47:20,970 --> 00:47:23,699 so if you look at this GitHub URL, 1352 00:47:23,700 --> 00:47:26,099 you can find in some sense the code 1353 00:47:26,100 --> 00:47:27,100 itself. 1354 00:47:29,550 --> 00:47:31,229 There are obviously other parts of the 1355 00:47:31,230 --> 00:47:32,879 CIA infrastructure, such as network 1356 00:47:32,880 --> 00:47:34,919 configuration and data center 1357 00:47:34,920 --> 00:47:36,809 configuration and so on. 1358 00:47:36,810 --> 00:47:38,909 And I'm not sure which of those parts 1359 00:47:38,910 --> 00:47:40,319 will or won't be published when they're 1360 00:47:40,320 --> 00:47:42,509 finalized. Those parts are not 1361 00:47:42,510 --> 00:47:43,510 not decided yet. 1362 00:47:44,520 --> 00:47:45,899 The other question, I guess, was about 1363 00:47:45,900 --> 00:47:47,489 the long term finances. 1364 00:47:47,490 --> 00:47:49,949 And so we really encourage 1365 00:47:49,950 --> 00:47:52,110 people, if you. 1366 00:47:53,280 --> 00:47:55,499 Are an individual or an organization 1367 00:47:55,500 --> 00:47:58,499 that cares about this, um, 1368 00:47:58,500 --> 00:48:00,479 we welcome people to sponsor us and 1369 00:48:00,480 --> 00:48:02,909 become financial partners. 1370 00:48:02,910 --> 00:48:04,289 As you alluded to, we don't have a 1371 00:48:04,290 --> 00:48:06,269 mechanism for individuals to donate right 1372 00:48:06,270 --> 00:48:07,229 now. 1373 00:48:07,230 --> 00:48:09,179 And I think that that's something that's 1374 00:48:09,180 --> 00:48:11,849 likely to appear after the US government 1375 00:48:11,850 --> 00:48:14,489 decides on our tax status 1376 00:48:14,490 --> 00:48:15,989 because that determination is still 1377 00:48:15,990 --> 00:48:16,990 pending. 1378 00:48:17,470 --> 00:48:19,889 OK, can we have, again, a question 1379 00:48:19,890 --> 00:48:20,890 from the Internet? 1380 00:48:22,890 --> 00:48:24,959 Can I issue a search for a dot 1381 00:48:24,960 --> 00:48:27,119 onion domain? 1382 00:48:27,120 --> 00:48:28,120 That's a great question. 1383 00:48:29,520 --> 00:48:31,529 I just spent a long time at ATF in 1384 00:48:31,530 --> 00:48:33,029 Honolulu talking to people about that 1385 00:48:33,030 --> 00:48:35,250 question and we didn't answer it. 1386 00:48:37,950 --> 00:48:39,179 And there are a lot of folks talking 1387 00:48:39,180 --> 00:48:41,319 about that on the browser forum, 1388 00:48:41,320 --> 00:48:42,320 uh, 1389 00:48:43,770 --> 00:48:45,929 mailing list. So I find that question 1390 00:48:45,930 --> 00:48:47,519 absolutely fascinating and I don't know 1391 00:48:47,520 --> 00:48:48,520 the answer. 1392 00:48:48,960 --> 00:48:51,130 And then the three. 1393 00:48:52,470 --> 00:48:54,839 So did you plan to 1394 00:48:54,840 --> 00:48:57,209 include multiple networks 1395 00:48:57,210 --> 00:48:59,579 views into the verification 1396 00:48:59,580 --> 00:49:02,039 of the clan certificate, for example, 1397 00:49:02,040 --> 00:49:04,229 when you have 1398 00:49:04,230 --> 00:49:06,389 some DNS cache poisoning our local 1399 00:49:06,390 --> 00:49:07,390 network attacks? 1400 00:49:08,930 --> 00:49:11,809 Yes, so 1401 00:49:11,810 --> 00:49:14,959 just to restate the threat, 1402 00:49:14,960 --> 00:49:17,899 if someone is applying for a cert and 1403 00:49:17,900 --> 00:49:19,969 is able to compromise part of the 1404 00:49:19,970 --> 00:49:21,439 DNS or part of the routing 1405 00:49:21,440 --> 00:49:23,449 infrastructure, it would be possible to 1406 00:49:23,450 --> 00:49:25,579 redirect connections to a fake version 1407 00:49:25,580 --> 00:49:27,649 of a site and then the verification 1408 00:49:27,650 --> 00:49:29,059 would be performed with the fake version 1409 00:49:29,060 --> 00:49:30,559 instead of the true version. 1410 00:49:30,560 --> 00:49:32,689 And so one possible mitigation for 1411 00:49:32,690 --> 00:49:34,969 that is to perform the verifications 1412 00:49:34,970 --> 00:49:37,219 repeatedly from multiple locations 1413 00:49:37,220 --> 00:49:38,599 on the Internet so that it's more 1414 00:49:38,600 --> 00:49:40,939 difficult to use a single localized 1415 00:49:40,940 --> 00:49:43,039 routing attack or a single localized 1416 00:49:43,040 --> 00:49:45,169 DNS attack to cause 1417 00:49:45,170 --> 00:49:46,849 the validations to validate something 1418 00:49:46,850 --> 00:49:47,809 that's fake. 1419 00:49:47,810 --> 00:49:50,329 And yes, we do plan to do that. 1420 00:49:50,330 --> 00:49:52,069 We had an earlier proof of concept 1421 00:49:52,070 --> 00:49:54,229 version which used Tor 1422 00:49:54,230 --> 00:49:56,749 to perform multiple validations 1423 00:49:56,750 --> 00:49:58,819 so it would perform one directly 1424 00:49:58,820 --> 00:50:01,009 and then one or two via tor via 1425 00:50:01,010 --> 00:50:02,599 different exit nodes that were located in 1426 00:50:02,600 --> 00:50:04,159 different places. 1427 00:50:04,160 --> 00:50:06,289 I don't know whether or not we'll 1428 00:50:06,290 --> 00:50:08,809 use Tor as a part of the validations 1429 00:50:08,810 --> 00:50:10,939 in the future, but multiple validation 1430 00:50:10,940 --> 00:50:13,129 is definitely an intended part of our 1431 00:50:13,130 --> 00:50:14,690 design for exactly that reason. 1432 00:50:15,830 --> 00:50:18,259 And then the one do you see 1433 00:50:18,260 --> 00:50:20,719 that there is some threat against 1434 00:50:20,720 --> 00:50:22,759 your project, considering that 1435 00:50:22,760 --> 00:50:24,650 infrastructure to people 1436 00:50:25,730 --> 00:50:27,979 and also your organization is located 1437 00:50:27,980 --> 00:50:29,179 in the United States? 1438 00:50:30,500 --> 00:50:32,689 I think that actually about eight people 1439 00:50:32,690 --> 00:50:33,319 have asked me that. 1440 00:50:33,320 --> 00:50:34,320 If the Congress already 1441 00:50:35,480 --> 00:50:37,380 had, I welcome the question. 1442 00:50:38,420 --> 00:50:40,129 It's a very common question and a very 1443 00:50:40,130 --> 00:50:41,779 common concern. 1444 00:50:41,780 --> 00:50:43,459 You know, there's a lot of mistrust for 1445 00:50:43,460 --> 00:50:45,049 the US government and the US legal 1446 00:50:45,050 --> 00:50:46,050 authorities, 1447 00:50:47,450 --> 00:50:49,009 probably deservedly. 1448 00:50:49,010 --> 00:50:51,349 And I think 1449 00:50:51,350 --> 00:50:53,119 one answer is that every certificate 1450 00:50:53,120 --> 00:50:55,099 authority is located in and operates in 1451 00:50:55,100 --> 00:50:56,719 some jurisdiction. 1452 00:50:56,720 --> 00:50:58,759 And there are many reasons to be 1453 00:50:58,760 --> 00:51:00,289 concerned about each of those 1454 00:51:00,290 --> 00:51:01,819 jurisdictions. 1455 00:51:01,820 --> 00:51:03,619 There is a trusted certificate authority 1456 00:51:03,620 --> 00:51:05,779 in the People's Republic of China that's 1457 00:51:05,780 --> 00:51:07,849 operated by a Chinese 1458 00:51:07,850 --> 00:51:09,649 government linked entity. 1459 00:51:09,650 --> 00:51:11,869 In fact, we made a chart and we found 1460 00:51:11,870 --> 00:51:13,399 that there are certificate authorities 1461 00:51:13,400 --> 00:51:15,589 operated according 1462 00:51:15,590 --> 00:51:17,539 to their self-description, in 1463 00:51:17,540 --> 00:51:19,459 approximately 50 different national 1464 00:51:19,460 --> 00:51:21,409 jurisdictions, and each of those 1465 00:51:21,410 --> 00:51:23,569 authorities can issue search for any 1466 00:51:23,570 --> 00:51:24,570 name. 1467 00:51:25,040 --> 00:51:27,529 I know that the United States is one 1468 00:51:27,530 --> 00:51:29,719 that people have a special concern 1469 00:51:29,720 --> 00:51:31,039 about, and it's the one where we're going 1470 00:51:31,040 --> 00:51:31,969 to be located. 1471 00:51:31,970 --> 00:51:33,739 We're not going to be located in all 50 1472 00:51:33,740 --> 00:51:34,639 of those jurisdictions. 1473 00:51:34,640 --> 00:51:35,929 We're going to be located in the United 1474 00:51:35,930 --> 00:51:37,159 States. 1475 00:51:37,160 --> 00:51:38,659 I think there are basically 1476 00:51:39,800 --> 00:51:42,259 three reasons why 1477 00:51:42,260 --> 00:51:44,119 people might feel that this isn't as bad 1478 00:51:44,120 --> 00:51:45,680 as they first fear. 1479 00:51:47,990 --> 00:51:50,299 One is that the project, 1480 00:51:50,300 --> 00:51:52,399 perhaps unlike some other cert 1481 00:51:52,400 --> 00:51:54,529 authorities in the United States, is 1482 00:51:54,530 --> 00:51:56,599 run by a group of privacy 1483 00:51:56,600 --> 00:51:58,669 and anti surveillance advocates 1484 00:51:58,670 --> 00:52:01,099 and activists, some of whom 1485 00:52:01,100 --> 00:52:03,229 work in a law 1486 00:52:03,230 --> 00:52:05,959 firm with over a dozen attorneys 1487 00:52:05,960 --> 00:52:07,669 who are very interested in directly 1488 00:52:07,670 --> 00:52:09,169 fighting the government in court over 1489 00:52:09,170 --> 00:52:11,179 surveillance authorities and powers. 1490 00:52:12,290 --> 00:52:14,989 And who would I think, uh, 1491 00:52:14,990 --> 00:52:16,459 one of them can correct me if I'm wrong, 1492 00:52:16,460 --> 00:52:18,409 but. Volcom interesting opportunities to 1493 00:52:18,410 --> 00:52:19,459 go to court to. 1494 00:52:19,460 --> 00:52:20,119 Yeah. 1495 00:52:20,120 --> 00:52:23,209 So one of our attorneys confirmed 1496 00:52:23,210 --> 00:52:24,210 we would 1497 00:52:25,310 --> 00:52:27,319 welcome the opportunity to go to court to 1498 00:52:27,320 --> 00:52:29,449 challenge the government's ability 1499 00:52:29,450 --> 00:52:31,579 to compel 1500 00:52:31,580 --> 00:52:33,859 us to Massachusetts and so on. 1501 00:52:33,860 --> 00:52:36,079 And we may have more enthusiasm 1502 00:52:36,080 --> 00:52:37,849 about that kind of fight than existing 1503 00:52:37,850 --> 00:52:39,679 CERT authorities in the United States. 1504 00:52:39,680 --> 00:52:41,869 I didn't mean to miss issuing 1505 00:52:41,870 --> 00:52:43,369 of certificates or something. 1506 00:52:43,370 --> 00:52:45,349 I rather meant to terminate your 1507 00:52:45,350 --> 00:52:46,759 operation in some way. 1508 00:52:46,760 --> 00:52:47,760 Oh, I'm sorry. 1509 00:52:48,590 --> 00:52:50,389 I just assumed Miss Issuance because that 1510 00:52:50,390 --> 00:52:51,409 was the threat that other people had 1511 00:52:51,410 --> 00:52:52,339 mentioned. 1512 00:52:52,340 --> 00:52:53,869 I think that operating a certificate 1513 00:52:53,870 --> 00:52:56,689 authority seems to be lawful 1514 00:52:56,690 --> 00:52:58,189 and a lot of people do it. 1515 00:52:58,190 --> 00:52:59,780 And there seems to be some 1516 00:53:01,550 --> 00:53:03,709 it's a common line of business 1517 00:53:03,710 --> 00:53:04,819 for people to be in. 1518 00:53:04,820 --> 00:53:07,189 And I'm not aware of legal problems that 1519 00:53:07,190 --> 00:53:09,049 have encountered in terms of their right 1520 00:53:09,050 --> 00:53:10,600 to exist and to discuss. 1521 00:53:11,900 --> 00:53:12,900 Then the two. 1522 00:53:14,030 --> 00:53:15,999 Thank you. Do you have a recommendation 1523 00:53:16,000 --> 00:53:18,859 on how to lobby shared hosting providers 1524 00:53:18,860 --> 00:53:20,509 to pick up your service quickly and 1525 00:53:20,510 --> 00:53:21,510 cheap? 1526 00:53:22,610 --> 00:53:24,199 That's an interesting question. 1527 00:53:24,200 --> 00:53:26,449 I'm hoping that general 1528 00:53:26,450 --> 00:53:27,979 competition and awareness 1529 00:53:29,210 --> 00:53:31,489 helps with that, that some large provider 1530 00:53:31,490 --> 00:53:34,009 may say, all right, well, now this is, 1531 00:53:34,010 --> 00:53:36,319 uh, free or 1532 00:53:36,320 --> 00:53:38,389 just one percent extra or something as a 1533 00:53:38,390 --> 00:53:39,349 result of this service. 1534 00:53:39,350 --> 00:53:40,609 And then others may say, all right, I 1535 00:53:40,610 --> 00:53:42,229 guess we've got to do that, too. 1536 00:53:42,230 --> 00:53:44,299 I have certainly spoken 1537 00:53:44,300 --> 00:53:46,609 to one large hosting 1538 00:53:46,610 --> 00:53:48,739 provider that was very interested in 1539 00:53:48,740 --> 00:53:49,879 integrating our service. 1540 00:53:49,880 --> 00:53:51,589 So I think that there is a likelihood 1541 00:53:51,590 --> 00:53:53,329 that that will happen. 1542 00:53:53,330 --> 00:53:54,949 And I had a suggestion from someone at 1543 00:53:54,950 --> 00:53:57,829 the Congress to try to attend a major 1544 00:53:57,830 --> 00:54:00,739 hosting conference that happens in Europe 1545 00:54:00,740 --> 00:54:01,879 in the spring. 1546 00:54:01,880 --> 00:54:04,819 And so I'm hoping that will attend 1547 00:54:04,820 --> 00:54:06,439 a hosting conference and try to spread 1548 00:54:06,440 --> 00:54:07,459 the word there. 1549 00:54:07,460 --> 00:54:09,619 Do you think a letter or email 1550 00:54:09,620 --> 00:54:12,049 template for a request 1551 00:54:12,050 --> 00:54:13,519 to the shared hosting providers might 1552 00:54:13,520 --> 00:54:15,799 help, as a lot of 1553 00:54:15,800 --> 00:54:18,109 them equal looking 1554 00:54:18,110 --> 00:54:21,199 letters tuning in may 1555 00:54:21,200 --> 00:54:22,529 help? 1556 00:54:22,530 --> 00:54:25,439 So, I mean, I would prefer 1557 00:54:25,440 --> 00:54:28,109 in this context to start with approaches 1558 00:54:28,110 --> 00:54:30,449 through individual engineers 1559 00:54:30,450 --> 00:54:32,550 rather than having sort of a petition, 1560 00:54:33,810 --> 00:54:35,879 because I think it is something that 1561 00:54:35,880 --> 00:54:37,619 they'll start by viewing as a commercial 1562 00:54:37,620 --> 00:54:39,029 and a technical proposition. 1563 00:54:39,030 --> 00:54:41,069 And I think we can try to approach them 1564 00:54:41,070 --> 00:54:43,019 at an organizational level. 1565 00:54:43,020 --> 00:54:45,059 And then I think that competition will 1566 00:54:45,060 --> 00:54:46,979 help quite a bit with that. 1567 00:54:46,980 --> 00:54:49,139 Then the fall, um, 1568 00:54:49,140 --> 00:54:51,389 I wanted to ask if 1569 00:54:51,390 --> 00:54:53,489 you have maybe for about 1570 00:54:54,900 --> 00:54:56,999 working together with the existing CIA 1571 00:54:57,000 --> 00:54:59,279 is like, for example, Cassard, 1572 00:54:59,280 --> 00:55:01,399 because if I look at CIA 1573 00:55:01,400 --> 00:55:03,569 sort of certificate or class 1574 00:55:03,570 --> 00:55:06,179 one, certification is exactly 1575 00:55:06,180 --> 00:55:08,459 the same what you are actually currently 1576 00:55:08,460 --> 00:55:10,949 doing and maybe 1577 00:55:10,950 --> 00:55:12,509 with your scripts you are a little bit 1578 00:55:12,510 --> 00:55:15,209 advanced, but 1579 00:55:15,210 --> 00:55:16,599 why not work together? 1580 00:55:17,920 --> 00:55:19,530 Um, so. 1581 00:55:26,090 --> 00:55:28,429 I really appreciate the search school 1582 00:55:28,430 --> 00:55:31,459 and other people's goal of making 1583 00:55:31,460 --> 00:55:33,619 the certification 1584 00:55:33,620 --> 00:55:35,809 infrastructure a free 1585 00:55:35,810 --> 00:55:37,399 service that's equally available to 1586 00:55:37,400 --> 00:55:38,329 everyone. 1587 00:55:38,330 --> 00:55:40,069 I think that's exactly the right call and 1588 00:55:40,070 --> 00:55:40,969 that's something that we need. 1589 00:55:40,970 --> 00:55:43,159 And that's a reason that we're doing 1590 00:55:43,160 --> 00:55:44,149 this project. 1591 00:55:44,150 --> 00:55:46,219 Um, and I would 1592 00:55:46,220 --> 00:55:48,319 welcome people who want to cooperate 1593 00:55:48,320 --> 00:55:50,659 with us in some way to get in touch. 1594 00:55:50,660 --> 00:55:51,660 I think 1595 00:55:53,240 --> 00:55:55,279 CSIRO in particular has a particular 1596 00:55:55,280 --> 00:55:57,679 model and particular infrastructure 1597 00:55:57,680 --> 00:56:00,139 that is different in some ways from 1598 00:56:00,140 --> 00:56:01,759 what we're doing, although similar in 1599 00:56:01,760 --> 00:56:03,469 some ways and similar in terms of goals. 1600 00:56:05,510 --> 00:56:07,609 But I think basically we've 1601 00:56:07,610 --> 00:56:09,769 developed a very specific path 1602 00:56:09,770 --> 00:56:10,879 that we want to 1603 00:56:11,960 --> 00:56:14,059 get done quickly and start 1604 00:56:14,060 --> 00:56:15,599 issuing quickly. 1605 00:56:15,600 --> 00:56:17,779 Um, so 1606 00:56:17,780 --> 00:56:20,059 we're pursuing the creation of this new 1607 00:56:20,060 --> 00:56:22,819 idea because we think that that's a 1608 00:56:22,820 --> 00:56:24,889 fast way to reach 1609 00:56:24,890 --> 00:56:26,959 the goal of issuing publicly trusted 1610 00:56:26,960 --> 00:56:28,040 search to the public. 1611 00:56:29,210 --> 00:56:30,409 But if there are folks who have 1612 00:56:30,410 --> 00:56:32,419 experience in this area through case or 1613 00:56:32,420 --> 00:56:34,489 otherwise, who have proposals or 1614 00:56:34,490 --> 00:56:36,709 ideas, whether technical proposals 1615 00:56:36,710 --> 00:56:38,329 or proposals for collaboration, they 1616 00:56:38,330 --> 00:56:39,679 should definitely get in touch with us. 1617 00:56:40,820 --> 00:56:43,369 Well, uh. 1618 00:56:43,370 --> 00:56:44,609 Could I say something more? 1619 00:56:44,610 --> 00:56:46,109 Oh, come on, hear me. 1620 00:56:46,110 --> 00:56:47,049 Yeah, OK, good. 1621 00:56:47,050 --> 00:56:49,219 Now, um, well, as 1622 00:56:49,220 --> 00:56:51,419 far Myers, as far as I 1623 00:56:51,420 --> 00:56:53,599 are currently aware of the 1624 00:56:53,600 --> 00:56:55,849 new system at that is currently 1625 00:56:55,850 --> 00:56:58,099 being written and there are quite 1626 00:56:58,100 --> 00:56:59,929 a few changes in there and that will be 1627 00:56:59,930 --> 00:57:02,119 more or less, I'd say, in 1628 00:57:02,120 --> 00:57:04,159 a few parts of it, and that one could 1629 00:57:04,160 --> 00:57:06,409 maybe just put it all 1630 00:57:06,410 --> 00:57:09,049 together to one project. 1631 00:57:09,050 --> 00:57:10,279 Well, I think we should definitely talk 1632 00:57:10,280 --> 00:57:11,280 about it. 1633 00:57:12,650 --> 00:57:15,519 OK, then the six. 1634 00:57:15,520 --> 00:57:17,659 I have two questions, the 1635 00:57:17,660 --> 00:57:19,849 first question is, when you 1636 00:57:19,850 --> 00:57:21,919 reissue certificates or add 1637 00:57:21,920 --> 00:57:23,780 extra domains to these certificates, 1638 00:57:24,890 --> 00:57:27,049 does that include changing the private 1639 00:57:27,050 --> 00:57:27,859 key? 1640 00:57:27,860 --> 00:57:28,860 That's the first question. 1641 00:57:30,840 --> 00:57:32,699 Well, I don't. 1642 00:57:34,280 --> 00:57:36,279 I think I've ever thought about that. 1643 00:57:36,280 --> 00:57:37,869 I mean, there are other people who are 1644 00:57:37,870 --> 00:57:39,729 working on the protocol who presumably 1645 00:57:39,730 --> 00:57:40,819 have thought about that. 1646 00:57:40,820 --> 00:57:42,969 Um, the 1647 00:57:42,970 --> 00:57:44,769 common case that we were thinking of for 1648 00:57:44,770 --> 00:57:46,809 changing the certificates without 1649 00:57:46,810 --> 00:57:49,389 repeating all of the validation 1650 00:57:49,390 --> 00:57:51,709 is keeping the same private key and 1651 00:57:51,710 --> 00:57:54,099 adding or removing names. 1652 00:57:55,360 --> 00:57:57,909 And in that case, we think we can skip 1653 00:57:57,910 --> 00:58:00,009 performing the validation of control 1654 00:58:00,010 --> 00:58:01,299 of names that have already been 1655 00:58:01,300 --> 00:58:03,879 validated. If you can prove continuity 1656 00:58:03,880 --> 00:58:05,139 that you're the same entity that 1657 00:58:05,140 --> 00:58:06,969 contacted us before that we did that 1658 00:58:06,970 --> 00:58:09,069 validation with changing 1659 00:58:09,070 --> 00:58:11,379 the private key might turn out to be 1660 00:58:11,380 --> 00:58:13,539 a big enough change that 1661 00:58:13,540 --> 00:58:15,369 we would want to repeat the validation 1662 00:58:16,960 --> 00:58:18,609 to avoid the risk that it's actually a 1663 00:58:18,610 --> 00:58:20,049 completely different entity coming in 1664 00:58:20,050 --> 00:58:21,050 from scratch. 1665 00:58:22,170 --> 00:58:24,239 OK, so sorry, I have a 1666 00:58:24,240 --> 00:58:26,609 second question that ties into that if 1667 00:58:26,610 --> 00:58:29,039 you are continually 1668 00:58:29,040 --> 00:58:30,629 creating new certificates with the same 1669 00:58:30,630 --> 00:58:32,969 private key, the revocation 1670 00:58:32,970 --> 00:58:35,489 process becomes more complicated because 1671 00:58:35,490 --> 00:58:37,679 you have to revoke every single previous 1672 00:58:37,680 --> 00:58:39,179 certificate that was issued with that 1673 00:58:39,180 --> 00:58:41,099 private key if the private keys is 1674 00:58:41,100 --> 00:58:42,989 compromised. So that leads into my 1675 00:58:42,990 --> 00:58:45,089 question of how are you 1676 00:58:45,090 --> 00:58:47,609 planning to maintain a scalable 1677 00:58:47,610 --> 00:58:50,249 available revocations system 1678 00:58:50,250 --> 00:58:52,349 where OSPI has low 1679 00:58:52,350 --> 00:58:55,679 latency and chorales? 1680 00:58:55,680 --> 00:58:57,179 There's there's a lot of traffic that 1681 00:58:57,180 --> 00:59:00,149 comes along with hosting these services. 1682 00:59:00,150 --> 00:59:02,219 How do you plan on building 1683 00:59:02,220 --> 00:59:04,109 a network infrastructure that's able to 1684 00:59:04,110 --> 00:59:06,569 withstand that in an affordable way? 1685 00:59:06,570 --> 00:59:08,399 So with apologies to my colleagues, I'm 1686 00:59:08,400 --> 00:59:10,139 really glad that I'm not responsible for 1687 00:59:10,140 --> 00:59:12,509 creating the ISP responder because 1688 00:59:12,510 --> 00:59:14,609 I really don't envy people who have to 1689 00:59:14,610 --> 00:59:15,950 create EXPE responder's. 1690 00:59:17,640 --> 00:59:18,640 Having said that, 1691 00:59:20,370 --> 00:59:22,439 we're we know that 1692 00:59:22,440 --> 00:59:24,689 we have to have a lot of hosting capacity 1693 00:59:24,690 --> 00:59:26,159 to serve HSP. 1694 00:59:26,160 --> 00:59:27,599 We're going to have to estimate what that 1695 00:59:27,600 --> 00:59:29,759 will be and figure out where we 1696 00:59:29,760 --> 00:59:31,149 can get it. 1697 00:59:31,150 --> 00:59:33,089 And I think, you know, when you make 1698 00:59:33,090 --> 00:59:35,279 changes, presumably when 1699 00:59:35,280 --> 00:59:37,499 we issue a new cert will 1700 00:59:37,500 --> 00:59:39,419 automatically revoke the old one. 1701 00:59:39,420 --> 00:59:41,309 But that does indeed create a lot of 1702 00:59:41,310 --> 00:59:43,829 potential ASSP traffic 1703 00:59:43,830 --> 00:59:45,210 and a lot of data. 1704 00:59:46,300 --> 00:59:48,279 So I agree that it's a large scale 1705 00:59:48,280 --> 00:59:50,679 challenge, and I hope that my colleagues 1706 00:59:50,680 --> 00:59:53,499 find a great solution to scaling it. 1707 00:59:53,500 --> 00:59:55,359 OK, the last question, because the time 1708 00:59:55,360 --> 00:59:56,979 is up and you had to have an hour for 1709 00:59:56,980 --> 00:59:59,050 questions. Answers is from the Internet. 1710 01:00:01,240 --> 01:00:02,379 Have you guys been working on any 1711 01:00:02,380 --> 01:00:05,199 proposals for restricting a particular 1712 01:00:05,200 --> 01:00:07,659 certificate authority to 1713 01:00:07,660 --> 01:00:09,789 a particular top level domain? 1714 01:00:09,790 --> 01:00:12,159 For example, a European SEIA, 1715 01:00:12,160 --> 01:00:13,630 only four domains in Europe. 1716 01:00:15,300 --> 01:00:17,849 So I think in terms of the threat, 1717 01:00:17,850 --> 01:00:19,559 that probably would have been a good 1718 01:00:19,560 --> 01:00:21,029 measure to have in the certificate 1719 01:00:21,030 --> 01:00:23,159 authority system at the outset 1720 01:00:23,160 --> 01:00:25,319 and to more closely tie 1721 01:00:25,320 --> 01:00:27,419 the people who issue 1722 01:00:27,420 --> 01:00:29,579 the domain names in the first place 1723 01:00:29,580 --> 01:00:31,859 to the cryptographic distribution 1724 01:00:31,860 --> 01:00:34,559 process, because as people point out, 1725 01:00:34,560 --> 01:00:35,999 they're the ones we treat as 1726 01:00:36,000 --> 01:00:38,129 authoritative for the question of who 1727 01:00:38,130 --> 01:00:40,259 controls or who owns the name. 1728 01:00:40,260 --> 01:00:42,299 And so if they're the ones who know who 1729 01:00:42,300 --> 01:00:44,339 owns the name, they're the ones who can 1730 01:00:44,340 --> 01:00:46,140 tell whether someone who wants to 1731 01:00:47,220 --> 01:00:49,409 post a public key 1732 01:00:49,410 --> 01:00:51,299 is, in fact, the owner or not the owner. 1733 01:00:52,470 --> 01:00:54,059 Having said that, that's not the system 1734 01:00:54,060 --> 01:00:56,129 that got created back in the 90s, 1735 01:00:56,130 --> 01:00:57,629 the system that got created back in the 1736 01:00:57,630 --> 01:00:59,909 90s, although it has extensions 1737 01:00:59,910 --> 01:01:01,439 that do allow you to create name 1738 01:01:01,440 --> 01:01:03,329 constraints by default, has no name 1739 01:01:03,330 --> 01:01:05,069 constraints at all. 1740 01:01:05,070 --> 01:01:07,289 And so I don't 1741 01:01:07,290 --> 01:01:08,489 think we see 1742 01:01:09,600 --> 01:01:12,029 a direct reason or a direct path 1743 01:01:12,030 --> 01:01:14,099 for us to create or implement 1744 01:01:14,100 --> 01:01:15,719 such name constraints. 1745 01:01:15,720 --> 01:01:18,089 Um, for the 1746 01:01:18,090 --> 01:01:19,859 the general question of preventing 1747 01:01:19,860 --> 01:01:22,209 issuance for a particular name, 1748 01:01:22,210 --> 01:01:24,359 um, on the part of the 1749 01:01:24,360 --> 01:01:26,699 name holder as opposed 1750 01:01:26,700 --> 01:01:28,349 to on the part of the registrar, 1751 01:01:30,070 --> 01:01:33,119 there is a mechanism called CAA, 1752 01:01:33,120 --> 01:01:35,459 which I think is quite 1753 01:01:35,460 --> 01:01:37,979 interesting and which we may implement, 1754 01:01:37,980 --> 01:01:40,109 which is one mechanism where you can say 1755 01:01:40,110 --> 01:01:42,359 I only want this year 1756 01:01:42,360 --> 01:01:44,639 to issue certs for my domain name. 1757 01:01:44,640 --> 01:01:46,709 I don't want any other to issue 1758 01:01:46,710 --> 01:01:47,669 them. 1759 01:01:47,670 --> 01:01:49,049 That's something that the individual 1760 01:01:49,050 --> 01:01:51,269 domain name Holder has to do. 1761 01:01:51,270 --> 01:01:52,739 But it could be a useful security 1762 01:01:52,740 --> 01:01:54,719 mechanism, at least at the level of 1763 01:01:54,720 --> 01:01:57,059 preventing misjudgments, attacks. 1764 01:01:58,320 --> 01:02:01,229 OK, that was successful 1765 01:02:01,230 --> 01:02:02,669 and I think is. 1766 01:02:02,670 --> 01:02:03,670 Yes, forget the.