 Thanks. Good afternoon. I hope everyone's had a great Congress. We're getting quite close to the end and It's been a lot of fun for me, and it's great to be here I'm Seth. I'm from the Electronic Frontier Foundation, and I'm here to talk about a project that we've been working on actually for about three years In some secrecy, and it's really excellent to have this Public and to be able to talk about it and to be able to share our ideas and our plans with everyone So there are a lot of acronyms in this space, and this is really only a tiny selection And I just wanted to start by letting people know if there are people who don't work with certificates or with Web encryption a lot the really most fundamental acronyms that occur the most So the protocol that we used to use as a security layer on top of TCP was called SSL when it was invented the proper name today is TLS that refers to the same protocol in its more recent versions and Of course when you put that On top of your or underneath your web connection. You've got HTTPS We've also got the format of the certificates For exchanging the public keys that we use in these connections. That's called x509 The infrastructure that that forms the basis of is called a public key infrastructure or PKI and the entities that Publish that sign these certificates within the PKI are called certificate authorities or CAs There are many more acronyms out there, but I'll try not to use too many of them So this is a technology for us as privacy advocates that is really fundamental that's really important and that we've been advocating for a long time and We started from a place where people had this sort of web security folklore that you need a secure connection to your website if the user is entering financial data like a credit card number and That's really weird because credit card numbers are not really that sensitive There are a lot of other things that are obviously Much more sensitive than a credit card number, but the folklore persisted for many many years that that's what this technology is about That's where this technology is needed that you use HTTPS when you're accepting credit card numbers and otherwise not and In the last few years the web community has said okay, also if the user is logging in we need to protect the username and password and Okay, after the user has logged in we need to protect the authentication cookie So gradually there's been an expansion of the recognition that this technology is important But I think we need to go much further than that And I don't really think that I have to convince this audience of that But I think we need to convince other audiences of this that we need a much stronger vision that the things around us our communications networks are actually attacking us all the time on a large scale Routinely that these networks are untrustworthy and that we need to protect our communications against them For many reasons for many threat models against many attackers in many different situations and there isn't just one reason for that There's a whole panoply of reasons Why we ought to think of networks as untrustworthy and why we ought to think of network protocols as needing to protect communications against the networks and Plain HTTP was never intended to protect communications against a network in any way It's totally unsecured the information is totally in the clear the network operator every run along the path has a full ability To spy on everything that you do and to modify it and to inject things So just to be concrete and this is just a quick representative sample not the full set of reasons why we want secure connections We've got issues like sidejacking and location tracking So if you have a cookie it might be an authentication cookie It might just be a tracking cookie If someone else can see that cookie that cookie can be repurposed to steal your session to impersonate you or just to recognize That that's you And we heard last year that governments noticed that and that there's a lot of infrastructure that's been created to say Okay, that cookie wasn't meant to be personally identifiable But it is to us because we know who that person was and therefore whenever we see that cookie Sent to that site We know who that is. We know where that person is. We can recognize that device immediately There are also software downloads I was just hearing about a really popular tool for creating installation media for Linux systems and You use this tool and you create bootable USB media and I looked at how does it get the images For your installation media and the answer is there's a hard-coded list of 261 URLs From which ISO images can be downloaded according to what operating system do you want to install? What version do you want to install? None of those 261 URLs is a secure origin All of them are HTTP or FTP with no checksum verification and no signature verification so you're making installation media for your operating system and your tools are going out there and getting your operating system over a Completely unauthenticated completely insecure connection and you're installing not necessarily what you wanted But whatever your network operator wanted you to install and that pattern is repeated over and over again with all kinds of software People are downloading unauthenticated software and installing it and interesting their computers interesting all their communications to software every day Reader privacy is another really significant one so sometimes we hear from People who publish websites like newspapers They say all of the content on our website is public There's nothing secret on our website. We don't need HTTPS The confidentiality of the sensitivity there as with so many other sites is not in the secrecy of the content It's the sensitivity of the association of the reader with what the reader is choosing to read Librarians understand this very well Every book in the library of course is completely public Anyone can walk in and read the contents of the book in the library. There's no attempt to say that these library books are secret But the librarians understand it as a fundamental ethical responsibility to protect the association of the book with the reader to protect the fact of Who is reading what? librarians have articulated this a long time ago and Website operators and publishers need to articulate this too Everything on your website may be public your readers have a really important privacy interest in the selection of what they read on your site another Significant point is content-based censorship built into networks. A lot of people are familiar with this through the golden shield project in China Where if you access a website that mentions certain keywords the golden shield will actually interrupt your connection to prevent you from reading about that topic Unfortunately more and more countries are building that kind of censorship infrastructure directly into their networks And so we need as an anti-censorship measure to Prevent the network operators from being able to see what we're doing and what we're communicating about and with whom we're communicating online and just recently we've been hearing more and more about mobile carriers injecting headers and Broadband carriers injecting advertisements into people's web connections So your ISP will advertise to you by actually tampering with your web connection and putting an ad banner in or Your mobile carrier will say I want to help sites track you so I'm going to put in a header That shows who you are So all of these forms of tampering and these scale all the way up from these commercial motives, of course to government surveillance motives Where we heard last year at the Congress about Governments creating massive infrastructure to actively inject content into people's web connections as a way of delivering malware as a way of Compromising people's devices. So it's a widespread tactic that a lot of people are interested in for a lot of reasons So we need a vision of a secure web that can defend users against these things of really routine use of encryption There are a lot of barriers to this we've talked to a lot of website operators about why don't you use HTTPS on your site? Why don't you have a secure connection to your site? And we hear a lot of things and one is the traditional view that it's slow That it makes it adds latency To the process of establishing a session when the user first connects to the site or that it puts a lot of demands on the CPU of the server For some people who have a complicated server side configuration with load balancers. There are additional complexities about engineering considerations with key management But the one that we hear over and over again most often is all about the difficulty and the cost of obtaining and Keeping up to date and keeping accurate and keeping non expired these certificates that you need in order to let the browser establish a secure connection to your site and We've talked to people who are technically sophisticated people who understand what a crypto key is and they understand What a web server is and they understand what a digital certificate is and they understand why they need it People who understand all of that Still typically take an hour to actually go through the process and actually get and deploy the cert If it's not something that they do on a regular basis Obviously, if it's something that you do every day or every week You become more accustomed to it and more familiar with it and you can get faster at it But we've heard over and over again from system administrators who only have to deal with this say once a year That they have to go and look up a recipe on some website about how do you get a cert? And they have to go through all of these steps Creating a key creating a certificate status request. They have to deal with the syntax of open SSL command line binary Dash no out Some of you will appreciate that Yeah, dash no out All right So this is this is a complex process That's really a deterrent to people and of course there's a financial cost associated with it, too And that's typically a financial cost per subject domain name And even then of course a year later It's going to expire and all of your users are suddenly going to get a cert error Or you're going to add some virtual hosts some subdomains that you didn't think of at the time that you didn't include In the cert and users are going to get a cert error in their browsers when they go to those subdomains and so there's a lot of complexity and there's a lot of purely administrative difficulty in keeping these things up to date keeping these things Deployed remembering which keys are for which sites which certs are for which sites Where does that go in the web server configuration all of this complexity? We believe that overall this is the biggest barrier to adoption on the part of people who have an interest in making a secure website And this is the barrier that we intend to address and eliminate So we've created this project called let's encrypt and this is a collaboration And we started working with the University of Michigan On the idea we started about three years ago working on the idea that there could and should be a completely automated certificate authority That can issue certificates to anyone quickly at no charge And we worked on this project for a couple of years and we happened to learn that Mozilla was actually working on the same project in parallel So fortunately, we were able to combine forces And be stronger and more effective together and have a single project among these three organizations to Bring this vision into practice And the vision is also that we should be better than the existing certificate authorities At least for the portion of the certificate authority space that we occupy in every way We should be cheaper. We should be easier to use. We should be more convenient and we should be more secure And for our launch we have commercial partners akamai sysco and identrust And thanks to them. It's going to be possible for us to have publicly trusted certificates that will be accepted by browsers So just to be clear about that point. Thanks Just to be clear about that point. This is the question that we got the most Our user is going to have to install something in their browser in order to accept your certs And the answer is no the users browsers will trust our certificate authority and its certificates out of the box And for people who aren't familiar with the intermediate ca Mechanism a certificate authority can delegate its power to another certificate authority By issuing a certificate that says this other entity is also a ca And this is something that happens routinely on a large scale We have another project called the ssl observatory that showed that in fact, there are hundreds of entities that have Hundreds of names at least of entities that have had this power delegated to them by certificate authorities Um, and in fact normally When you get a certificate for an end entity for a website It's almost always signed by an intermediate certificate authority not directly by a root certificate authority Our authority will be cross signed by identrust meaning that identrust will delegate to us this, um Ability to be recognized as a certificate authority, which means that mainstream browsers will trust our certificates immediately So within the pki There are various forms and levels of validation That the certificate authorities perform They verify or confirm or validate different kinds of information Depending on what information they're going to put in the certificate The lowest level of validation is domain validation In domain validation The certificate authority says I checked that the applicant The person requesting the certificate controls this domain name And in domain validation the authority explicitly does not confirm who the applicant is They explicitly don't say this is such and such an organization based in such and such a city They say we don't know but this applicant controls this domain name There are other forms of validation that certificate authorities do in the pki such as organizational validation and extended validation Where they do in fact say we're going to go Find out about the human being who requested the cert and we're going to put other contact information and other identity information in the cert so an advantage of domain validation is that since it refers to confirming control To validating control of the domain name We believe that we can replace the certificate authority with a very small shell script Okay, so actually the industry has a lot of rules so the shell script may not be that small but and it may actually be written in go but We have to comply with all of these industry standards, right? As a condition of being a certificate authority, we have to actually go through and have an audit We have to show What our procedural controls are we have to show what our technical controls are We have to show what our policies are and so we're developing all of these aspects but The point that remains is that the dv process can be fully automated For the most common cases it can be performed by machine There doesn't need to be a human being in the loop. And so that's what we're going to do So just to describe a little further how this works You have your client This is kind of confusing like with the x-window system. The server is the client, right? Okay, you have your web server Which is the let's encrypt client Which is connecting to the certificate authority server Using an application that we expect will be bundled with the server operating system Or may be offered by a hosting provider And they speak to each other a protocol that we're developing called ACME The automated certificate management environment and they talk about the certificate issuance process and the steps that need to be performed So to simplify the process a little bit We can say the client says I control these names and I want a cert for them And the server says okay in order to prove that you should do this And the client says all right. I've done so Here's the proof And the server says all right. Here's the certificate And in the common case it ought to be just about as simple as that ACME is a JSON structured protocol that's being developed It was primarily invented by our colleague Richard Barnes at Mozilla And it goes through each step in the process of issuing a cert through dv Just to talk briefly about the organizational aspect We've incorporated a california nonprofit corporation Called the internet security research group or isrg which is the entity that will operate the let's encrypt ca We're preparing for the audits and the other process Other processes that are required for the buildout of a ca And we're expecting to have the ability to issue certificates to the public around june of 2015 So what we have right now is a technology preview So you can get our code you can contribute to our code you can try out our code but just to Warn you Certificates that you get with our code right now won't be publicly trusted at the present time. We can only issue test certificates But we welcome people to experiment with our technology and try out our technology I wanted to talk a little bit about this validation method that we've developed called dvs and i And we think that dvs and i is stronger in some ways than the mechanisms that a lot of dv ca's are using today The basic idea is that the verifier asks the applicant To post a certain self-signed cert containing certain information that the verifier provides The verifier then makes an htdps or tls connection to the server of the applicant And checks that that self-signed cert is actually present and actually contains the requested information And if you have a live htdps site, this doesn't have to interfere with that site You don't have to replace your cert with the cert of this site because we're using the sni mechanism server name indication So when we connect we'll ask about a particular invalid domain name And the self-signed cert should be served in response to that request It doesn't get served in response to other requests. So again, if you have a live site We won't interfere with your live site. It can keep working just as normal while we do this verification in parallel And the bottom line of this is that it proves control of the web server It proves that you have the ability to reconfigure the web server that's listening on that domain To the point of posting new certs And we think this is a very strong validation method and we're expecting this to be the primary or a primary method of validation Again, users don't have to worry about that very much because we're providing client software that handles all of this And we believe that client software is going to be very convenient and that's really an essential part of this vision We think it's going to be At most this difficult To get your cert And it ought to take It ought to take less than a minute to get the cert and install it So I want to show you a video I want to show you an excerpt from a video that was prepared by My colleague James Caston from the University of Michigan. Who's the primary author of the client application And I'll try to narrate and see if I can keep up with what James is saying in the video here But this is just a demo of the Client application as it existed a little while ago So the idea is you might have a site and the site doesn't have HTTPS So when people go to that site, they get an error, right? There's an invalid cert or there's no cert at all. So you have this let's encrypt application and you say sudo let's encrypt This is a warning that the certs that you get won't be publicly trusted. Okay It parses your Apache configuration and detects which virtual hosts you have And it offers to get you certs for all of the virtual hosts that you have And then it says, okay, I'm generating a key. I'm generating a certificate request And I'm connecting to the server and actually while I was explaining that it got the cert and installed it So it finished And it actually It actually reconfigured Apache and then it asks whether you want to redirect HTTP in that Apache configuration virtual host to HTTPS or not Now James is going to do this again showing that if you know exactly what you want ahead of time There's actually a non-interactive mode where you can just say exactly what you want and then you won't be prompted interactively So he's just saying Sorry Yeah So he just wants a cert For encryption example demo and it generated the key generated the request Configured Apache to answer the dvs and i challenge Received the challenge got the cert deployed it and reconfigured Apache with a v-host that redirects the HTTP to HTTPS So now if he reloads the HTTP Apache redirects to HTTPS And so all of this is reliant of course on the ability of the client to parse And to write to the Apache configuration and the configuration files of other web servers And that's an ongoing effort that we're involved with to try to make this as convenient as possible for people regardless of what server software they're using I'm also working on a standalone version Which will just get the cert and save it into a file So if you have some application some server that you want to install the cert into that's not supported by our software For automatic configuration you can just get the cert and have it in a file in your Directory and then you can do what you want with it So we will have a standalone mode that doesn't require you to let our software edit your web server configuration Live, but when it does edit your web server configuration It has a very careful configuration file backup mechanism and checkpointing and rollback mechanism So it's not going to change your configuration file and not give you a copy of how it was before, you know And we care a lot about the security of the Certificate system In fact a lot of people working on this project are people who've done previous research and previous analysis About concerns about the safety of the certificate authority system and concerns about the safety and security of HTTPS We're very well aware of the risks of mis issuance. We're very well aware of The concerns that certificate authorities could get tricked into misissuing something that someone could try to legally compel them to issue inaccurate cert that someone could try to hack them and steal their key All of these are concerns that are certainly very much on our mind and we're not trying to Minimize them or sweep them under the rug. We think that CAs have a big responsibility and We want to be very careful with that responsibility We think that transparency is a really important part of this within the context of the existing system And so we're likely to adopt something along the lines of google's certificate transparency system Where all of the certs that are ever issued by the authority Are published publicly and where we can actually say that if the certificate has not been published publicly It should not be accepted And there are other mechanisms that we're looking at and talking about in terms of transparency In terms of being able to say to people Why did we issue that cert? What certs have we issued? What do they say? We're also very interested in exploring ways that we can decline to issue Things that there's some reason to believe that we shouldn't be issuing And so one policy that we're exploring is if there is a valid cert already For a particular name that's still within its period of validity We may say that we won't automatically issue A new cert for that name unless the applicant can prove that they control the private key That's in the existing cert And so then we could say okay. Well, if there's some HTTPS site out there that's working fine right now We're not just going to issue a cert for that name to some stranger who comes along who doesn't control the private key Of that valid functioning HTTPS site And there are other mechanisms that we can use where domains can say We don't want your ca to ever issue a cert for our name and we can respect that request So again, we're very concerned about avoiding mis issuance and exploring technical means that we can use to mitigate the risks of mis issuance We'd like to be really widely integrated so that this is a really routine thing that people can use conveniently and expect to have and to rely on So we'd like to be in every server operating system We'd like to be integrated with every web server application We'd like to be integrated with every hosting an application platform So we'd like to have a situation where when you sign up for a hosting provider The hosting provider gives you a single click or maybe zero click mechanism Where you'll get a valid cert from us if you want one And of course our protocol is an open standard that's likely to be submitted to standardization at itf And you can implement the protocol in your own software. You don't need to use our software to request or obtain a cert from our ca And so if you are or work with a hosting provider And you don't like our client or it doesn't fit your architecture. You can write your own client, right? You can Do what you like You don't need to directly coordinate with us. You don't need a contractual relationship with us You can just get these certs from us by speaking our protocol to us And we hope that people will do that If you are an organization that finds this valuable and wants to make sure that it can exist We welcome financial sponsorship, but that's absolutely not a condition or a requirement of integrating with us in any way It's just something that you can do to support internet security So that's actually about it. I wanted to acknowledge These are the folks who've been working on the original technical concept with us From mozilla from eff and from the university of michigan And of course as the project has developed we now have even more colleagues from these organizations And even some volunteers from outside who are working on developing other aspects of the ca and other aspects of the technology So it's a great collaboration. You can Go take a look at our code Help develop it help test it help critique it We'd be very grateful for public involvement. So thanks very much and I think we have Actually quite a bit of time for questions because I think that was only half an hour But I know people tend to have questions about this project. So Very happy to hear them. Sorry. I thought you would speak a little bit longer Yeah, but just thank you And I think there are actually a lot of questions So it maybe it's a good thing that you have left us some time for this So is there a question from the internet? Okay, then we start with this Okay, first question. Does this only work with Apache? So it depends what you mean by work with So in terms of the ability to do what we see in the video Where you run the program and it gets the cert and then configures the cert on your website automatically In the current version of our software Apache is the only thing that we've integrated with yet in that way and so Today You would only be able to have that automated experience with Apache We're actively working on integrating with nginx And of course we want to integrate with every other web server So we welcome other people to help Write that integration There's no technical reason that it can't work with any and every web server It just requires us to write the code that deals with reconfiguring the web server in an appropriate way And that code unfortunately will be different for each and every web server application Okay, before we go further. I see that you are sitting At the moment But we have learned that people try to stand up and go out During the Q&A if you need to do so, please be quiet and don't speak and now we will continue with the session I think I start with I don't know who was first. I think I go for one Yeah, that's you. Yeah, okay I have several questions The first one is their possibility to revoke a certificate And what think all the other commercial theories about your work? I'm actually sorry that I cut off the demo video So quickly maybe I'll put that back on while talking about this because the next thing that happens in the demo video Is let's encrypt dash dash revoke And it demonstrates revocation which has actually already been implemented Revocation is actually just about as quick as issuance. In fact, it may be faster because you don't have to test You just have to prove cryptographic control of the name of the subject key And then you can revoke. So yes revocation is already implemented and is of course a very important part of the public key infrastructure And I don't think that we've heard directly from any of the other ca's I saw that one person from one of the other ca's posted on a public mailing list when this was first announced something like Well, I assume they're going to comply with all the industry rules, right? And so far that's the only comment that I've heard from other ca's Okay, well, then I think too Thanks, great stuff. I really look forward to this rolling out. What are the rules of the other Partners Akamai and Cisco in this work Um I think that their main role at the outset is providing financial sponsorship because they think this is important Um, I'm hoping that they'll find it technically useful as a Thing that will help their customers But their initial role is just allowing it to happen financially Great more people should do that Then the fall Um, can I issue a certificate that's only valid for a few days so I could forgo the entire revocation mess and Do it that way and and issue a new certificate every few days So we have a lot of interest in the proposals for so-called short-lived certificates where Some people view that as an alternative to ocsp and I'm sorry to throw out another acronym. That's not in the chart, but There's a lot of difficulty about how in practice browsers should check Whether certificates that have been issued are still valid And a mechanism was created for that that doesn't work very well That an attacker can Defeat And so an alternative might be issuing certificates that have a very short period of validity And that might be much more convenient relatively with our technology Because we have the ability to install the new certificate Into the configuration on a regular basis. We would have the ability to provide automated renewal and automated installation and updating of the Certificate, so I think that's something that could be achieved more easily Um, we have not finished making policy decisions about How or whether short-lived certificates will be used in our system So I can't actually answer the question except to say it's something that we find quite interesting Okay, then there's another question from the internet Yeah, uh, is there a plan to address uses for certificates other than tls such as ssh certificates to enable pki usage with ssh? I don't think that we'll be able to do that before we address the primary case with the web pki I think that If this model proves to Work well as we think it will Then isrg would be very interested in figuring out whether there are other parts of cryptographic infrastructure That we can help provide for the internet I think this case is going to be our first test case and This is where we're starting Then we go to the three Uh, not sure if you know that currently worldwide web consortium technical architecture group So w3c tag prepares publishing the finding about htps recommending it Do you find it useful such document and if there's already some collaboration about what to include in such note We're really grateful to the tg for making that recommendation. We think they are totally correct and uh very timely and Not sure what else to say, but I appreciate that they said what they said And I appreciate that a lot of people in the internet standards community Are really starting to say That cryptography is a fundamental essential part of internet standards and technology standards And it's not that you design something and then you make the optional crypto version a few years later The crypto and the privacy features and the security features Should be a part of the network protocols and the communications protocols from the beginning Yeah, I think people here agree to this Okay, then I think this six First thanks again for this project. I'm really happy about it. So Will this first version also support certificates for non web tls like xmpp smtp or whatever Yeah, so we've had some discussions about that um It appears that right now in most uh tls implementations The same certificate will be accepted for any application. In other words, the Subject entity is just a common name for the domain name And is not explicitly bound to a specific protocol or limited to a specific protocol Maybe it should be According to some security arguments, but it's not And so you have the ability to take a certificate that was issued For a web server in some sense If you want to think of it that way and use it for an xmpp server use it for a mail server And we expect that people will be able to do that If someone wants to write Patch that actually installs it in other servers that you have on your system That would be useful functionality I think a common case for people who only run Something like an xmpp server is that they would run the standalone client Which would temporarily start a listening process listening on port 443 The ca would perform the validation with port 443 and issue the cert And then the cert would be saved as a file which the system administrator could then install in another Service, but again if people want to help make that process more automated. We'd love to have that help Okay, then the five Okay, thanks for the talk Do you plan to support wildcards and multi domain name certificates? So for multi domain name. Yes, we support that right now And it works great You just request all the names that you want in the cert And it validates all of them and we actually have some additional features For people who expect to have to Reissue the cert with more names or fewer names in the future There's a technical way to avoid repeating the validation for each name every time you make changes to the cert Wildcards are a more difficult case We don't really know How to use the validation mechanisms that we have now To perform a validation that would be meaningful and appropriate for issuing a wildcard cert It's a question that's come up quite a bit um And I think that the answer is Right now we don't know how to do it and so right now we're not going to do it And if someone wants to propose a mechanism Through which we could safely issue wildcard certs Our board of directors would be willing to consider that mechanism One thing that one person said at a prior talk about that Is that if we can reissue a cert automatically in Less than one minute with a different selection of names Perhaps the argument or the necessity for wildcard certs decreases If you say oh, I have a new virtual host. Well, that's all right. I'll just take 30 seconds and add that to my cert Okay, then a question from the internet Are you aware that era rascala co-authored a standard that contained an nsa backdoor? um so i'm definitely aware of that report and I don't know a lot about the details of that but Eric is a very active person so the reason that someone is asking me about this is probably That eric is someone I think on this slide who's one of our colleagues who's working directly on this project with us And eric is someone who's very active in internet standards is the Editor of the tls standard and the chair of the tls working group and has a lot of experience with All areas of internet standardization So I don't know the circumstances surrounding that incident But my impression is that eric Was asked to edit that document as a result of his role as the chair of the tls working group and not because he Thought that that technology was a technology that he personally recommended that everyone use Much as other people working in internet standardization have ended up with their names as editors of a lot of things like john postel Who didn't personally invent each and every standard but was called upon to edit them and to issue them Then the phone How does your effort relate to using certificates from dns as in dan and what do you think about that? Is that something that might come into play in a couple of years? maybe So a lot of people have been interested in putting cryptographic keys in dns And there are a lot of mechanisms for that There are different schools of thought about whether it would make sense to replace certificate authority issuance with dns sec delivered keys or Whether you would use it sort of to limit Whether you use it as an alternative or whether you use it as an additional mechanism to confirm the information in the cert I mean, I guess the answer is that we don't have a specific technical plan about how that relates to our work And it's obviously an important development certainly if there are dns sec mechanisms that are relevant to issuance decisions Then we want to know about them and we want to take account of them as a ca Then a question from two So thank you for this work. I really like it Fully automated systems have a tendency to feel badly And well, you've taken out two of the non automated parts of certificate issuance So the human interaction and the financial commitment Do you feel confident that you've prevented any bad failures? So I think different people envision different failure modes I mean, some people envision a failure mode like a private key compromise of the ca And then some people envision a failure mode like someone succeeds in obtaining mis issuance I think that existing dv CAs run the risk of mis issuance if someone is able to compromise The site Because someone who's able to compromise the site can perform the dv verification steps as if that person were the legitimate operator of the site And so there is a risk of mis issuance there even today right I think that we're confident that We won't make that kind of risk systematically worse The ca system always has a weakest link issue If you can compromise any ca you can get that ca to miss issue for any name even if it's Entities that have had no prior relationship whatsoever as in the digital tar compromise for example There was no prior relationship with google, but they were able to issue for google So there's this really fundamental weakest link issue So I think what we can say is that with respect to dv validation Um, we don't think that there's a way in which our design makes things any worse We think that our validation and our transparency is stronger than existing dv ca's Then from the fall You're already removing the hassles for getting the certificate and deploying it and so on And would you please also remove the hassles for creating the dain records and maybe Automatically or with some flag just create the dain record which somebody can copy to his nameserver configuration I think that would be very valuable. Um I mean it's often not the same server Like the web server and the dns server and so the I guess you're just suggesting creating the configuration that someone might then import to another machine So I think that would be great and I Would welcome someone writing a patch for that Then again from the internet Is there a limit of requested sign certificates per domain? Well, I don't know if you can ask for clarification back to the person or not, but Is the question like How many times you can ask for a new certificate related to a particular domain Or In a time frame Um So I I don't know if you can ask for clarification back to the person or not So I don't think that we have any policy developed about that right now Then the six Do you think that Did you think that chariot hossas would join the idea of a free ca and give the Uh certificates for free to their users or So I didn't understand the beginning of the question that who would do this chariot hossas like one and one or Oh, they shared hosting providers. Yes. Yes, um We would definitely really like that and we would consider it a very appropriate and Desirable use of our services if those companies would integrate with us And we would love to have conversations with any and all of them or Second best we'd love to be surprised That when we launch All of them have actually already written it and it already works So the the first best case is that they tell us The second best case is that we launch and then we find out that people go and get a shared hosting account And huh, they got a cert from let's encrypt looks like someone integrated it Yeah, sir I see that you're pointing much. We will have to wait Okay, it's a six Okay, then the five Thanks First of all, yes, you can use web services certificates for mail servers. I'm doing that with start SSL certificates Then my first question is How does a long run Financiation look like For example, when are you going to accept private donations? And the second question is will you document and publish the infrastructure of the ca Um, so the second question, I'm not sure which parts of the infrastructure will be publicly documented the certificate authority code itself Or at least the candidate version written in go has just been published last week on our github account So if you look at this github url, you can find in some sense the ca code itself Um There are obviously other parts of the ci infrastructure such as network configuration And data center configuration and so on And i'm not sure which of those parts Will or won't be published when they're finalized those parts are not Not decided yet. Um, the other question, I guess was about the long term finances and So we really encourage people if you Are an individual or an organization that cares about this Um, we welcome people to sponsor us and become financial partners As you alluded to we don't have a mechanism for individuals to donate right now And I think that that's something that's likely to appear after the u.s. Government Decides on our tax status because that determination is still pending Okay, thanks Okay, we have a organic question from the internet Uh, can I issue a cert for a dot onion domain? That's a great question I just spent a long time at itf in hana lulu talking to people about that question And we didn't answer it And there are a lot of folks talking about that on the ca browser forum Mailing list so I find that question absolutely fascinating and I don't know the answer Yeah Then the three Did you plan to include multiple network views into the verification of the client certificate for example when you Um, have some dns cash poisoning or local network attacks Yes, um, so just to restate the threat if someone is applying for a cert and Is able to compromise part of the dns or part of the routing infrastructure It would be possible to redirect connections to a fake version of a site And then the verification will be performed with the fake version instead of the true version And so one possible mitigation for that is to perform the verifications repeatedly From multiple locations on the internet so that it's more difficult to use a single localized routing attack or a single localized dns attack to cause the validations to validate something that's fake And yes, we do plan to do that. Um, we had an earlier proof of concept version Which used tor to perform multiple Validations, so it would perform one directly And then one or two via tor via different exit nodes that were located in different places Um, I don't know whether or not we'll use tor as a part of the validations In the future, but multi path validation is definitely an intended part of our design for exactly that reason Okay, then the one Do you see that there is some threat Against your project considering that the infrastructure the people And also your organization is located in the united states Um, I think that actually about eight people have asked me that at the congress already I welcome the question It's a very common question and a very common concern You know, there's a lot of mistrust for the u.s government and the u.s legal authorities um probably deservedly and I think one answer is that every certificate authority is located in and operates in some jurisdiction And there are many reasons to be concerned about each of those jurisdictions There is a trusted route certificate authority in the people's republic of china That's operated by a chinese government linked entity In fact, we made a chart and we found that there are certificate authorities operated According to their self-description in approximately 50 different national jurisdictions And each of those authorities can issue certs for any name I know that the united states is one that People have an special concern about and it's the one where we're going to be located We're not going to be located in all 50 of those jurisdictions. We're going to be located in the united states I think there are basically Three Reasons why people might feel that this isn't as bad as they first fear One is that the project Perhaps unlike some other certificate authorities in the united states Is run by a group of privacy and anti-surveillance advocates and activists some of whom work in a Law firm with over a dozen attorneys who are very interested in directly fighting the government in court over surveillance authorities and powers And who would I think One of them can correct me if i'm wrong, but welcome interesting opportunities to go to court to yeah, so one of our attorneys confirms we would Welcome the opportunity to go to court to challenge the government's ability to Uh compel us to mis-issue certs and so on And we may have more enthusiasm about that kind of fight than existing certificate authorities in the united states I didn't mean the mis-issuance of certificates or something i rather meant to terminate your operation in some way Oh, i'm sorry I just assumed mis issuance because that was the threat that other people had mentioned I think that operating a certificate authority seems to be Lawful and a lot of people do it and there seems to be some Uh It's a common line of business for people to be in and i'm not aware of legal problems that ca's have encountered In terms of their right to exist and to be ca's Then the two Thank you. Do you have a recommendation how to lobby shared hosting providers as to pick up your service quickly and cheap? That's an interesting question. I'm hoping that general competition and awareness um Helps with that that some large provider may say all right well now this is uh Free or just one percent extra or something as a result of this service and then others may say all right I guess we've got to do that too I have certainly spoken to one Large hosting provider that was very interested in integrating our service So I think that there is a likelihood that that will happen And I had a suggestion from someone at the congress to try to attend a major Hosting conference that happens in europe In the spring and so i'm hoping that will attend A hosting conference and try to spread the word there. Do you think a letter or email template For a request to the shared hosting providers might help as a lot of them equal-looking Letters tuning in may help So, I mean I would prefer in this context to start with approaches through individual engineers Rather than having a sort of a petition um Because I think it is Something that they'll start by viewing as a commercial and a technical proposition And I think we can try to approach them at an organizational level And then I think that competition will help quite a bit with that Then the four I wanted to ask if you have maybe thought about Working together with the existing ca is like for example ca cert because If I look at ca cert the root certificate or class one certification is exactly the same what you are actually currently doing and Maybe with your scripts you're a little bit advanced um But why not work together? um so I really appreciate ca cert's goal and other people's goal of making The certification infrastructure A free service that's equally available to everyone I think that's exactly the right goal and that's something that we need and that's a reason that we're doing this project And I would welcome people who want to cooperate with us in some way to get in touch. I think ca cert in particular has a particular model and particular infrastructure That is different in some ways from what we're doing although similar in some ways and similar in terms of goals But I think basically we've developed a very specific path that we want to Get done quickly and start issuing quickly So we're pursuing the creation of this new ca because we think that that's A fast way To reach the goal of issuing publicly trusted certs to the public But if there are folks who have experience in this area through ca cert or otherwise Who have proposals or ideas whether technical proposals or proposals for collaboration? They should definitely get in touch with us Well Could I say something more? Oh, come on hear me. Yeah. Yeah. Okay. Good now Well as far as As far I am currently aware of the new system at ca cert is currently being written and there are quite a few changes in there And that would be more or less at say in a few parts are opt-in that one could maybe just Put it all together to one project Well, I think we should definitely talk about it Okay, then the sixth Hi, I have two questions The first question is When you reissue certificates or add extra domains to these certificates Does that include changing the private key? That's the first question Wow, I don't Think I've ever thought about that I mean there are other people who are working on the protocol who presumably have thought about that The common case that we were thinking of for changing the certificates without repeating all of the validation Is keeping the same private key and adding or removing Names And in that case, we think we can skip Performing the validation of control of names that have already been validated If you can prove continuity that you're the same entity that contacted us before that we did that validation with Changing the private key might turn out to be a big enough change That we would want to repeat the validation To avoid the risk that it's actually a completely different entity coming in from scratch Okay, so Sorry, I have a second question that ties into that if you are continually Creating new certificates with the same private key The revocation process becomes more complicated because you have to revoke every single previous certificate That was issued with that private key if the private key is is compromised. So that leads into my question of How are you planning to maintain a scalable available? revocation system where ocsp has low latency and CRL's There's a there's a lot of traffic that comes along with hosting these services How do you plan on building a network infrastructure that's able to withstand that in an affordable way? So with apologies to my colleagues, I'm really glad that I'm not responsible for creating the ocsp responder Because I really don't envy people who have to create ocsp responders Having said that We're We know that we have to have a lot of hosting capacity to serve ocsp We're going to have to estimate what that will be And figure out where we can get it And I think you know when you make changes Presumably when we issue a new cert will Automatically revoke the old one, but that does indeed create a lot of potential ocsp Traffic and a lot of crl data So I agree that it's a large scaling challenge And I hope that my colleagues find a great solution to scaling it Okay, the last question because the time is up and you had to have an hour for questions answers is from the internet Have you guys been working on any proposals for restricting a particular certificate authority To a particular top level domain For example a european ca only for domains in europe So I think in terms of the mis issuance threat That probably would have been a good measure to have in the certificate authority system at the outset and to more closely tie the people who issue the domain names in the first place To the cryptographic key distribution process because as people point out They're the ones we treat as authoritative for the question of who controls or who owns the name And so if they're the ones who know who owns the name, they're the ones who can tell whether someone who wants to post a Public key is in fact the owner or not the owner Having said that that's not the system that got created back in the 90s The system that got created back in the 90s Although it has extensions that do allow you to create name constraints by default has no name constraints at all and so I don't think we see A direct reason or a direct path For us to create or implement such name constraints For the the general question of preventing issuance for a particular name On the part of the name holder as opposed to on the part of the registrar There's a mechanism called caa which I think is quite Interesting and which we may implement which is one mechanism where you can say I only want this ca To issue certs for my domain name. I don't want any other ca to issue them That's something that the individual domain name holder has to do Um, but it could be a useful security mechanism at least at the level of preventing misissuance attacks Okay, that was such Sure, and I think he's yes forget it