 Okay. We will have this talk now about OpenBGP, Discussion and Skillshare. This is part of the Getting Involved in Debian track. And the speaker is Daniel Kangilmore. So, Daniel, please. Hello. So, my hope is that this is going to be more of a discussion than a presentation. I don't actually have slides, because I wanted to just actually hear what people are working on, what their workflow is, and make sure that we can figure out sort of best practices, ways to do this. What I have up on here is the Gabi notes for this session. Sorry about that. So, this is... Sorry, let me show you where it is. If you go to gabi.debian.org within debconf12buff, there's an OpenBGP Skillshare. This is a Gabi document, so I invite people to edit it. And if someone wants to try to take some notes as people throw out ideas, it would be great if this document could end up actually containing the good ideas from you guys, because I have some ideas about how to use OpenBGP, but I'm sure that everybody else here has other ideas, and the more we can learn from each other, the better. So, also, if you have any questions, or if you want to... I really do mean that this is not going to be just me rambling at you. I'm hoping that we have a discussion, so please sing out. There's a microphone here, and Gunnar has a microphone. Right, so we have two microphones, so either just come up to the mic, raise your hand, and Gunnar will dance it over to you. So I just wanted to make sure that we're sort of all on the same page here about why OpenBGP is important for Debian and important for network communication. So I'm just going to skim through some of these ideas quickly, but if you have questions about them, or if you think that I'm wrong, or that these topics are wrong, or you're not sure, we should talk about those too, because it's a complicated topic. But basically at its core, the OpenBGP certificates are about identity. And the reason that identity is important is because it gives you a baseline that you can then use for confidentiality and for integrity. So why do I say that identity is a baseline for those things? So confidentiality, should we need it, doesn't make any sense if you don't know who you're communicating with? That is, I can't send a confidential communication to an unknown party, because it doesn't ensure that it's private to the unknown party. So identity, I need to know the identity of the party to whom I'm corresponding, or with whom I'm corresponding, in order to ensure that it's a private communication. And integrity is based on the idea that it comes from someone that you know. And here I'm editing the Gaby session as we speak, because the other big thing, and we'll see this a lot in Debian, is reputation. So once you've proven who you are, you can use that as a baseline to say, well, this is the person, I am the person who did these 10 things in the past, and you can judge me by that. And that reputation will help you to find your way into doing the things that you like to do in Debian. So where do we use OpenBGP within Debian? Someone just pasted their password onto line 42 there. You probably want to change your password. So, let's see, let's fix that up here, sorry. So where do we use OpenBGP in Debian? We use it to sign mails to the mailing list sometimes, some of us do, not everyone does, it's not necessary to do that, but we do, some people. We use it for voting, so if you're a Debian developer, whether uploading or not, you participate in the votes that happen, and those all happen via OpenBGP signed mail. There are some password resets and things for Debian machinery that require OpenBGP signed mail. You use it to sign if you're an uploader, you would use it to sign files that are part of package descriptions. I don't know, can people see the text up here? I don't know if this is... But so there's a bunch of different things that we use it for, and we also use it for system infrastructure, so this is how we make sure that our packages are coming from Debian. And that's a system key, it's a key that's maintained by the FTP masters that signs the archive so that you can ensure when you're fetching packages over the network that what you're getting is something that's from Debian. So there's a lot of places that we use it, there are probably many more. Do other people have thoughts about ways that are not mentioned here? Ways that we use it? Well, only worth mentioning, I think, while most of the keys are owned or related to a person, and I think that will be most of your talk, we have some keys also related to roles or to processes. Right, and the archive signing key is a great example for one of those keys. So... I may have missed this actually when I came in, but Debian specifically do use it for identifying new people into Debian. So we have someone who's already trusted as part of Debian and has to have signed a new key that gets introduced, whether that's a new maintainer or a new Debian developer. So we use it for the whole web of trust is actually something we intrinsically use to introduce new people as well as to trust the key material involved. Right, right. So just to give some... What I'm hoping that we can do here in the next 40 minutes or however much we've got, yeah, about 40 minutes, is that we can share some of the ways that we use OpenPGP here and if you've got good workflows that you think might be useful and configurations that might be handy or you have some concerns about the way that you think people are using them, I would just be nice to share those tricks and maybe folks can come away with this with a document that recommends some ideas that people might like. But to give some background on that, I just wanted to make sure that we're all on the same page when we're talking about these keys. So this is just a bit of vocabulary stuff here. I don't know, let's put that in the middle of the screen there. This certificate structure section here in particular. When we say an OpenPGP key, we're talking about actually a bunch of stuff. In general, we're probably talking about the public key material and the names associated with it and the signatures that have been made that say, yes, this name belongs to that key. And so the actual structure... So I've got it drawn up here in sort of a tree diagram. This is one person's OpenPGP certificate. And so up at the top there, the primary key is the sort of core that anchors the entire OpenPGP certificate. And on that primary key, you can see here because I've got a star, that means there are zero or more direct key signatures. Most people don't have those direct key signatures, so we can ignore them for right now. If you ignore that and look down on the next line there, every primary key has to have at least one user ID or more. That's what that plus is for. And then the user ID itself is signed. So what you can note here is that the signature on the user ID actually signs the user ID with the primary key. So it's a signature over all that material. And so when people talk about their key ID, they're talking about an identifier that identifies the primary key. And then because these signatures are present, you can figure out which user IDs are associated with it. So that's the way that it's structured. And a lot of people get the term key ID confused with user ID. And if we can keep the term straight, I think it's going to be more helpful when we're talking. So for example, this here, that's my user ID. And this here is my key ID. Or actually this is my full fingerprint. The full fingerprint is relatively long. When you ask for someone's key ID, they'll usually show you something short like this. Just this last chunk here. Is this visible to folks in the back? Okay. So this key ID, this short key ID, people will often use that to refer to a key. That's a bad idea. That's easily spoofable. Unfortunately, Ashish left us today. He went off to another conference. But Ashish is known for having generated a new key that matches the same key ID as his old key. So you can do that. I've done that on this crappy ancient laptop in a couple of hours. So. Well, for the Debian key ring, we use not the eight last digits as you did, but the last 15, 16 digits. So, well, everything that consists of getting a digest is potentially spoofable. But what's your opinion on getting 16 digits? So 16 digits is 64 bits. These are hex digits. So a brute force search over that space would be roughly two to the 64th operations. And that's pushing it right now. There are known collisions of the 64 bit key IDs in the global PGP Web of Trust. Right. Well, certainly for v3 keys, in fact, it's trivial to create the collision with version three keys. So I should probably adjust this to say openPGP v4 because we really need to stop using openPGP v3. It made me very happy. What's that? We did. Debian stopped using it several years ago, and it made me very happy. Yeah. And actually that move is a great move because, and this is another situation where Debian is important, that move has actually helped to convince the GPG maintainers to drop support. And I think it will be the next release of GPG where you won't actually be able to import a v3 key, so you won't run into those kind of collisions. I really think that we should be using the full fingerprint for everything, but GPG's key database doesn't do that. So we're stuck at the moment where, at the mercy of the tools, if only it was free software that someone could be convinced to fix. Yeah, well GPG made the move of changing to using full fingerprint prints for returning keys, which then broke key servers that did not parse full fingerprint prints. They seem to have just assumed that the world is SKS. So let's not always trust new PG to do the right thing. No, I agree with you. GPG is not always doing the right thing, and I'm saying that we as Debian can give guidance to GPG in terms of what needs to be done, and they seem to accept that. So the other thing to note, I don't know, for those of you who are new to Debian or who haven't looked at the OpenPGP space a lot, Debian is the group of Debian developers and ex-Debian developers and Debian maintainers is the largest group of people actively using OpenPGP certification in a coherent way. And so we actually have a fair amount of sway over what can happen in that space. So I want to follow up on something that Noodle said, especially in the context of what you just said, Daniel, and that is there are alternatives to popular programs like SSH, like Mosh, and I'm wondering how feasible is it to imagine an alternative to GPG that implements PGP? So there is actually, I believe it's, I can't remember the license it's under, it uses OpenSSL, so it's tainted by whatever the association was with that, that the... So the UK domain registry, NOMINET, actually, I believe they still, they've got another system now in place as well, but originally, like if you look back 10 years ago and more, NOMINET used PGP signatures across all of their meals. So every single NOMINET member of which were at least 500 had a PGP key and was using it commercially day to day, and they signed all... any domain that had a .UK ending on it was registered using a PGP signed meal. No, they didn't do Web of Trust things on it, I know that they're technical guys, then sponsored the development of this library which does exist and was written by... Ben Laury. Ben Laury, I couldn't remember which of the lauries it was. I've... looked at it, I must confess I was put off by the licensing which then meant that I couldn't do whatever I was working on. I had the same experience, by the way, I tried to package it and decided that I didn't want to introduce another cryptographic dependency on open SSI licensing. I think having diversity and implementations is always a good thing. I think that GPG actually gets pretty much all of it right. I would have some objections to some of the things they do and some of the ways they work, but in general I think it's a reasonably good implementation. It might be nice to have a library that was easily usable by other projects that would then let you hook in and even do things like tie into Perl rather. I mean almost everything I've seen ties into the GPG code whether it's calling GPG correctly or they've now brought some more of it out into libraries I think. I can talk to some of that if you want. I've not played with it. I mean I have written PGP parsing code that doesn't do any of the crypto stuff and I have some of that that I've used in writing a key server that doesn't do any of the crypto stuff and I think the crypto stuff is actually where the interesting bit is. There's two bits about that. One of which is how much traction would it get and second of all is it needs all of the audits. If you're writing it from scratch it needs to be written by people who are trusted and have other people to look at it and it would take a long time to get to that and I'm not sure we need that at this point in time. OpenSSH came about because SSH was private. The V2 stuff was not available for non-commercial use. It was a use case why we had OpenSSH. LSH as far as I can tell doesn't really exist anymore. I know that there's been some good stuff that's come out of LSH but it never really went anywhere. Let me actually mention that. One of the good things that came out of the LSH development was the Nettle cryptographic library and Nettle actually does have some OpenPGP parsing code. So anyone who's interested in writing and thinking about trying to write an additional OpenPGP implementation will be able to start with the Nettle library and try to either add to that or build on top of that. So I do think that we should have another implementation in particular because of the lack of a library interface to GPG. I would just like to make a motion right here. Right now I know there's a lot of interest and I am interested in following this discussion as planned as part of this like tutorial track and ask you to request an event to continue discussing this which is quite important for us. Sure. And if we can figure out a time to have a further discussion I'll try to announce that and maybe put it into the same document in Gabi so you can check back to see if it got scheduled. So the basic idea is that we've got whoever put sub keys in on line 59 is absolutely correct. I'm not sure why I didn't put the sub keys in there that totally needs to be in there and it should have each sub key. I'm not going to do fancy unicode line drawings on that but each sub key should have a binding signature. Someone wants to hook those up. The sub keys should come directly off of the primary key sorry that's off the top of the screen here. Each primary key can have zero or more sub keys and the sub keys should have basically one binding signature each sub key. So yes so what's happening here someone's got some nice unicode chaps so the binding signature is a signature on a sub key that binds it to the primary key so the key material in the sub key is the same kind of key material that you'd have in a primary key so for example it might be an RSA key but it might have different properties than the primary signature it might be a different size it might be marked to say this key is to be used to encrypt mail rather than to sign things but how do you know that it belongs to the same person? The way that you know is that the primary key has signed over that sub key and itself the sub key belongs to me and you can then infer that it's associated with the user ID that's also associated with the primary key. That actually brings up a question I was having in terms of what's recommended best practice with the primary key always be the signing key and should you only make it a signing key not an encrypting key? So you're asking questions about the key usage and the OpenPGP standard defines a bunch of different possible key usages and here I want to introduce a bit of terminology that I didn't write down here either, very sloppy of me so I would like to distinguish between signing and certification and so when I say signing I do my best to say signing only when we're making a signature over regular data so this is data that's coming from me I'm putting my stamp on this data and when I say certification I mean I am making some kind of OpenPGP signature that is a certification binds a key to an identity or a key to another key or something like that but it's working within that framework and that's different from me signing my email so with that distinction between certification and signing there's a separate and distinct key usage that is certification that's distinct from data signatures your primary key is guaranteed by the structure of this whole thing to be a certifying key it has to be able to certify or else you couldn't make the signatures that bind user IDs and sub-keys to it so you're guaranteed that that's certification and then yes I do recommend that you have a separate sub-key for encryption and then there's a question about how you want to deal with signing you can either go ahead and sign with your primary key or you can make a separate sub-key for signing maybe we can discuss that I'm going to get into the idea of separate sub-keys for signing shortly but yes I recommend that you do not use a single primary key for all purposes and the reason for that is because there are certain kinds of attacks where someone might be able to convince you to do something with your key that they could then replay in another domain so if you have a key that you generally use for one thing, keep using it for that one thing and mark it so that it doesn't, it can't be used for these other things and sub-keys are designed specifically for that kind of a use case to separate it out and say okay this key is going to do this stuff and don't trust it if you see it over here so okay so the core of this stuff is asymmetric encryption which means that your key has some secret material that you and only you control and then there's public material that everyone in the world has to know about so I wanted to talk a little bit about the public key material right now because there are some surprising properties that people don't expect I'm not going to go into the cryptographic part of it for the public key material which is everything that we saw and that whole certificate all of that stuff is public the secret key material doesn't even show up there so what we have is we have a key server network that distributes keys all around the world relatively rapidly and anyone can access it and it's all public and that's using we access it using HKP noodles just mentioned that people tend to think that it's all SKS which is one implementation which we have in Debian right now but it's not all SKS there are other key servers including Onak and PKS but the majority of it right now is SKS so there's a surprising characteristics about this key server network one thing is that when you inject if you upload your public key to one of the key servers within a couple of hours almost all the key servers all around the globe will have that key all of that entire certificate will be published globally and once you publish it there are no take backs any data once put in the key server network is permanently in the key server network so if you don't want this to be public don't put it in the key server network you can't take it out so a consequence of this because the open PGP certificates are certified by other certificates so you've got potential for mapping of a social graph there are a lot of people who are uncomfortable with that so there will be a key signing here at this conference haven't announced exactly when it's going to be I'm hoping that it will be Thursday evening but you can also sign keys with anyone at any time including during this conference even if it's not at the larger key signing event so but that means that say I've signed Gunnar's key if Gunnar uploads his open PGP certificate to the key server network it now has a signature over his user ID and his key that's made by my key so now anyone who wants to can fetch that information off the public key server network and say ah DKG has met Gunnar and they now know that there's been an interaction between us so this allows someone who's interested to look at the map of the sort of social graph that says who has met who and because a lot of people are unwilling to sign keys unless it's someone who they know personally it might even be implied that it's not just who has met who but who actually knows who so we're starting to get to the point where if you look at it you might say oh well this is actually like a whole Facebook friends graph and well what can you do with that well there's a lot of insidious things that someone who's who you don't like might be able to do figure out who your friends are and figure out where you live and where you've been and there's all kinds of stuff so some people are a little bit nervous about the fact that there's a potential for some kind of social graph mapping I'd like to emphasize that if you just sign people's keys after having met and identified them that's the only thing it needs to say it doesn't need to be these are my friends it just needs to be I've identified this person and if you do that I think the social graph mapping becomes significantly less damaging and certainly less damaging than for example the information that is actually contained in your Facebook friends graph or the information that lists the all of the emails that you've sent or something do you want to just send to the microphone I think the mic is being turned on okay let's write this one yes there's there's parts within Knoopici about where you can put on it's called a trust level that you can set but that part will never be exported to the key service so if you set a trust level on someone it will not be exported to the key service that's right so yeah more vocabulary that I feel like I should have written down here because I've tried to distinguish certification versus signing and so let me add a bit of other vocab which is I think trust levels are like falling out of favor they were asked by default some years ago and now they're no no Rhonda's talking about this is where we need a vocabulary disambiguation because even the GPG documentation was fuzzy about this until about a year ago when I sent them some patches so so let's say I have a key and the key claims that it belongs gonna I'm using you as an example I've been doing this sorry I hope you're okay with me using you as an example so let's say I have a key and the key has a user ID attached to it that says Gunnar Wolf well who can make a key that says Gunnar Wolf yes you can you all can it's not hard to make a key and claim whatever you like so I have this key and I have to decide is this actually a key that belongs to Gunnar well the way to do that is that I can go physically talk to Gunnar and he'll tell me yes it's this key so this is a key this is basically what's happening when we do a key signing so once I've confirmed with Gunnar that it's his key I believe that key is I'm going to say I'm going to use the term valid so I believe that that key belongs to the person who is identified by the user ID associated with it so just to clarify that what you're really signing is the fingerprint you're not signing any of the UIDs you are actually signing the user ID so what you're signing is you're signing the primary key which you've interpreted based on the fingerprint and the user ID associated with that so you're actually and I'm going to use the term binding again you're actually binding that user ID to that primary key you're saying I believe that these things go together and making a cryptographic certification that no one but you can make and if you have a certificate that has two user IDs in it like mine has several user IDs because I'm both DKG at 5thForceman.net and DKG at Debian.org so you wouldn't need you wouldn't need to but you could certify both of those things or you could decide I don't know whether he's actually DKG at Debian.org or I think he's actually not but I do know that he's DKG at 5thForceman.net and you can certify the one user ID and not certify the other it's all within your control to do that so but what I was just saying so I've gotten this key I've looked at its fingerprint I've talked to Gunnar it has Gunnar's user ID on it the fingerprint checks out I now believe that key is valid so I believe this key belongs to Gunnar I can now make a certification about that and I can even send that certification to Gunnar or I can publish it to the public key server network to tell other people I believe this key belongs to Gunnar that's all about validity but I can now also say in GPG I trust the person who holds this key and I trust them is limited in scope GPG doesn't care about whether you trust them to feed your children GPG doesn't care about whether you trust them to cook good food GPG doesn't even care about whether you trust them to write good software the trust they're talking about is very narrow and it says I trust the person who holds this key to make good identifications that is their certifications that are made on other keys are I'm going to consider those things acceptable so then if Gunnar meets noodles Gunnar checks out the key with noodles Gunnar makes a certification for noodles and publishes that well I might now take that certification and say the certification was made by Gunnar therefore I now believe that that key is in fact noodles key so that's a valid key that I now believe is valid because I trust Gunnar so when Rhonda was talking about setting trust levels in a key you're not publishing your trust levels the trust levels are something that GPG keeps to itself and it knows, you've told it this is a person who I think makes good certifications this is a person who I think does not make good certifications and by default it assumes that you're not willing to rely on anybody's certifications so when you hear trust that means am I willing to accept certifications by this person and when you hear validity that means do I believe this key belongs to the person whose name is associated with it do you want to try that microphone or try Gunnar it works now you can revoke your key by publishing the revocation certificate but how would you revoke trust let me add revocation because that's another one that I should have put in here and I'll put it in my handwriting in green here so that it looks like I thought of it well revocation is a public statement it says either this key is not valid anymore when you revoke your key or when you revoke your user ID it says this user ID is no longer associated with me I used to work at foocorp.com and I no longer do so I'm going to revoke that user ID so these are public statements but trust is not a public thing you're not publishing your trust levels so to revoke your trust just means changing your trust and you'd set that in the same way that you would use GPG to change to set the trust so you'd say GPG edit key and then the identity that you're going to be editing the key for and then you'd say trust and it would say what's your new trust decision and so if you had previously said I trust Gunnar fully and then you discovered that actually Gunnar tends to sign keys immediately after the wine and cheese party then you might go in and say okay I'm going to drop the trust level and his certifications back down to zero because he's probably full of wine and cheese and that's not a good time to be thinking about what you're doing by the way I don't think he has ever done that so today is a good moment to find out right yeah lots of different things that we could be covering here so let me try to hit a couple of other details that people might be interested in and then I'd like we're kind of running close on time already so we've talked a lot about the public key handling another question might be about how we handle secret keys your secret key material really does need to stay secret to you if anyone else learns your secret key material they can impersonate you on the network if they can impersonate you that violates the identity thing that we're trying to build out which means that they can damage your reputation they can receive confidential messages that were intended for you they can masquerade as you when talking to someone else it violates a whole bunch they can upload packages as you if you're a Debian developer which then hurts everybody else in the distribution including all of our users and all of the derivatives so keeping your secret key material secret is actually really critically important also really critically important is making sure that you still have access to your secret key material so not only should no one else have access to it you need to be able to have access to it if you lose the laptop that it was on because it got it was out in the rain and it got soaked you now don't have an identity to be able to connect back into the web of trust so you'll have to rebuild it again so managing your secret key material carefully is a pretty critically important thing and there's a lot of people who have different interesting strategies to do that including things like keeping your primary key offline so that it's available and having sub-keys to do all of your regular work you can use smart cards as somebody noted up there and there are other approaches that you can that you can use Gunnar you're standing with a mic and you have so I wanted to point out that there's some things to think about there for managing the secret keys and then there are some suggestions sort of technical suggestions about key size ciphers to use and things like that that I'm not going to I think get into too much detail I can yeah I'm just curious how many people in this room either use offline primary keys or don't have the primary keys on their laptop but only sub-keys so not very many people but let me just point out here there's a confirmation bias in the people who are interested in these questions being in this room and that was less than 25% of the people in this room I think so very few people are currently doing that I'm not currently doing it even though right now I think I probably should be trying to sort out soon and how many people are using smart cards but basically you can have a smart card soon external device where you store the private key and the idea is that as it is an external device it cannot be accessed so your key cannot be stolen from the by breaking into your computer and any signing will actually not be done by the computer but by the card itself right so I I actually used to carry a smart card for some secret key material that happened to not be open PGP secret key material it was RSA keys for other purposes and I carried it for about four years and I'm no longer carry it so I'll just say why I decided that the trade-off was worth it at the time which is the stuff that you described and after four years I've now decided that I don't think it's worth it for me one is that smart cards if you use them every day and you carry them every day they will fail they're cheap crappy hardware and they don't have really a long insertion life and if you use it regularly it's likely to fail the second reason and when it fails then you have to dig out a key from backup or whatever and the second reason that I don't use it anymore is because I've been reading about different kinds of attacks on smart cards and there actually are cryptographic attacks on smart cards that make it sound like you might be able to extract the key from the card itself which is like the absolute worst thing that you're not supposed to be able to do so there are I think they have a lot of advantages I think they also have some disadvantages and I'm not sure I'm not convinced enough by the hardware vendors that the key promises they offer are going to be maintained unfortunately we have a question on IRC from somebody who is very far away in the Central American country by the pool I have a question how is the normal approach to use when you notice that the user has several keys and has no longer access to those keys personally I ask if they just lost their secret key and if they confirmed I decide not to sign any new key since I feel they will not take a good care of their private data okay so part of the thing about OpenPGP certifications is that these are subjective questions right is this person who they say they are do they really have control of their key and it's sort of up to you to figure out what you what your signing parameters are so I don't think I can answer that for anyone else I personally would not make that decision I would sign it what I would probably do is I would probably sign their key and I would probably set an expiration date on my certification so I would say I believe this is their key but it's probably only going to be their key for about a year and if in nine months they're still using it maybe I'll make another certification for another year but that way I don't have to think about it I can just say it's probably about a year long and we'll see where they're at so it's a soft expiration yeah if you look at the certifications that I've made you'll see there are lots of there are lots of expirations in them not just because I think people are necessarily going to be lazy but because I don't know what the future is going to be like would you take the opportunity to educate them about revocation certificates yes so if you lose control of your key or if an adversary or someone unknown gains access to your key what can you do if you still have your key you can generate a revocation certificate right then and say this key is no longer valid publish it to the key server network using the same mechanism and all of the key server network will propagate it and anyone who fetches your key again will get that revocation certificate and say oh this is no longer the right key if you do not still have access to your key for example if you stored the key only on your laptop and your laptop was stolen then you don't have a way to publish that revocation certificate and that means that in the future your key will always be published and it's out there with no revocation so what you can do is you can create a revocation certificate and store it you can put it on a USB key you can print it out on paper and if you should you have to use it you can type it in you'll make a revocation certificate and just store it for safe keeping so that when you lose your key you can revoke it don't give anyone else access to that revocation certificate because if they have it then they can publish it themselves but a very good thing to do as soon as you make your first key make a revocation certificate store it somewhere that someone else that no one else can get it to get access to it there's one other option you can actually allow other keys to revoke your key so I use it for example I have another key I use not for Debian but for something else which my Debian key can actually revoke so I don't need to keep a revocation certificate for the other key because your other key can revoke it and you can also do that with a friend so you actually really do trust you can create this kind of revocation certificate that says if this person says that my keys or my certifications are no good then believe them but you have to keep in mind that you cannot revoke the revoke grant right yep sorry for the screensaver there so we are really short on time here and I feel like we haven't gotten through even a quarter of what we could talk about I'm going to mention a couple things since key server access potentially leaks who you're communicating with some people don't like to use HKP which is the key server access protocol the HTTP key server protocol so you can actually use HKPS which is HKP over transport layer security that's in newer versions of GPG you need to have the GPG-CURL package installed on your machine to be able to do it and you'll need to set which certificate authorities you're willing to sign so here's an example here I've got keys.mayfirst.org and I've got a copy of the certificate authority that I think is going to sign it this is in there's other leakage that can happen here but keys can embed what key server they should be updated from so that every time you look at them GPG goes out and fetches from there that's kind of a phone home feature which is a little bit creepy but by default it's set to true so I've got key server options in GPG.conf again key server options no honor key server URL I've got showUID validity turned on and verify options and list options so that whenever I see a key I can I'll also see the key there'll be the key in the user ID and GPG will always show me what it thinks I believe about the validity of that user ID so just by adding showUID validity to those it's useful I only make certifications using a strong digest SHA 512 and when I make new keys I prefer to make them these are the digest that I publish about what I use I also do key ID format 0x long so that I never see 8 character key IDs anymore I just see 16 character key IDs if you just drop that one line near GPG.conf it'll let you, it'll move you away from having an obvious interface that just suggests that you use 8 characters which we know to be trivially compromisable that would be probably a good default to add to the package I've been pushing upstream to try to try to change this key ID format default and they haven't done it yet but I think pushing for that and pushing for the removal of the v3 keys they've opted to go for the removal of the v3 keys which is a stronger win so I'm happy with that for now but we also could change defaults within Debian there's also an open bug I think in GPG suggesting that we set some of these as defaults okay the time is up so we're going to end shortly and I don't know maybe people who are within Debian who are interested should talk about whether we're willing to diverge from upstream GPG on the defaults if we think they're not moving in the direction that we want so there's a lot more discussion to be had and I'm sorry that it was more me talking at you than I wanted it to be but if you find me or any of the other people around at the conference and you've got questions about it or other ideas I hope that you'll take the time to stop and have a discussion I would be happy to talk about it more one last question we need to give our video team crew a break between talks so thank you all for coming and yeah I hope your key management goes well thank you Daniel as he said the amount of information we can continue digging in this subject is huge I hope well there was something in this talk for everybody for every level