 Okay, so without further ado, Daniel Carl Gilmore will be talking to you about the cryptography. So I apologize for the presentation snafu here. So you'll just pretend that this looks good. But basically I wanted to actually just make an argument today and sketch out like a vision for where I think things maybe need to go and what we're missing. So the presentation, there aren't that many pretty pictures in the first place. So it's more about ideas. And I actually welcome questions if anybody has any questions or suggestions in the meantime. So the topic here is Debian as though cryptographic authentication mattered. You can tell it's a little bit of a bitter title because I feel like we're really not doing what we could be doing in the way of helping our users actually take advantage of the strong crypto that we do have available. We're acting right now as though it's sort of an afterthought, but really I think that it's a critical piece for a modern operating system. And we have the opportunity to get it right better than what most people do. So what do I mean by cryptographic authentication? In particular I'm talking about public keys being mapped to identities. And when I say public keys, just basic asymmetric cryptography. It's mathematically verifiable and it's a set up where you can say this identity controls these keys. And that's sort of what I'm looking for. There are other things that I'm not going to refer to. So just to run through those so it's clear which I'm not talking about. Standard DNS is not cryptographic at all. It's sort of best effort UDP delivery over the internet. Not something that we can actually rely on. It's not mathematically verifiable. Tours.onion addresses and Bitcoin purses. Those are things that you might look at and you say, oh, wow, that's so incomprehensible. It's got to be what he means. But no, I'm actually not talking. Those are just public keys or fingerprints of public keys. There's no identity bound to them at all. So yeah, you can have a Bitcoin person be totally anonymous. That's a separate thing. So I'm not talking about that. I'm talking about the binding of public keys to identity information in different contexts. And I'm also not talking about challenge response authentication via MD5, HTTP digest, Kerberos, things like that that are actually shared secret or single trusted third party arrangements. I think that those do use some cryptographic tools, but that's not what I'm talking about. So why do we need public key cryptographic authentication? Basically, shared secrets don't scale. So we need authentication because without authentication, you can't do authorization. So if you say this thing can only be done by this person, this identity, you need to know who you're talking to and you can't have confidentiality without authentication because at least one party needs to know who they're talking to or else you're just whispering into a little void and you don't know who you're talking to. So we need authentication and I think the reason that we need public key authentication is because the network is large and the other approaches don't really scale. Maybe we can do this. So shared secrets don't scale and centralized systems like if you could imagine a global Kerberos 5 domain, which you might be able to implement, doesn't scale so well because it creates a single trust point that's sort of too big to fail in the language that we've been using in the US at least about the banks. Once you have one entity that's that big that's responsible for that much, as soon as they make a mistake, there's no way to say, sorry, you're done, you sort of have to keep using them and so then they have no incentive to fix their problems. And of course, the network is hostile. We need to be able to make introductions across the network. We need to be able to work with each other across the network, but we know that the network is not something that we can actually rely on. So where is this kind of cryptographic authentication used? It's used all over the place in Debian and it's used all over the place in the non-Debian world too, so transport layer security or TLS or SSL, SSH, OTR, email, when we upload our packages, when we download our packages, when you go through new maintainer, there's a bunch of different places where we're actually using cryptographic authentication. But if you notice about all these things, these are all kind of piecemeal, right? We have different ways of associating SSH keys with people than we do with going through dealing with secure app. Debian actually has this infrastructure and we rely on it in parts, but we're not really doing a good job of bringing them together and making it one sort of coherent whole. To actually use these tools effectively, you have to know, okay, right, I'm using SSH right now, so I'm going to be using the keys over in this file and I've got to have these things and OTR is going to be a whole separate bag. It's kind of a mess. And so some existing approaches, we've already sort of talked about that. So this is going on right now, X509, I call the way that's being used in the real world right now, the certificate authority cartel, right? There's a group of unimpeachable, untrustworthy middlemen who sign all the certificates and we all say, okay, well, it's signed by one of them, I guess that'll be all right. OpenPGP has this sort of arcane web of trust thing that most of us don't really understand, including those of us who work on it. The protocol specific handshakes, like ZRTP, which is a voice protocol, Socialist Millionaires Protocol, SMP, which is what OTR uses. So a bunch of different ways to do that kind of handshake. And one that's up and coming, which is pretty exciting, is Dane, which is DNS authentication of named entities. So the idea is you stick the keys in DNS for anything that can be named by DNS. And that's really exciting, except of course that DNS itself is not secure. So you say, well, but we can get DNS sec, and that'll get us bootstrapped to everything that's nameable within DNS. And so now we've got keys associated with these DNS entities. Well, that's all well and good, but each of these I think has failed to provide, or will fail to provide, secure authentication for the users. I've talked about the big, too big to fail for the X509 cartel. OpenPGP has been a failure in the broader sense because it's too geeky to use. People see it as all of the arcane practices. People look at the kind of muddled terminology that we have. And it's kind of too complicated in the way that we've been presenting it for most people to use. So we've got some work to do on that. The protocol specific handshakes fail specifically because they're only good for that protocol. So if you happen to be a regular person who's actually using the network for various means, you learn that one, and now you've got to go learn another one. So you can't go from there into the broader world. And Dain, I think, is going to be a scary failure because if the CAs are too big to fail, if Dain works out, then the root of the DNS tree is going to be way too big to fail. And the folks who control the popular top-level domains, they are going to be way too big to fail. And already we've seen problems where large attackers like the US government will go and lean on, say, the dot-com registry. And the dot-com registry just rolls over and says, OK, you got me, boss. We're going to drop this domain, or we're going to hand it over to you. And that's pretty problematic for people who want to be able to resist being basically devoiced from the global conversation by a potentially powerful adversary. So I think Dain is going to centralize stuff into DNS, and that's going to put a lot of pressure on the registrars that they're not prepared to withstand. The other problem is that Debian's implementation of all of these things is basically impenetrable. It's impenetrable to regular users because it's scattered. There's way too many places to configure things. Even if you knew what you wanted to configure, you'd have to do it in 17 different places to get it roughly what you wanted to. And honestly, I would argue that we actually can't configure it in ways that people really want right now. And then there are too many implementations to actually audit. So it's impenetrable for users, and it's impenetrable for developers or security-conscious auditors or anything to make sure that we actually have things working properly. Fortunately, we're not the only ones who are bad. Everybody else is at least as, in at least of a sorry state as we are. The proprietary operating systems, the major ones, they're doing a decent job at centralizing their X509 work. So one of the many protocols that I've listed back there, they're doing a decent job where there's a system-wide and user-specific key rings of, OK, well, who do we add, which members of the cartel are we willing to trust? But the cartel itself is broken, so that's not that helpful. And they're not allowing for things like scoped delegations. So for example, maybe I'm willing to trust the certificate authority that's run by SPI if they want to identify Debian websites. But maybe the SPI certificate authority has no business certifying HTTPS colon slash slash apple.com. You could argue that it wouldn't make a lot of sense for people who are in a potentially adversarial relationship to be responsible for certifying these other websites. And so another interesting side note is Fedora is trying to standardize all of their transport layer security work around LibNSS. And they're trying to make LibNSS work where you have a similar system-wide X509 key ring and a per-user X509 key ring that lists your trusted authorities. If Fedora can succeed in that, which I'm not convinced they have, they haven't yet, but if they can succeed in doing that, that just brings them to the point where the proprietary operating systems are at. And I don't think that's sufficient for us to really do what we need to do for our users. So these are sort of my critical observations in sketching out the problem space right now. One thing is that there can be no universal trusted authority in a diverse global network. And that's because people are different. So if you look at, say, an activist who's trying to push back against a repressive regime in, say, Syria, they have different needs and different concerns and a different threat model, if you want to use a security terminology, than an activist who's pushing back against, say, a repressive regime in the United States. So it doesn't make sense for us to set up a single system and assume that, oh, everybody's going to be fine trusting this one particular authority. And technology that ignores the differences between our users is guaranteed to fail them at some point. If we take a tool and we say, oh, you don't have to think about it. This thing's just going to make everything work for you. Then that's like saying, don't worry, this is the one true shell. This is the only shell you'll ever need. We all know that that's not going to work. It's also not going to work in terms of who we trust to identify each other over the network. And the last thing is that protocols don't matter. Endpoints do. I don't want a system that's going to solve one protocol for me, because I'm going to use more than one protocol. I want to make sure that I know who I'm talking to. If you put something up on Identica, I ought to be able to go from that to having a private email exchange with you and know that at the very least, that's the same entity that I'm talking to, even though I just switched from HTTP to SMTP. It's kind of silly that right now, all of our authentication schemes are in these little bubbles where they say, this works for this one, and this works for that one. And there's no connection between the two. That's not useful. And this is something that I've had a hard time coming to terms with over the last couple of years, because I believed it to be untrue earlier. But people seem to be happy to tell complicated machinery information, details about their social relationships as long as they get some social rewards for it. So one of the reasons that I used to think that OpenPGP was a failure was because people were generally resistant to mapping these things out for a computer. But with the advent of Facebook and with the success in the commercial sense of Facebook, turns out people are fine mapping out their social relationships to computers. So we should be able to take advantage of that kind of willingness that people seem to have as long as we can work in some level of social reward. So that's sort of where I think we need to head. And if we can offer people that kind of social reward in exchange for their work of doing that kind of input, then we can offer them the social reward without the self-surveillance that things like Facebook and Google+, and whatever are actually encouraging people to buy into. And I think that's really important if we care about our users. So what do we have in Debian? We got a bunch of different stuff. If anybody has something to add to the list, I'd be happy to add it to the list. We have the CA Certificates package, which is badly in need of some love, I think. Last couple uploads have been QA uploads, which I very much appreciate the folks who are doing it. But basically that package is also kind of an all or nothing arrangement, where the system administrator can say these certificate authorities are legit, and these are not. And there's no middle ground, there's no scope delegation, there's no use of that for anything other than the next 509. It's good, it's not what we need it to be in the long term. There's GPG, which has no usable sane defaults, a user interface that borders on sadism, and a very powerful and flexible syntax. So again, not quite there. OTR and SSH, again, in our little walled bubbles. And then how many TLS and SSL implementations do we have in Debian? I think you packaged the most recent one. Clint, how many are we at now? Is it like four, five, six? Eight? Okay, we have a lot of different implementations. So those TLS and or SSL implementations, many of them come with their own certificate resolution scheme, which is a function where you pass it a certificate and it says usually yes, certificate good or no certificate bad. Those APIs themselves are usually flawed. The ways that they actually do the calculations are probably flawed. They probably don't check revocation properly in terms of OCSP and CRL, which are the ways that you revoke X509 certificates, and of course, they're limited to X509, which doesn't cover all of the other things that we're interested in, or we might be interested in, or at the very least, our users are interested in. So what do we need? So what we really need is user friendly, user controlled identity management tools with a common API, so that all of the various TLS implementations, all of the various network communications that need authentication can call out to that system, that identity management system. And I note that I'm not talking about your own identity. If you're using these tools, you're trying to keep track of all the peers that you interact with on the network. And that peer might be another Debian developer. That peer might be a website that you go to. That peer might be your boss. When I say peer, I'm talking about peer in the network sense, not in the sense of that this person is exactly your equal in every way. So we need to keep track of those things over the course of time if we wanna actually be sure that we're having confidential communications over the network, or if we're having any sort of authorized or authorization necessary transactions over the network. The tool was gonna need sane, useful, comprehensible defaults. And it turns out that this kind of project, I think, is a good fit for Debian, right? Debian is, as a distribution, we're in a position to think about making policy and think about system integration in ways that we can encourage tools from upstream and just in terms of how we integrate as a downstream, the tools to play together. Because that kind of playing together, I think, is critical if we actually wanna provide these systems that will work for people in the real world as the network changes around us. So, okay, so what work needs to be done? There's some tools that might be useful. I don't claim that any of the tools has all the answers right now. The Monkey Sphere Project, which I'm part of, has built a very sort of rudimentary, first-pass cryptographic validation agent called MSVA, the Monkey Sphere Validation Agent, which sits and listens for requests and the request looks like, hey, here's a public key in some form or another, whether it's a X5 and ON certificate or OpenPGP or all public key or what. Here's a public key and here's the identity that I'm trying to match it with and oh, by the way, I'm making a connection via, this is actually an SSH session. And the validation agent decides and says, yes, that's a good, you know, you can use that public key for that peer over that connection protocol or know that I can't find any match. And the validation agent has the opportunity to prompt the user in the event that that makes sense. Now, obviously, I'm not encouraging us to do a lot of pop-up boxes that users are just gonna click yes to. I don't think that's useful. So, ooh, did we crash the web browser? No, it's just, does new mail bring up mud? Whose laptop is this? All right. So, there's a bunch of other pieces that you can fit together if you're working on the packaging. LibMSV is a C library that knows how to talk to the MonkeySphere authentication agent if one is present. So, you can try integrating that with some tools that you've got. P11Kit is for managing your own identities at the moment. And I'm working on getting that package into Debian. P11 is PKCS number 11, which is an old RSA standard, if people wanna look it up. DurManager is a similar kind of a daemon offered by the GPG folks, particularly for tracking X509 revocation. It's one of the few attempts to do persistent revocation that we have. I haven't really used it that much. If people wanna use it and file bugs, that would probably be really helpful. And there's probably other pieces that I'm missing. I'd like to know about them. If you have ideas, please let me know. We need user interface help desperately. None of us working on the MonkeySphere are UI designers and we're aware of the limitations in the UI, but we need good suggestions to make it better. We also need the MSVA to work with other protocols because currently it's mainly using the OpenPGP web of trust to do the verification. If you have other recommendations for how a per user or per system daemon like this would make sense, we need to have them proposed. We need to start this conversation and actually have it happening. And then the identity managers is gonna be another really big user interface challenge. How do we make something that gives people the same satisfaction or parts of the same satisfaction to map out who they know and what those relationships are with other systems? So if you're a Daemon contributor, look at your own package. Does your package communicate with other peers over the network? Or does it let the user or the system do that? If it does, ask yourself whether you're properly validating the remote peer. If you're not, now's a great time to start. And if you don't know how to do the validation, try using something like libMSV or try using something like the DER manager so that you don't have to write the code yourself to do the evaluation. Because if we can work on making the tools work together and work from a commonly shared set of assumptions about identity, then the user has more of an incentive to actually go ahead and do the little bit of work that it takes to map out some of those relationships. So, yeah, so I really, this talk is mainly to try to start a conversation about what we might need and how we might go forward and how we might actually be able to advance the state of the art across the board, not just in free software. There's a lot of work ahead of us, but I think we can actually do a bunch of it. And we can certainly improve on the sort of shoddy piecemeal arrangements that we have at the moment. So that's my basic spiel. People have questions, suggestions. Wait, let, microphone, sorry. Do you relate? Oh, do you relate and how do you relate to SSH agent? I'm not sure I understood the question. Can you try one more time? Do you know SSH agent? Yes, I do. How do you relate to that part of the SSH project? Okay, so SSH agent is a tool for managing your own cryptographic secrets. So it's your own secret key. It's not a tool for managing identities of others. So I think SSH agent is a critical piece and actually I can point you to a blog post that I wrote about SSH agent called you should be using SSH agent. So I think it's critical, but it's not, it doesn't solve the whole problem. It helps you to manage your own identities. Actually, I meant GPG agent, not SSH agent, so. Okay, so GPG agent, I can, speaking of sadistic interfaces, GPG agent at the moment presents itself as a similar tool to SSH agent in terms of managing your own identities. But in fact, all GPG agent is doing is caching your passphrase. And the result is that GPG up through version two, Vernacoch has promised me that this is gonna change in version 2.1, which is not yet released. But up to version two, the GPG process itself is actually getting full access to your secret key material. And the way that it does that is it asks the SSH, asks the GPG agent, hey, do you have the password for this key? It gets the password and then it goes ahead and uses it. So there's actually no per-process isolation keeping your secret key material out of GPG with the current GPG design. That's, it's troubling. So, I just wanted to point out that you're absolutely right. This is exactly the size of project, the kind of project you should be doing in Debian because it's not only about distributing software, but it's actually about integrating software together. So it's great to see this kind of, you know, analysis of where we can integrate stuff and how we can do that. A question I have is, I was wondering if you already have a place where people interested into this can sort of try to define a policy, not in the technical sense, but in where we want to go and which list of things we need to change. Do you have a meeting place already for this kind of discussions? So I've been having most of these discussions recently within the group of monkey sphere developers. So there's a monkey sphere mailing list. If folks are interested, we would welcome discussion. It's a very Debian centric mailing list. So if there are Debian developers who want to talk about how it will work with Debian, that would be good. There's also a hash monkey sphere channel on IRC if folks prefer real-time conversation. And if this turns out that it's a bigger question and it turns out that monkey sphere is not the answer that people are consensing on, that's fine. I would be happy to help set up other infrastructure. But at the moment, I'm inviting everyone to work on the monkey sphere channels for that. So I just wanted to say I had a chance to meet DKG last summer at DebConf 10 and was really amazed at how cool monkey sphere is and friends. I think one thing that maybe you're selling short is the value that we have right here in our web of trust. Debian, as I understand it, is at the center of the web of trust. And it's an enormous resource that we need to leverage. And so just a point, I don't know if any ball is here yet, but does anyone know if the key sending has been scheduled? Yes, I scheduled it last night. The key sending is gonna happen tomorrow evening at 9 p.m. We're gonna probably start in the meeting room and then head out into the lobby of Bansky Dvor or maybe across the street if it's too crowded in the lobby or just a nice outside. Well, that's awesome. Even if you didn't sign up in advance for the key signing, I would encourage you to come and bring some slips with your fingerprint. If you don't have a strong key that's been generated, we can point you to some websites on how to create a strong key and come and get your key signed because as a member of the web of trust, now you can take advantage of all the cool things that are in monkey sphere. And so really would encourage people to do that. And then another question for you, Daniel. I haven't had a chance to talk to you about this, but I'm really curious. Are you aware of web sockets as sort of the future of interactive websites? And have you thought about using monkey sphere in a web socket kind of context? I'm aware of web sockets and my reaction thus far has been, yee, yee, yee. So I haven't really thought in detail about it, but it sounds like you have. So maybe we can talk about it later. And look to you, that'd be awesome. Similar to that, I would like to ask you if you could reflect a little bit on web ID. I know that you have had some discussions about that recently. Sure, so web ID, which is the new name for FOAF plus SSL. So just to add to the acronyms, FOAF plus SSL is friend of a friend over SSL, which is now being known as web ID. The basic idea is to use client-side public key authentication over the web that's verified by a callback to a server that you might have that's running on the network. So it's a pretty neat idea, because it means that end users get for free, they get a certificate that says, hey, I'm identified by this URL on the web. And so it's a neat approach, but if you track the trust chain, it turns out that you're still relying in that model on the underlying X509 certificate authority cartel as we currently understand it. So it takes advantage of some tools that are already pretty widely distributed to get better client-side cryptographic certification, but I'm not convinced that it actually solves the underlying problem of, are we relying on unreliable parties? What I was hoping you would also get into was, I believe you directly was in the email conversation with one of the developers of the web ID about actually being able to replace the HTTP with another protocols that it is open to, it's protocol agnostic as I understand it, but if you're not into that, then that's okay. Yeah, I'm pretty sure that web ID is web-reliant given the name. So I don't know, but we could talk about that later too. We can find a new acronym then. Yeah, can you talk about Dane because I think I heard about it, but I'm not sure. Can you explain what it is? Sure, so Dane is the DNS authentication of named entities, and the idea is that if you're trying to contact something that is identified via DNS, so what's identified via DNS? A web server as a basic example, that rather than trust a certificate authority to verify, yes, this guy, this is the key for this particular website, you can just ask the DNS itself and say, where's the key? So like basically instead of using a CS authority, I would trust a registrar instead? That's correct. So then, okay, so that's what I thought. So then in this case, instead of having, I don't know how many CA authorities, we would have hundreds of registrar to be trusted, is that what I should understand? Well, it doesn't seem so safe for me, right? Yeah, in my more complicated version of the slides, with the notes, it says that Dane, it said that Dane replaces the current model which has far too many weakest link untrustworthy middlemen with a new model that has far too many untrustworthy middlemen. I think it actually reduces the number of potential untrustworthy middlemen, so the number of weakest links gets smaller, but it also increases in some sense the authority. My main problem with both of the schemes, the existing scheme and with Dane, is that there is no method for corroboration. You either believe in some certificate you've been given or you don't, and that certificate is only granted by a single party. So you basically have to decide, do you trust that party, do you see that certificate or not? To say, actually, there are three entities that are agreeing that this is the right thing. And in the real world, if we're talking about major mega corporations, you'd like to have a group of them have to maybe do some checks and balances with each other, and Dane and the current model don't do that. So yeah, I think it's still problematic. One way that Monkeysphere could get more manpower among developers would be to have Monkeysphere being used by more people that could hack Monkeysphere, right? Yes. One question is, have you talked about to the, to DSA about actually using Monkeysphere to authenticate Debian machines and also that Debian machines could authenticate Debian developers using Monkeysphere? You're making me spill my secret plans in public here, but yes, that's one of the things that I'm hoping to get out of DebConf this week. I haven't actually met any of the DSA folks in person before this week, so I'm hoping to actually get to spend some time with them I'm trying to see. Yes, they do exist. Unfortunately, I'm not seeing, is there anybody from DSA here? What's that? I don't see anyone from DSA in the crowd for, okay, but yes, I think that, I think that as a group in terms of using Monkeysphere, there's almost no better group to use it than Debian. We actually have the web of trust. We have, you know, we have corroborative trust pads to most of us, and we should be taking advantage of that instead of our current arrangement where we have SSH access granted by an LDAP server that's authenticated by the SPI CA, which you use via a web interface to upload your key. Like, we've already got the GPG key ring. You can just attach your key to that key, that key ring, and push it up to the public key servers, and it's propagated globally automatically without you worrying about it. So we should be taking advantage of that much more than we are right now, and hopefully we can see something change with that. Let me, let me just, I just thought of one other thing with Dain. I was having a conversation last night with Fedon, and he made the point of, well, at least with Dain, you've centralized the problem to DNS. And so maybe, so maybe then we can just figure out how to fix DNS. And I actually think that there's some merit to that argument. I'm not sure how to fix DNS. I would love it if we could fix DNS and make it a little more decentralized. But there is something to be said for the idea that, well, maybe if we just force that thing to be critical, that that'll put the momentum behind us figuring out some way out of the mess that we're in. I don't know how to do it. But there are also, there's a distributed naming buff that hopefully will get some ideas rolling later on if folks are interested in that. So, okay, I didn't really get, from a technical point of view, so what you're trying to achieve, for instance, if I share my PGP or GPG key with you, so then I could, I guess the idea would be that I could also later use that key for, I don't know, to grant you SSH access or something like that. So would that somehow require a master key for each person, or would it more be like just a database of, and your tool would just be sort of a database management tool, you know? So, there's sort of two different parts of answering the question. In terms of how key distribution can work, OpenPGP already has, each key holder has a primary key with a number of subkeys attached to it. And the way it works with the monkey sphere right now is that you can actually attach a subkey to that primary key that specifically is your SSH key, just wrapped in an OpenPGP package and attached and bound to it with a signature from your primary key. So for key deployment, yeah, you can just attach more subkeys, and if we need to specify this subkey specifically for this kind of use, we can find ways to do that. But the other side of the question is, as for identity management, if I've figured out what your public key is, and I've certified it, that any system that I'm responsible for that knows that it can rely on me to make certifications, I can now say, hey, give this guy access to Jabber. And I don't have to set up a password for you. I don't have to write you and ask you to go verify through an email callback or anything. I've already signed your key, and if you don't have a public key that's capable of authenticating to an XMPP server, you just have to add one to your key and upload it. And then my Jabber server can talk to the key servers and say, oh yeah, here's his Jabber key, and then you can have mutual key-based authentication that way. So the idea is, by making the in-person connections, or maybe making a staged series of in-person connections, if we decide that the people in the middle are actually trustworthy, or that there are enough marginally trustworthy people in the middle, that you can have an authentication regime that works across a whole range of protocols. And then in addition to that, it means that if you lose your key or you lose control of your key, you can revoke it, and that clears the ability of that key to be used in all these other places. You don't have to go around resetting passwords and begging someone to please check the, you know, just wipe out that account, I'll start something new. There are revocation mechanisms that are built in. They're not perfect, but they're there, too. Even if you lose your master key, you can also revoke that, or is it? You can. As long as you've generated a revocation certificate ahead of time that you can then publish. Is there any support for, I don't know, offloading the key? I mean, you know, if I lose my SSH keys while my servers are hosed, and if I lose my GPG keys, my email is hosed, but if I lose my primary key for all of this, I would be completely hosed. So is there any sort of functionality planned to offload these things to, I don't know, smart cards or whatever? Yep, there is. You can do smart cards. You can offload it to paper storage and put it in a safety deposit box. There's lots of ways that you can do that. And you can even take the primary key entirely off of your local key ring if you just want to work with subkeys for the most of your work. Yeah, that's all doable. Is that just the way how GPG works anyways? Or is there something special in you? No, that's all part of GPG, that's right. Yep. Yeah, I was once a DSI, so I can probably comment a little bit about what you were talking about on authentication and stuff, our servers. I can't see. I don't think making it so that if a key's been signed by GANF, then the person that owns that key gets to log into anything at all is gonna fly at some point. Well, I don't think GANF should have to be a bottleneck, I think. No, you know what I mean. There could be a magic DSA, you're allowed to log in key. Sure. At which could implement what you were talking about. Given that they don't act the way we use LDAP, we don't trust LDAP, so we just dump it all into a file and then read that off every server. Right. That's the level of sort of conservative paranoia that applies in DSA, and I think that's quite right. I'm a big fan of conservative paranoia. Yeah, but on the other hand, the other way around, using MonkeySphere so that when you log into a new build machine for the first time, or develop a machine for the first time, it's there being presented with a load of nonsense and things like that. I wonder whether I trust that. I suppose I could try looking at the website and looking at the string that's there. Right. Which is completely pointless. Who here has actually looked up fingerprints? I always do, but that's because I was a member of DSA. For the db.debi.org? Yeah, yeah, yeah, and is it a pain in the ass? Who here thinks it's not a pain in the ass? So I think what you're suggesting is that there might be a place for a Debian-specific role key. So we're shifting the focus now to how we can use this kind of situation within the Debian project, not just for our users, but for ourselves, which I think is a good conversation to have, maybe not the specific part of this talk, but a Debian-specific role key that is used to certify people who are known to the project could be a really useful mechanism, because then you could say that role key, and maybe that role key is controlled by the folks who are in DSA, maybe it's controlled by Keyring at Debian. That role key could be something that we then say, oh, every server that gets set up gets certified by that role key, or get certified by someone who has been certified by that role key, and you can trace the past that way. When you get your maintenance shape or your Debian developer status, it's part of the process. That would allow, I run a server where I have get to lights running, and I quite often give out login, or at least uploadability to people, so if you can integrate that, you can say, well, on these 10 Git repositories, anybody that's been signed by that key, go for it. Yep. Cool. So I would be, let me actually, let me qualify my ascent to that a little bit, because I want to be clear that for OpenPGP signatures, I think it's crucial that we treat regular OpenPGP signatures as simple statements of authentication of identity. So it says this identity belongs to this key, and this key belongs to this identity, or rather they both belong to some real world entity. I think as soon as we start to say this OpenPGP certification is actually an authorization to do something, it starts to get a little bit muddled, and it means that one, if a certification means authentication, means authorization, not just authentication, then it makes people more reluctant, if they're thinking about it, to make certifications. And I think we're all better off actually just making it really easy to make certifications so that you're not worried that by doing this am I accidentally granting somebody root on my machine. And I also think that one of the concerns that I've had raised to me by a bunch of people is that the OpenPGP web of trust provides for free a public social graph that folks like Facebook have taken years to try to aggregate. And so do we wanna provide that sort of social graph to the public in general? And I would argue that the more we make the certifications just, hey, I've met this person and I'm pretty sure that's who they are, the less information we're actually giving about this is my buddy, this is someone who I trust with the keys to my house. So if we can be real clear that OpenPGP certifications are identity certifications and if you wanna add something else on extra, be clear that that's something extra and we can figure out how to do that if it turns out that there's a way to do it. But I think we're better off if we make it clear that the standard OpenPGP certification is identity only. And then instead of saying anybody who's been signed by this key gets in, you say, this key is allowed to identify people and here's the list of identities that can get in. So Joey Hess has access to this machine. Phil Hans has access to this machine and then you can figure it out from there as far as what the authentication goes. Any other questions? All right. Thank you guys. I would, if you do have more thoughts or questions or ideas or you wanna work on stuff, please speak up on the MonkeySphere mailing list or on the MonkeySphere IRC channel. There's a bunch of work being done around this kind of idea in the FreedomBox project. There's a distributed naming boff later in the week. There's a bunch of places where these kinds of ideas might fit in. So I encourage you to think about them and bring the ideas up and if we can find a way to sort of coalesce around what's a reasonable arrangement for Debbie and both for the project and for our users, I think we could really move things forward. So thank you. Thank you.