 I suggest we get started. So I'm in total conflict of interest. I am going to introduce my collaborators on the Monkey Sphere project. This is Greg Lyle and Daniel Gilmore, who some of you guys know. And we've been working on this project for a while and feel like it's pretty cool and important and extremely relevant to Debian, actually. And without further ado, I will let them take over. I would have preferred a lot more ado, actually, Jamie. Can you stand? You want to stand? OK. I don't know that I can stand and read at the same time. So actually, I'm going to sit down. We've prepared this. We did a lot of rehearsing. So we're going to speak today about authentication and the fact that on the net, we consider it to be broken in many ways. And present one solution that we've been working on and that we think is a particularly good one. So there's a quick rundown of what we're going to talk about. So what's broken? Well, as I said, we've prepared. Authentication is important. And the first thing that we tend to think about is that we don't want people seeing things that we don't want them to see. We want messages that we would want to be confidential to stay confidential. And part of that is that we need to know who we're talking to. We need to know the origins of any given message, be it an email, be it any other sort of connection, a website, we want to know that we're actually talking to who we want to be talking to. So authentication is a requirement for having secure communications on the net. One existing method we see for authentication a lot is as open SSH hosts identifying themselves to you via this key when you first log on to it. And I suspect that most of us here have looked at this and then just always said yes. Who here has actually verified Hoski Fingerprints? Tough crowd. All right. And who here has always verified Hoski Fingerprints? Wow, all right, we have one bold person raising their hand. So quickly the SSH does provide a certificate to you as you, or I'm sorry, raw key material to you when you first attempt to log in and it transmits it as part of that initial connection. And if you want to do any verification of that, you have to find some mechanism to do it. Typically you don't or a lot of people don't. Some of us are very good about that. Alternately you have to be, you have to call someone, you have to call the systems administrator, you have to be in the same room and say hey the host you just set up, what's the key on it, that sort of stuff. So you have to have an out of band mechanism for determining whether or not this is actually the case or not, or that this server is in fact who it says it claims to be. X509 here seen in HTTPS is another way that you see this. If you are to actually scroll down and hover over the lock in any given browser, you'll tell you who is saying, it'll tell you that this website is being authenticated not by nobody, but by somebody, in this case by Verisign. Once again, we have a certificate going over the wire as part of a handshaking with the server. And in this particular case, X509, you have out of band certificates embedded in a browser in this example, there's, you have a whole bunch of them in Etsy for other uses if you wanna use them for open LDAP or that sort of stuff. So, but there is this concept of an out of band mechanism for authenticating this server or authenticating the certificate that's coming across the wire. So the common patterns here are that at least one peer in the communication is showing a public key, a certificate, something along those lines during the initial connection. And in this particular case that we're demonstrating, you're authenticating the other side. You're not authenticating yourself to a service or to a server, you're authenticating that the person that you're talking to, the server that you're talking to, the service that you're communicating with is in fact who they say that they are. The other direction does typically use the other direction being identifying yourself to a service or to a server. That's typically shared secrets, passwords, you can use client keys. I suspect most of us use SSH keys to identify ourselves to servers. I'd actually like to see who uses SSH keys to identify themselves to the servers. I mean, if you're a Debian developer, I think it's sort of a requirement that you have one available. And who supports services for non-Debian folks that where those other users use keys. Okay, wow, that's the best set of hands I've seen for that trade off. But that's good. I mean, I think that is a better arrangement than shared secrets. So I'm glad to see that people are starting to take advantage of it. So a quick rundown. In this particular case, a certificate, as we see an example here, it's an identity, in this case it's a URL or part of a URL, but a website, in many other cases, it is on an open PGP key, for example, that's the identity that is typically an email address or a name in an email address. Doesn't necessarily have to be either of these things. That identity is bound to an actual piece of public key material. And this package is certified by someone, in this case, with the X509 kind of certificate. It's a certificate authority in open PGP. It's yourself, you sign your own keys, or someone else can sign your keys. Another way to look at this is that the certificate authority is asserting that this particular identity has a given public key or a concrete example, verisign identifying of any given server. So, when you have no certifier, or you don't do any certification yourself, that's kind of a problem. You have to have some sort of manual key verification to prevent a man in the middle attack. If I don't know that this server is in fact who it claims to be, anybody could be making a claim about that and I would have no way of verifying that. The problem is also that users don't always understand what it is and I know that I, in particular, I've said stuff like, yeah, you just, that host key exchange stuff at the beginning, just say yes. So users don't always understand what's going on there and users don't also always verify at themselves even if they know what they're doing. With a single certifier, as opposed to no certifier, there's still a set of issues. Each certifier, each certificate only has one certifier, exactly one certifier as per our reading of the spec. You don't have any choice of your trust path. There's only one and you can't corroborate that with any other kind of certifications. The trusted certifiers, the weakest link in the chain of certifiers in an X509 certificate chain, the weakest one is the only one that needs to go down. You don't need to attack all of the certificates in any given change, only one. It's difficult to change these default trusted lists. These are typically embedded in your applications with X509, this is something like the website, this is all in Firefox, Firefox is determining what's trusted and what's not. It's difficult to reject certificate authorities that you happen to know or believe are untrustworthy. And so this is an insecure logjam if we've called it for the entire network. So I wanted to clarify why it's difficult to reject. For one thing the user interface is clunky and confusing but even if the user interface was perfect, it would be difficult to reject a certifier in this default trusted list that we all implicitly trust simply because there are a lot of people that are already using those, there are a lot of sites that you wanna authenticate that are already using these untrustworthy identifiers. And so if you go ahead and you reject the one that you think is untrustworthy, well now you're back in the no certifier problem. So and you'd prefer to have some mechanism of actually getting an assertion that this identity is what you want. So it's not just difficult from a UI perspective, it's difficult because it just throws you back into the no certifier problem which is still not what we want. So if we want to avoid single certifier or no certifier issues, we can hopefully find a multi certifier infrastructure when each certificate can be identified by more than one or by more than one certification. Obviously we all have more power to make assertions and more power to choose the assertions that we trust. Service administrators have more options of who to trust as well as who they're willing to trust is making assertions about there's less grief for the tool vendors and we avoid the weakest link failure modes. You're bad, but. So in the end, as we were working on the project, we were looking for a multi certifier PKI and does there happen to be one? Well, yes, it's OpenPGP as Daniel has said, the original social network. That's actually Jamie's line. Oh is it? I can't take responsibility for it. Okay. I thought that was yours. So why do we look at OpenPGP? Well it's multi certifier as we've talked about. Authenticating other, authenticating things using TLS or X509 certificates is very analogous to identifying someone, identifying say a email address via OpenPGP. These are essentially the same issues. Obviously there's an existing infrastructure, PGP, OpenPGP and implementation of it currently exists. Multiple implementations of it currently exist and we can also use it in multiple spaces without having to actually change anything about the other protocols that we're using to talk about, that we're using to communicate. Since we're looking at something that's out of band to certify our certificates or our assertions, then we don't actually need to change any of those protocols if we can use OpenPGP to do this out of band authentication. So if you look at SSH out of the box, as we saw before you're just exchanging, the server is sending public key material and you're certifying it or not certifying it based on nothing typically. But if we have a network to exchange these things out of band, then we don't necessarily, we skip this no certifier problem and we have a way of actually verifying that this public key is in fact associated with this server. And it can be an automated way so that users are not confronted with having to do a bunch of manual steps that are error prone and confusing and unintelligible. And once again, making the analogy between X509, we have the server and this giving you a certificate over the wire and your browser accepting it. But also we can do this out of band exchange and determine that this server is in fact who it claims to be. So our goal with the monkey sphere was to enable the use of OpenPGP in as many domains as possible. Email obviously it's already in use, we don't necessarily have to worry about working with that. SSH, we have in use, we have working implementation of bi-directional authentication. So that's both the host authenticating to the user and the user authenticating to the servers via OpenPGP key. And we have HTTPS working, but that's only one direction. We have the server authenticating itself to the user. And then we have other TLS stuff in planning stages. So there's nothing else that's actually implemented. So with our current single certifier approach, we have this sort of assertion from a single place, in this case very assigned, saying that a particular Debian domain has a given public key, but with a monkey sphere approach, with a multi-certifier approach, we have any number of assertions can be made about this, any number of certifications can be made that this is the case. And it's not just Debian users, we can in fact include, Verisign is still here, Verisign is still capable of making a statement about any given key. We don't necessarily have to exclude that. This is in fact a superset of that site, that type of authentication. Apologies to people whose images were used in this presentation without checking with you. So as we progress, there were a couple of technical observations that we made and first is this idea that everything can be done out of band. We don't need to actually change any of these other protocols, which is a huge benefit. We don't actually have to go in and change every service that you might like to use to actually use something like this. And as I just mentioned, for authentication purposes, X509 is technically a subset of what OpenPGP can do. So I think that last point bears a little bit of elaboration. What we see when we look at the X509 hierarchical trust model is actually implementable in the OpenPGP web of trust. We would just have to decide that there are these 40 or 200 or whatever, depending on which tools we're using, unaccountable organizations that we're willing to grant. You know, ultimate owner trust in identifying people. So we could implement that in OpenPGP should we decide to do so. Those of us who are using OpenPGP probably think that's a terrible idea. Why have we accepted it in X509 for so long? So this is something that you can in fact use today. There's an unpatched, with unpatched open SSH, there is a Firefox extension and a validation agent for doing X509 in web browser. And there are Debian packages in squeeze. For all of these things. And you're not necessarily sacrificing anything because there are no on the wire changes to any of your services. So you're not giving up any users who are currently using anything. You can do this on top of anything that you are actually currently doing and gain without having to push people out of something that they're already using. So here's a quick example for using SSH host keys. You have an existing RSA host key and you just import that into a key with the monkey sphere host, import key command and then you publish it with the publish keys command. Pretty easy. And then since you are the person who theoretically know what this service that this SSH key is in fact the correct one, you would then go and get that key that you have just published, import it into your own key ring and then sign it and then resend that back to a key server and start incorporating this into the web of trust. So here you're actually making the assertion that this key is bound to this host. So just to clarify a little bit, this string right here becomes the user ID string in the OpenPGP certificate for this host. So this is the full user ID string here. So if you were gonna do the same thing for your website you would just change SSH to HTTPS. And then this creates a brand new OpenPGP certificate with this is the user ID and dated at the time when you created it and then you publish it and then it's on the web of trust. So if you wanna do a search the key servers right now you'll find quite a few of these actually that have already been being used out in the wild both for SSH and for HTTPS. The RSA key is the key that forms the basis of the OpenPGP certificate. So you can't have an OpenPGP key without actually having key material. And the point here is that we are like the earlier slide that showed the certificate. The point is that a certificate is an identity bound to public key material and all certified by somebody. So you need the key and the identity in order to make the OpenPGP cert. Right, so. That's a private, sorry? That's a private key. Right, in order to create the cert you need a private key because you need to create the self signature and you can't create a self signature without having access to the secret key material. So it ends up creating a, it creates an OpenPGP certificate using the secret key material that can then be published. Does that make sense? Why the secret key material access is needed for that step? And it's the same, essentially basically exactly the same for taking a, to make an OpenPGP certificate for the equivalent of an X5 and 9 certificate you take the secret key material that's used for your X5 and 9 certificate and making an OpenPGP certificate out of that. So the observation here is that it's all RSA, right? Yeah, that's a key thing. All of these tools are using the same asymmetric cryptographic authentication mechanism and that's RSA and they're wrapped and packaged in these different ways or not packaged at all in the case of OpenSSH. And so what we're doing is we're actually making a certification mechanism that binds these identities outside of the existing strategies that are being used that are flawed in the ways that Greg talked about with the no-certifier and single-certifier problems. So yeah, so people should also, I mean, feel free to raise your hands and ask questions. I'm gonna, oh, we have one in the back there and then can you stand and say your name? I'm Emmett Hickory. Traditionally with PGP, we focus on a trust protocol involving individuals. I want to know who you are and I'll sign your key. Yeah. When we're dealing with arbitrary services, we have two other entities that are interesting, that of a service and that of an organization. What sort of trust protocols do you recommend for that using this? Okay, that's a good question. So for one thing, it may or may, depending on your organization, you may decide that it may or may not make any sense for the organization itself to make assertions. So you could, for example, if you were running a large organization, create a certifying authority in the traditional X509 model, but just using open PGP certificates instead of using an X509 certificate. In that case, the same verifications that you would use to run your large enterprises, X509 certificate authority would be the, those would be the same protocols that you'd use. In a more egalitarian peer-to-peer network, which is what I would like to see happen, by the way, I'm not, I don't oppose having a large organization have a certificate authority. I think that's a reasonable model. I just don't think it should be the only model that's available and it turns out we can have all of these models for free if we use this particular system. So, and we can have more corroborative work. So in the more egalitarian model, I maintain some servers. I know what those servers are. I know what the, what keys they hold and I can make those certifications with basically extreme confidence, right? Because I know what the key is. If you're willing to call somebody up and say to them on the phone, here's the host key for my SSH service. If you're willing to publish that on your website, those assertions that you're making are clumsy assertions that require error-prone, human-level checking. If you're willing to make those assertions publicly, you should be making them in a way that can be automatically checked and that's what this lets you do. So, if you're, so again, you're probably already willing to publish the SSH host key for your machines. And if you're willing to do that, go ahead and publish it in a way that your users can verify it automatically and that they can see, you said your name is Emmett. Yes. They can say, when they connect to the machine, they say, oh, Emmett says this is the right key, automatically. And that, because that's what humans get, right? The human has met you already. They already exchanged keys. And so the network that we have can be used, we can take advantage of it in these other domains as well. Yeah, I think that's a really important point is that, if I wanna connect to a server or service that my friend Daniel has set up, it's absurd for me to be relying on some crazy other thing to be certifying that. It's just crazy because I know Daniel way more than anybody else who could possibly be claiming to certify him would be able to know him. So why go through the middle? 83% of my question, the one piece that's missing is, what protocol would you recommend for a person to certify that an organization is trusted to then certify services? So I wanna make a distinction between identifying someone or identifying an organization and asserting that an organization is trusted to make these kinds of identifications. So all of the key signing that we did last night, if you participated in that, those were identity certifications that we were making. They were not trust certifications. And I believe that the current model, which is the correct one in OpenPGP for the vast majority of use cases, is that who you decide to rely on to make certifications is a private matter and does not need to be published. We keep our lists of owner trust in our, if we use GPG in the GPG TrustDB. And those assertions that, okay, I know Jamie, I know that his policies are reasonable. Those are decisions that I make. I say I trust Jamie. And there's a bunch of work that we have to do that I'm willing to go into later about better user interfaces that we can use to handle that kind of trust management. And better, we have opportunities to ask those questions of users to build the profile for the users in ways that people actually understand instead of requiring a user to say, do I want to give Emmett marginal owner trust or full owner trust? Like in general in the abstract, that doesn't make sense. I wouldn't give, I mean, as much as I know Jamie and I trust him, I wouldn't necessarily want to give him full owner trust to verify anybody, right? I just, it's reasonable because he certifies certain things and I wouldn't want to ask him to verify my bank or something like that. So I don't want to get into trust certifications right now. I think those are things that people need to be making their own decisions for and we need to be making better tools to help them figure out how to make those things. Hi, my name is Tom Marble. And so I have a, I want to compare and contrast the use cases that you brought up. Initially, you talked about where, let's say I want to SSH into food.example.net and it presents the host ID and then I decide if I want to say yes and then I go ahead. And so now, let's, I just want to note that he didn't say I decide whether that key actually belongs to the host. He said, I decide if I want to say yes. Okay, so we're that point, but that is the point actually. No, that's what people are doing. Right, yeah. So let's contrast it with this exact case, especially since you said open SSH works unpatched. So I now want to SSH into host.example.net. Now do I have to have a special command line ARG so that SSH will check my key ring to see if I have this ID and if not do a receive keys. And then once I have the key, look into my trustee B to see if I decide if I actually trust. And it's a command line that's only this long. No, I'm kidding. Let's, I can answer that. I can show you. Excellent. Let me just pop through here. Okay, so in the current example, we see like the current use case, this user wants to SSH this host, it gets the gobbledygook string and it says the correct thing, because it doesn't, the user doesn't understand, it says no. Okay. So yeah, I know, I know that's not what most users do but this kind of gobbledygook needs to go away. We need to stop presenting users with material like this that they cannot make reasonable decisions about. And so the goal here is to bind the decisions to things that people actually understand and to minimize the number of steps. Now I'm not saying we can completely eliminate the difficult steps. We need to minimize those steps. So the user says no because they got the gobbledygook. So we actually are starting to ship now a little example SSH config just to give you a demonstration. This is a, it's a two liner with some comments. So it's four lines with comments. We actually document stuff occasionally. The only option here is this proxy command. So the proxy command is just monkey sphere, SSH proxy command, %h, %p. So the user goes ahead and puts that into their SSH config. You can imagine other ways of putting it in there. And they connect and as soon as they connect, the, this hook looks in their web of trust and says, oh, I see, this has been certified by somebody that you have already marked as having full owner trust and therefore I know that the key is correct and so I'll stick it in the known host file and then SSH connects and the known host file is populated and everything goes. And then it just prompts them to use their own key. This is the user authenticating to the host and now they're in. So they never saw any of the gobbledygook. Now, if you haven't marked full, if there isn't full calculated validity on that host key, what the user sees instead of the gobbledygook, we need to work on smoothing this out a little bit and anybody with good user interface design or user experience design who wants to talk us through what you think is a good idea, we'd welcome it. Is they see what we're calling the marginal user interface which I don't have a direct example for you here but so instead of saying, here's the gobbledygook, yes, no, it says, the gobbledygook you're about to see has been certified by this person that you do know or by these people that you do know and this is what I'm talking about where there's an opportunity that we have in that context where people, it actually makes sense. I'm connecting to a server that's run by Emmett. I'm expecting it to be certified by Emmett. Whether or not I've granted Emmett any particular kind of owner trust. So if I'm expecting Emmett and it says it's certified by Emmett and Emmett and I have already exchanged our personal keys, the human to human connection is there and we can leverage that at the moment of connection and then we can store that information and continue from there. Let me just very briefly just say the point of the monkey sphere is not just to get host keys into open PGP keys, it's to also get the UI right, to present this information in a way that makes sense to users and to not have to make them have to put in really long command lines and to get this information right. Is there a sexy UI to visualize the trustee fee? Not yet, but it's under, there's a bunch of projects that I'm willing to talk about later but I know there are other questions and I do want to talk about it. But we also try to minimize the UI, right? So that people don't have to, I think that's an IRC question real quick and then Pablo. Lunar from IRC asks. Hi Lunar. Asks, what happens when there is multiple keys with SSH slash slash example.org on a key server? Okay, so the monkey sphere will fetch the keys that have those user, excuse me, it'll fetch the keys that have those user IDs. It doesn't, it's not just gonna accept any key that has this user ID because as we all know, anybody can make an open PGP key that asserts any identity that they want. So if there are multiple keys that are on the key server, it will fetch them and it will sift them and say, oh, these are the ones that are actually certified by people that you know or by people that you not only know but trust. And it will only populate the known host file based on the actual validity of those certifications. We're not just pulling every single key from the public key servers that matches this and stuffing it in your known host file. That would be bad. We're not doing it. So the fact that the owner of the secret has to make the first certificate to upload drops a lot of possible uses cases. Like you can do a man in the middle attack with X509 if you just get, you know, a bad certifier to certify that you're actually gmail.com. Right. And it will be, I mean, I'm thinking we can give our users some compelling reasons to use this infrastructure. So they decide, okay, X509 is not so trustworthy. And with this monkey sphere type of mechanism, now I'm really know that these certificates and certificate that DKG have seen before and these other people I know have seen before. So I'm really logging into my bank not being routed through, I don't know. Russia or something. So how can we start bringing the certificates into the web of trust without, right now we need the people from Gmail to sign their stuff and upload it. Right. So I think that's a good question and there are a couple of different avenues of attack that are sort of political avenues of attack. One option is that we can go to existing certificate authorities and we can tell them you have an opportunity to be part of this alternate certifying approach. When someone comes to you to make us and ask you for their cert, you can offer as an added feature, as an upsell, however they want to do it. You can take that same key and encourage them to make it into an open PGP certificate. There's a couple of other possible approaches we could take like being willing to accept keys that are not self-certified, right? In which case it's trivial for anyone to extract the public key material from the certificate, bind it to a user ID and it's just that we wouldn't have any open PGP self-sigs on that. Now none of our existing open PGP tools use that and I'm not even convinced that would be the right thing to do but that would be one approach to being able to have an overlay on the network without requiring the service administrators to opt in. We're not pursuing that option right now and I'm not convinced that it would be the right one but it's something that's worth thinking about. I'd be curious to hear other people's opinions on it. How are we doing on time? Okay. There's still a half hour left. Okay, cool. So yeah, let's get some other questions. So just based on what you just said about it fetching multiple keys from the key servers checking that they're signed by people you trust and then importing them into your known host file. The monkey sphere proxy command if there's already an entry for lair.fifthorseman.net and the known host file it wouldn't have fetched anything? That's correct. Okay. Depending on what you're, we actually have a couple different configurations that you could choose. We're not expecting users to fiddle with it. By default it would not actually have the delay of a key server fetch in that case. Okay. So you're not actually using the public key information returned over the SSH wire protocol in order to figure out which key you want to take from the key server. We actually can't currently do that because the key server interface is based on the fingerprint of the OpenPGP cert and the OpenPGP cert includes the key, the fingerprint of the OpenPGP cert is a digest over the public key material plus the OpenPGP creation date which is not stored in any of the stuff that's transmitted across the wire. That would make it much easier if we could do that. If you have ideas about how to do that I know you have some key server ideas. Like maybe we can actually say let's add a piece to HKP. We do check that the keys match. We do check that the keys match once they've been fetched, yes. But I think Jonathan is saying you could actually selectively download from the key server if we know what key we're looking for just only look for keys that match a certain thing and I'm saying we can't actually do that based on the methods that I know of for key fetches from the existing HKP. So how are you checking the keys match? You are actually checking the fingerprint of the... No, we're actually comparing the RSA public key material. The full RSA public key material. So we pull them all from the key server. We see which ones validate and then we extract the public key material from that and then make sure that it matches. We take the public key material, return from the server and the public key. So do you add all public keys which match the host name or do you only add all public keys to the known host file that match the key material? We add all public keys to the known host file that are validly bound to the host name. So not everything that has a host name but that are validly bound based on your personal owner trust preferences. So that land needs the question, what about revocations? So if we fetch a key from the key servers. So by the way, we're hoping that this will also encourage users to do regular GPG refresh which is useful in a number of other contexts, right? Refresh your key rings. And we might have an opportunity the more we do this to provide hooks that encourage key refreshes or whatever. If a key is revoked on the public key servers, we will actually strip it from the known host file. So we are handling revocations as well. And expirations, right? So first, congratulations on the project. It's a great initiative and I was, well basically I started using it for real about two weeks ago I hope. And I was really impressed by all the work that was done, like especially over HTTPS and all that. I wanted to provide some feedback on that particular user interface. And for me, there's a lot of cryptic things and they're like a mess called in the star. Like for me, that's kind of unnecessary. And what I've been looking to get from that is not necessarily, okay, I've added the host key. Your doom is like why? Like who certified that key? And that can be just a two line thing or, and this is very simple modification for me that would change a lot of things and that would really improve the user interface. I think it's the same problem we have in the Firefox plugin too. Right, so let me just comment on that and I've got sort of two brief comments on that. One is that regular users don't actually want to have their user experience from what I've seen. They don't want to have their user experience cluttered with a lot of additional information. So we've made a deliberate choice to try to keep things minimal. There are debug log levels that you can turn up if you prefer to see in detail what's going on. And the second observation is that we actually are looking at some more sort of graphical feedback. So if we can make the verification, there's certain ways that we can make this verification happen that could display for each of our, if you're assuming that you're using a GUI, how many people here are using GUIs? Oh, for a second there, I was like, whoa, no one raised their hand. We're all running straight consoles, that's awesome. If you're using the GUI, we could potentially pop up sort of desktop notify the alerts that say the connection you just made was verified because NRKat said that it was okay and you decided that NRKat was okay to verify things from Kumbit in the past. Well, basically, this particular case here is when you add a new key, right? So for me, it's not the regular, when I connect again, I won't have the new key added. This just happened once. Right, so I think we can just add more information there in general. Like to the first prompt, because you're annoying the user already with a message made as well, CY. Well, right, yeah, it occurs to me that you're talking about persuading a CA to get involved in this from the X509 side of things. One way that that might be encouraged is if you close the loop and persuade them to use signatures by people, maybe in the strong set for PGP as a significant part of their signing procedure so that you don't have to do as many of the other onerous, pointless nonsense that they tend to go for if you are in the strong set because they actually know who you are at that point and the people in the strong set are probably the decision makers on which CA to use in quite a lot of certificates, in quite a lot of big sites. So you'd suddenly get a mind share switch towards the first CA to think that was a good idea. And that would actually be a fairly major feedback loop. Right, so I've been talking in particular the folks at Komodo, there's two different folks at Komodo who I've spoken to who seem to think that this might be something that they could maybe get a little bit of leverage with. I'm not committing them to anything. I don't mean that, sorry Komodo, if you're from Komodo and you're hearing about this for the first time. These are two individuals that I've spoken to who work at Komodo who seemed interested at previous presentations of this topic. So I think there is some room there, particularly among certificate authorities who are actually interested in providing a secure network, right? I don't wanna claim here that every single X599 certificate authority is evil or bad or screwed up. The trouble is that the framework in which we're using them makes them as trustworthy as the worst one. So those certificate authorities who actually care about the secure network have a real incentive to try to find another way to participate that can maybe rule out some of their sketchy or fly-by-night or not fly-by-night but still sketchy competitors. So I wanna take a couple more questions but I've got a couple more points that I wanna push that are very Debian-specific. So can I do those before we take the next set of questions? So all right, so there would be a big Debian swirl in the background here if Greg had a certain package installed that he doesn't have. So we've got an edge in this, right? We're Debian, we are one of the major if not the largest participants in the OpenPGD Web of Trust. We've got the infrastructure already among us and between us to be able to take advantage of, right? So we currently take advantage of it for email, right? We sign all of our flame wars or many of our flame wars. And for package signing and package distribution. These are critical pieces of our infrastructure and if those pieces didn't work then Debian would be fundamentally broken in a lot of ways or fundamentally insecure. So we're already reliant on OpenPGP and we've got a big network. So we can do a lot more than that, right? So what can we do? If you run a service for the Debian project or for other Debian users, take that services host key and put it in the Web of Trust, right? And so if you're an individual user, whether this is a specific Debian service or it's a Debian.net service or it's your own service that you happen to use with other Debian users, just put the host key in the Web of Trust. It costs you almost nothing to do that, right? All you have to do is that little example that Greg showed you here. You install the Monkeysphere package, you import the host key. We've got it in back ports by the way so you can do it on your stable server if you're running stable with back ports. And then just certify it. When you do this import key step, it'll show you what the fingerprint is, what the OpenPGP fingerprint is and what the other typical RSA fingerprint mechanisms are. And so when you pull it back down from the key servers, you can verify the key directly just by copying and pasting from your separate console windows. So just do that. Put your thing in the Web of Trust, put your service in the Web of Trust and identify it that way. Your users can then take advantage of this infrastructure to not have to call you to ask about the key and to avoid seeing the garbage and accepting the sort of man in the middle attack for that first connection. So if you maintain a package that authenticates users, that is like the OpenSSH server package, or you maintain a package that authenticates services like any of the various clients like the Gaby client for example. I don't know if you guys have been following people connect to the Gaby servers. We get a prompt that says blah, blah, blah. Do you actually want to connect? Okay. And the answer is of course yes. Well, we should get rid of those prompts that say blah, blah, blah and say this is something that's, this Gaby instance was set up by Michael Schulteis. How many of you know Michael Schulteis? I don't actually know whether he set up the Gaby instance but whoever set it up could have certified it and said yes, this actually is Gaby.devion.net. Why aren't we doing that already? Well, first off the Gaby package doesn't do it. So if you maintain a package like that, that authenticates users or services, then talk to us. We'll help you make it take advantage of the web of trust infrastructure that we already have. If you run a service that devian contributors authenticate to then you can actually use the web of trust to authenticate your users. So we've talked mostly here about users authenticating services but as Greg pointed out earlier the, this is a bi-directional, we have bi-directional possibilities here and we actually have that functional for open SSH. So you can configure your SSH server to read from a list of keys that are generated in the same way by pulling from the web of trust. So what do you have to do? You have to tell your server who its identity certifiers are. So who can your server rely on to properly identify the people that are connecting? Well, one obvious answer is you. If the server can't rely on you to identify people who can it rely on? And maybe it can rely on some other people. You have some friends who you think are you know make reasonable certifications. Well once you do that, now you can tell your server the person who should get access to this account is not AZZX43829 whatever, the person is Jameson Rollins, Jay Rollins at findstructure.net. And then if Jamie just loses control of his SSH key he can now revoke it because he's put his user key for SSH into the open PGP web of trust. So you've got revocation mechanisms in there. You've got human understandable strings in the access control list that you're creating basically instead of just gobbledygook. You don't have to use the, you don't have passwords and you're taking advantage of the infrastructure that we already have. So it works for open SSH and there are some quick readme's on the Monkeysphere website which is web.monkeysphere.info for how to set up your server to work that way. We don't have it working for other user authentication steps right now. If you were interested in that, come talk to us. If you're interested in seeing it happen but can't make it happen, talk to us, we'll put it on our list. If you're interested in trying to help make it happen, definitely talk to us, we'll put it on our list and we'll help you figure out what you need to do to make it work. So that was just that example. Yeah, so that's the concrete Debian request that I wanted to make. I'll just leave it on the last page here. Yeah. So okay, I'll go back to the questions but I wanted to put that out there and I know that unfortunately there are no Debian system administrators in attendance at DEBCOP today. I think that's the case which is a shame I would have loved to have met you folks and hopefully I'll meet you next year in Bosnia. Hopefully some of y'all are watching on the stream. Feel free to find me or any of the other Monkeysphere contributors and talk to us because we'd be happy to help deploy this stuff so we can start actually getting the rest of Debian infrastructure to use this PKI that we already rely on. Yeah, which is what I was gonna ask which is why isn't all of Debian.db.debian.org already in Monkeysphere so we can authenticate against it? And it should be a good first step. And I just wanted to make a more general comment which is I'd heard about Monkeysphere before and I'd glance to the website very briefly as casually. And I saw that you had the second part of it where you're allowing people in based on it. And I was like, ooh, that's a little frightening. And I didn't realize you were doing all the other stuff so I think you might have a little bit of a perception problem where some people may just think oh, it only allows this one frightening, potentially frightening, right? And not all these other cool things too. And I have a third point which is that you're using a key server pool by default. So there's some timeout issues sort of minor by the report. Yes, so we are relying, I mean these slides that we had that show the out of band process, this little cloud at the base of it. This cloud here is the OpenPGP key server pool. The key server pool is actually remarkably functional but the DNS round robin occasionally will point to a dead server. Or you'll just send a key. Right, because if you send a key at one point and then pull it back. So we probably need to think of, so first off it'd be great if there were more key servers that were in the pool so that the proportion of failed key servers was lower. Maybe that would happen. Maybe it would just increase the proportion of failed servers, I'm not sure. But yeah, if folks have architectural ideas about how to improve that, all the key server infrastructure is free software too. We have the ability to make some changes there if we can think about how to make those changes better. Let me just really quick comment. Those sorts of things like I went to your website and it got the wrong impression, definitely tell us that stuff. Please tell us that stuff. Cause we, that's really good feedback. We wanna know in what ways, cause this stuff can be kind of hard and complicated. And if we, I mean it's a lot of relations sort of thing stuff, right? Like to get the right information out there about what we're doing, what the point of it is. So anybody, if you've been confused about anything you've seen on our websites or in the packages, whatever, please tell us, please follow up. And the website is in an icky wicky git repo, which is public, so you're welcome to edit it and push your changes someplace and let us know. Yeah, that's right. All of this is developed in Git and so we're happy to have people sync, apply patches, push them to their public thing, tell us about them, we'll review them and stuff like that. Under what circumstances would, who's talking? It's right here. Sorry, yeah. Under what circumstances would you recommend using to sign someone else's key? So I sign a services key, like for example, let's say I wanted to sign laptop.org's key. And I haven't actually physically been there on the machine and verified that that's the key, but I called, this is my manager on the phone and verified the fingerprint with him. Should I, in your opinion, should I then verify that key? So by verifying a key, so first off, if you are willing to state in a public forum in a signed email, I believe that this is the key that belongs to laptop.org, then I don't see any difference in your being willing to make an open PGP certification of that same statement. So if you have thought about the situation and you'd be willing to make that signed email statement in a public forum, then I think, yeah, go ahead and sign it. There's no problem with that. One thing to be aware of is that when you make that certification, it does bind your name irrevocably to that server in some context. So if there's a service that you're concerned about being publicly associated with, then you probably don't wanna make that certification. Now there's a middle ground between having actually called the system administrator on the phone and verified the fingerprint and believing that this is the key. And I think that that gray area in there is very comparable to the gray area that we have around our human to human key signing protocols. And so I'm not gonna pretend to actually say you must do it this way. But I personally, if I believe a key to be the key that works in that machine to the point where I'm willing to compromise my own connections, if that key is the thing that's being used to compromise my own connections, I would rather make that assertion and let my peers know that this is the key that I believe to be the key that belongs to that service. I think that's more useful and we can have a better web of trust if we are willing to make those assertions publicly. Jeff Crompton, we were talking about the key server earlier and last night you said that currently the key material on a key server is 20 gig. If this takes off when we start putting lots more keys on there, are there any scalability issues for key servers? That's a good question. The thing about the scalability issues for key servers is that it's actually, you certainly don't wanna test them on the public key servers because once things go into the public key servers they don't come out. So I suspect that there will be at some point scalability issues. I don't know at what point we'll hit them. I haven't done any tests like in a private controlled key server environment. So the answer is I don't know. We do need more work on the key servers. I was just talking with Jonathan earlier. So if you're interested in the way that the key servers work, that's another place that you could potentially plug in to help. What I'm missing right now in the workflow you presented is a way to generate revocation certificates and to somehow store them securely so that you have them in case you really need them. That means when the server where you generated the SSA and open PGP key actually failed and is no longer available. Right, so one thing you can do, the Monkey Sphere host does let you generate a revocation certificate for the host key. But one observation is that what matters is not, in this case, what matters is not the self-sig, right? The self-sig on a host key just basically says, yeah, this is a legit host key. What really matters is the fact that you certified that host key. So you can revoke your own certifications on that. And when you know if you're the admin you can revoke your certifications and say this is the wrong one. Now, so Monkey Sphere host has a set of sub-commands and one of them will let you revoke, will let you generate a revocation certificate so that you can absolutely pull it. But depending on what the other kind of certifications are made, the main thing is that you retain control of your own human key so that you can revoke your certifications. So a couple of comments from a key server perspective. One is a move to being able to do a lookup by a fingerprint rather than a free form text search will certainly ease the load on the key server network if this takes off. Okay, we're doing exact string match queries, not free form text search. But that's effectively from some key server point of views that is a free form text search in a key app which then means it's a heavier weight lookup. Especially, I mean there are over two million keys I think in the key servers at the moment. So I don't think there's a concern about the number of key added. It's just about the number of queries. Also, please don't encourage people to generate PGP keys that aren't self-signed. This is something we got rid of a long time ago and there were certain moves in the key server community to throw away any key that wasn't self-signed in an attempt to keep junk off the key servers and there's a risk that if you do that things will get thrown away. Okay, fair enough. That's why I said this is a possibility and I wanted to hear feedback. I fully trust Jonathan to, I mean, yeah. So don't do that. Let's get buy-in from the server operators who want to participate. What was the question? Oh, yeah. It was shown earlier one of the benefits of using the monkey sphere was to get rid of the gobbledygook when you're connecting to a host that you don't already know of the host key. I think there are two other benefits that I think are worthy mentioning. One is that, let's say for example there were something that were to be hereafter known as an open SSL debacle in Debian. With the monkey sphere we could actually revoke host keys and deal with that problem a lot easier than having to go through an arduous rekeying process. So that's one thing that I think is bear's mentioning and then another thing is that the gobbledygook analog on the other side when connecting to a SSH server is that instead of having to send via email or paste on IRC your SSH public key to somebody so that they can give you access to their server, all you need is an open PGP key and it is all just taken care of for you in a much more smoother manner. I think that wasn't shown in that demo because that SSH demo was the other end of the SSH authentication of a host rather than the user authentication. So we are running out of time. I think we're out of time. But come find us and talk to us. This is really neat and the thing that I'm really inspired about is how applicable this could be to the FreedomBox project. I realize we don't have a lot of time but I really would like to get as many smart people together to talk about the application of monkey sphere to FreedomBox, maybe at lunch or maybe at five. Sure, we've actually been talking to the diaspora guys about how to integrate this stuff. But yeah, I mean we think that, basically we think that the open PGP model is the model that we should be using. Can we kind of like informally like get together at lunch and chat about that? Yeah, cool. Thanks, folks.