[00:00.340 --> 00:01.400]  Can we get rid of this thing?
[00:01.940 --> 00:03.280]  This is Jamie.
[00:04.460 --> 00:08.520]  We, among other folks, we're two of the folks who work on the MonkeySphere project.
[00:08.660 --> 00:13.220]  We're going to talk about fixing authentication on the network today.
[00:14.580 --> 00:18.120]  So I'm just going to go ahead and dive right in.
[00:18.360 --> 00:21.100]  If you have questions, you should feel free to raise your hand.
[00:21.140 --> 00:23.000]  I'm happy to engage with questions during the talk.
[00:25.440 --> 00:28.500]  We're going to sort of take turns on pieces of it.
[00:28.600 --> 00:35.120]  I'm probably going to be doing most of the initial speaking, but anyway, we'll have room for questions at the end too.
[00:35.800 --> 00:36.520]  So, okay.
[00:36.840 --> 00:39.560]  So the first question is, what's broken?
[00:39.700 --> 00:40.280]  What's the problem?
[00:40.460 --> 00:41.700]  What do we need to fix, right?
[00:41.800 --> 00:43.140]  Why this talk is fixing authentication?
[00:43.560 --> 00:57.260]  So, and then just the general outline here, we're going to talk about in particular, a problem with some really common forms of cryptographic authentication on the net, and then how we're going to fix it with OpenPGP and the MonkeySphere.
[00:59.940 --> 01:07.320]  So, just as a check here, folks know about OpenPGP here, right?
[01:07.920 --> 01:15.820]  It's so nice to look at a room full of people and know that there are probably a lot of people in here who know about OpenPGP, but some of you all don't, and we're going to explain some pieces of it too.
[01:16.260 --> 01:16.820]  So, okay.
[01:16.940 --> 01:18.140]  So why is authentication important?
[01:18.320 --> 01:19.820]  This is the what's broken part here.
[01:22.000 --> 01:31.700]  So, when we're communicating over a mediated network, one of the main problems is that messages that you want to be confidential can be sniffed by somebody who you maybe don't want to read them.
[01:32.740 --> 01:34.600]  So, there's a privacy issue.
[01:34.820 --> 01:37.920]  That's not exactly about authentication, but it is about privacy, right?
[01:38.640 --> 01:39.860]  We don't want that to happen.
[01:39.940 --> 01:43.720]  Another issue is that somebody might send you a message and you don't know who that message actually came from.
[01:43.960 --> 01:48.720]  It says, you know, let's meet at the pier at 8 p.m.
[01:49.180 --> 01:53.420]  Well, is that the person you're trying to meet at the pier at 8 p.m., or is that somebody else luring you out to the pier?
[01:54.780 --> 01:56.960]  Just, you know, if you're cagey like that.
[01:57.080 --> 02:02.280]  But the message might also say, yeah, let's go ahead with that plan at work.
[02:02.560 --> 02:11.000]  It might also say, you know, no, you know, don't worry about paying me back that loan.
[02:11.360 --> 02:15.480]  There's a whole bunch of things that the messages could say, and it would be nice to know who it was sent.
[02:15.480 --> 02:19.260]  So, authentication is a pretty obvious requirement for solving some of...
[02:19.260 --> 02:21.020]  Sorry, am I going in and out here?
[02:21.180 --> 02:21.940]  Are you guys okay?
[02:22.160 --> 02:22.880]  Volume-wise?
[02:23.780 --> 02:26.780]  So, it's an obvious requirement for solving the second problem, right?
[02:26.860 --> 02:28.020]  Message origins being dubious.
[02:28.260 --> 02:32.080]  But authentication is also a requirement for the first problem, the confidentiality.
[02:32.300 --> 02:37.620]  So, when you have a communication over a mediated network, you can't have a confidential communication.
[02:37.620 --> 02:45.040]  Confidential means only the parties that I want to have access to the content of the communication have access to it.
[02:45.420 --> 02:50.880]  So, if I don't know who the other side of the party is, then I can't have confidential communication.
[02:51.140 --> 02:55.420]  Otherwise, I'm having a private conversation with somebody.
[02:55.620 --> 02:56.900]  That doesn't actually mean anything.
[02:57.300 --> 03:02.900]  So, in order to actually have good private communication, you actually need to know who the other party is.
[03:02.900 --> 03:15.120]  Now, you might be willing to accept anonymous communications from somebody else, but if they don't know who you are, at least one side of it has to actually be authenticated for it to actually be potentially confidential.
[03:15.340 --> 03:22.580]  So, here's one existing method that we currently use today to authenticate things on the network.
[03:22.720 --> 03:23.620]  So, open SSH.
[03:24.220 --> 03:27.540]  Many of you use open SSH or run SSH servers probably.
[03:28.740 --> 03:30.240]  You've probably seen this a lot.
[03:30.980 --> 03:32.440]  This is meaningless.
[03:33.260 --> 03:33.620]  Right?
[03:33.920 --> 03:36.580]  Regular people look at this and they say, uh...
[03:36.580 --> 03:36.940]  Yes.
[03:37.180 --> 03:37.620]  Yes.
[03:38.080 --> 03:38.520]  Yes.
[03:38.680 --> 03:38.940]  Oh, yeah.
[03:39.420 --> 03:39.860]  Totally.
[03:40.120 --> 03:40.540]  That's it.
[03:41.600 --> 03:47.940]  So, this is a real problem because when you say yes here, what you're doing is you're saying, yes, I'm sure that this is the host that I'm trying to connect to.
[03:48.320 --> 03:54.460]  If it... a heavily mediated network means that there's lots of points in between that could be taking over that connection.
[03:54.460 --> 03:59.400]  And so, if you just say yes here and cross your fingers, you don't really know who you're getting.
[03:59.640 --> 04:01.080]  Now, this provides some continuity.
[04:01.560 --> 04:10.440]  Like, you can be sure that the next time you connect, it probably isn't something that changed, but there are other issues with this on top of it being totally incomprehensible to the average human being.
[04:11.180 --> 04:12.120]  So, okay.
[04:12.220 --> 04:13.360]  So, that's OpenSSH, right?
[04:13.420 --> 04:14.500]  The key is provided in the wire.
[04:14.640 --> 04:15.300]  You have your client.
[04:18.560 --> 04:23.000]  There's an encrypted tunnel, an anonymous tunnel, sort of, that it sets up to the server.
[04:23.120 --> 04:24.680]  And the server provides its public key.
[04:24.920 --> 04:26.840]  So, basic public key cryptography.
[04:28.700 --> 04:33.400]  It's fancy math, but basically you have a secret thing that you hold and you have a public thing.
[04:33.720 --> 04:37.980]  And you want to provide that public thing to the other party.
[04:38.180 --> 04:39.340]  The math works great.
[04:39.340 --> 04:43.420]  The problem is how do you connect these keys to the parties in question?
[04:44.420 --> 04:46.580]  So, in SSH, you know, we saw that prompt.
[04:46.740 --> 04:48.020]  That's what's actually happening on the wire there.
[04:50.280 --> 04:53.280]  So, one thing you could do is you could call somebody up on the phone.
[04:53.400 --> 04:57.240]  Usually what happens sort of out of band of this is nothing, right?
[04:57.480 --> 05:01.320]  So, but you could also call your admin on the phone.
[05:01.460 --> 05:05.520]  Who here has ever called their administrator and said, is this the proper host key fingerprint?
[05:06.180 --> 05:07.260]  I am the administrator.
[05:07.880 --> 05:08.480]  All right.
[05:09.200 --> 05:12.500]  Who here as an admin has gotten such a call from the users?
[05:13.660 --> 05:14.220]  All right.
[05:14.400 --> 05:14.480]  Wow.
[05:14.600 --> 05:17.380]  That's like the most hands I've ever seen raised for that question.
[05:17.500 --> 05:18.080]  That's pretty awesome.
[05:18.280 --> 05:20.040]  It's still pitiful.
[05:21.540 --> 05:22.840]  I'm glad you guys did it.
[05:22.960 --> 05:25.240]  But the proportions are really, really low.
[05:25.360 --> 05:27.700]  We're not doing authentication in that sense right now.
[05:28.740 --> 05:30.360]  Realistically in most connections.
[05:31.560 --> 05:35.040]  So, what we want is we'd like to have a smoother way of handling that.
[05:35.260 --> 05:37.620]  So, here's another way that we do authentication on the network today.
[05:37.620 --> 05:39.000]  So, here I'm going to a bank.
[05:39.260 --> 05:39.780]  Excuse me.
[05:39.960 --> 05:40.580]  Going to a bank.
[05:41.040 --> 05:42.400]  It's the Seattle Metropolitan Credit Union.
[05:42.560 --> 05:43.600]  It's their secure website.
[05:43.740 --> 05:46.340]  I'm about to type in some highly confidential financial information.
[05:48.540 --> 05:50.940]  So, I'm connected with this web browser.
[05:51.880 --> 05:53.920]  And there's a little lock down in the corner.
[05:54.100 --> 05:56.720]  And if I hover over the lock, it says authenticated by VeriSign.
[05:58.200 --> 05:59.460]  Who the hell is VeriSign?
[06:00.220 --> 06:00.320]  Right?
[06:00.780 --> 06:01.880]  Is VeriSign my bank?
[06:03.120 --> 06:05.400]  Could VeriSign authenticate somebody else as my bank?
[06:05.480 --> 06:07.420]  This is a classic man-in-the-middle attack concern.
[06:07.800 --> 06:12.080]  And if I trust VeriSign, then VeriSign is able to be the man in the middle.
[06:12.640 --> 06:15.280]  By the way, I never configured my web browser to trust VeriSign.
[06:16.320 --> 06:18.600]  Nonetheless, it seems to work like this.
[06:19.320 --> 06:20.240]  That's a bad thing.
[06:20.600 --> 06:21.700]  So, X.509.
[06:21.820 --> 06:22.980]  This is like the SSH connection.
[06:23.300 --> 06:23.380]  Right?
[06:23.740 --> 06:26.060]  So, instead of passing the raw public key, you pass a certificate.
[06:26.060 --> 06:29.280]  The certificate is this thing in the middle of the pipe here.
[06:29.400 --> 06:31.100]  I'm pointing at the screen, which you guys can't see.
[06:31.200 --> 06:31.660]  That's kind of dumb.
[06:34.480 --> 06:38.160]  So, the authentication...
[06:39.100 --> 06:39.460]  Exactly.
[06:41.100 --> 06:44.120]  So, in this case, we actually have a little bit of out-of-band communication.
[06:44.200 --> 06:55.720]  The web browser has the certificate authority's own certificate, which amounts to basically all we care about is the certificate authority's public key, stored by default in the web browser.
[06:55.720 --> 06:56.980]  That's VeriSign right there.
[06:57.540 --> 06:59.000]  CA is the certificate authority.
[06:59.240 --> 07:04.040]  So, here, our client already knows about X because it knew about it when we downloaded it.
[07:04.400 --> 07:09.260]  And when we get the certificate, we can check that that seal that was on that certificate is actually right.
[07:09.420 --> 07:10.620]  So, what's this certificate?
[07:10.860 --> 07:10.900]  Wait.
[07:11.060 --> 07:11.640]  Go back real quick.
[07:11.840 --> 07:16.200]  Just so I want to point out, there's not a seal on this, which I think is important.
[07:17.000 --> 07:18.580]  Technically, there's a self-seal.
[07:18.760 --> 07:19.540]  It's stamped itself.
[07:19.740 --> 07:19.860]  Right.
[07:19.860 --> 07:22.540]  But you can't verify it itself.
[07:22.700 --> 07:26.120]  The reason that you're trusting it is because it was shipped with your browser.
[07:26.680 --> 07:28.560]  We can argue about whether that's actual trust.
[07:29.020 --> 07:34.560]  So, the common patterns here is that one peer shows the other peer its public key, maybe in a certificate during a session.
[07:35.540 --> 07:37.000]  And notice the direction here.
[07:37.080 --> 07:39.480]  This is about us authenticating the bank.
[07:39.580 --> 07:43.600]  This is about us authenticating the remote server, not the other direction.
[07:44.060 --> 07:47.480]  Now, you can also use these technologies to go in the other direction.
[07:47.640 --> 07:48.420]  Not that many people do.
[07:48.600 --> 07:51.960]  Who here uses SSH public keys as a user?
[07:53.320 --> 07:54.020]  All right.
[07:54.540 --> 07:54.980]  Nice.
[07:55.300 --> 07:58.880]  And who here uses X.509 client certificates on the web?
[08:01.400 --> 08:01.840]  Wow.
[08:02.060 --> 08:02.260]  Okay.
[08:02.540 --> 08:02.860]  All right.
[08:03.000 --> 08:03.220]  Cool.
[08:03.560 --> 08:05.040]  People are using some of that.
[08:05.360 --> 08:06.060]  It's pretty uncommon.
[08:06.240 --> 08:08.580]  Usually, we use super crappy things like passwords.
[08:09.000 --> 08:10.300]  We're not going to go into that right now.
[08:10.700 --> 08:11.040]  So, okay.
[08:11.040 --> 08:12.980]  So, what's the certificate for X.509?
[08:13.980 --> 08:17.500]  It's an identity that's bound to a public key.
[08:18.080 --> 08:20.260]  And the whole thing is signed by a certificate authority.
[08:21.360 --> 08:24.720]  Does that make sense as far as the way the public key stuff works?
[08:24.940 --> 08:27.260]  Another way to look at it is, hey, there's the certificate authority.
[08:27.260 --> 08:31.800]  And it says, I'm telling you, this thing has this public key.
[08:31.980 --> 08:33.580]  This is how we're binding these things together.
[08:33.980 --> 08:36.540]  Concretely, VeriSign was saying that's the bank.
[08:37.500 --> 08:40.440]  Of course, I have to also know that smcu.org is the bank.
[08:40.440 --> 08:43.440]  So, what happens if you don't believe the certifying authority?
[08:44.140 --> 08:48.580]  Well, there is no certifying authority in SSH.
[08:50.240 --> 08:59.540]  And then on the web, you get pages like this, which are also, I would argue, about as meaningless as that first SSH view, particularly to regular human beings.
[09:00.520 --> 09:05.440]  So, for one thing, all the terminology people use tends to be sort of garbage terminology.
[09:05.780 --> 09:07.860]  The message here says it is untrusted.
[09:08.000 --> 09:08.900]  That's not true.
[09:10.220 --> 09:12.940]  This is an authenticity question, right?
[09:13.080 --> 09:14.660]  We need to know who we're talking to.
[09:14.900 --> 09:20.480]  If I know for sure that I'm talking to George Bush, that doesn't mean it's a trusted connection.
[09:20.700 --> 09:23.320]  It doesn't mean that I trust him, right?
[09:23.900 --> 09:26.180]  It means that I know who he is.
[09:26.440 --> 09:29.480]  So, the issue here is authenticity, not trust.
[09:29.740 --> 09:33.400]  And so, we consistently use the wrong language in a lot of this stuff.
[09:34.200 --> 09:39.140]  However, in that situation where my bank was authenticated by VeriSign, there is a trust issue involved.
[09:39.280 --> 09:40.920]  But it's not about me trusting my bank.
[09:41.060 --> 09:44.800]  It's about me trusting VeriSign to be sure that I'm talking to the bank.
[09:44.800 --> 09:47.720]  And I think that actually is a trust issue.
[09:47.740 --> 09:49.620]  And it's not actually about real human trust.
[09:51.120 --> 09:57.180]  So, for X.509, which is the certificate model that's used for the web, that is...
[09:59.220 --> 10:05.000]  The main problem, and I will argue this quite strongly, is that X.509 has exactly one certifier.
[10:05.320 --> 10:09.320]  When you offer that certificate, only one party can have certified it.
[10:09.440 --> 10:10.160]  And that's it.
[10:10.480 --> 10:12.680]  There's no way to choose trust paths.
[10:12.680 --> 10:14.080]  Maybe I don't trust VeriSign.
[10:14.200 --> 10:14.720]  Maybe I trust...
[10:16.740 --> 10:18.140]  Who's your favorite certificate authority?
[10:19.280 --> 10:20.020]  CN-NIC.
[10:20.160 --> 10:20.220]  Yeah.
[10:20.380 --> 10:23.860]  Maybe I prefer to trust the Chinese Internet Authority over VeriSign.
[10:23.980 --> 10:24.100]  Right?
[10:24.320 --> 10:28.540]  I don't have that choice because that certificate's only been signed by VeriSign.
[10:30.700 --> 10:31.140]  So...
[10:31.140 --> 10:35.940]  And also, I've automatically trusted all of the authorities in my browser.
[10:36.100 --> 10:39.240]  Who knows how many certificate authorities are implicitly trusted in their browser today?
[10:39.420 --> 10:41.620]  Pick your browser and tell me how many there are.
[10:41.720 --> 10:41.940]  Anybody?
[10:47.400 --> 10:49.300]  So he says Firefox and 200.
[10:49.680 --> 10:50.900]  I think Firefox is...
[10:50.900 --> 10:51.340]  80 to 100.
[10:51.480 --> 10:51.720]  Sorry?
[10:52.180 --> 10:52.940]  80 to 100.
[10:52.940 --> 10:53.720]  Oh, 80 to 100.
[10:53.960 --> 10:55.880]  I think actually Firefox is more like 30.
[10:56.220 --> 10:59.100]  I think Internet Explorer right now is about 200 or something.
[10:59.220 --> 11:00.280]  I don't have the exact numbers.
[11:00.460 --> 11:01.200]  It's a lot.
[11:01.400 --> 11:03.000]  And it's weakest link.
[11:04.460 --> 11:22.080]  The point here is that if any one of those is compromised, then the person who controls... or simply malicious... the person who controls that weakest one can compromise all of the network connections if they have access to them by creating a false certificate and doing a man-in-the-middle attack.
[11:24.060 --> 11:24.900]  It's also...
[11:26.620 --> 11:29.100]  It's also difficult to change who you trust.
[11:29.240 --> 11:32.680]  If I say I don't trust VeriSign, then I no longer can really get access to that bank.
[11:32.860 --> 11:36.200]  And so this whole thing is this... it's a social log jam.
[11:36.200 --> 11:38.000]  It's a big mess of relationships.
[11:38.240 --> 11:40.500]  And I'm just going to briefly illustrate that mess of relationships.
[11:40.900 --> 11:42.700]  So this is what we care about.
[11:42.920 --> 11:43.400]  Right?
[11:43.680 --> 11:48.300]  The users want to connect to services that are run by service administrators.
[11:48.700 --> 11:49.180]  Right?
[11:49.300 --> 11:50.660]  So this is the blue here.
[11:50.760 --> 11:51.160]  That's me.
[11:51.300 --> 11:52.840]  And the green there is my bank.
[11:53.660 --> 11:53.920]  Okay?
[11:54.740 --> 11:56.360]  But the user is using a tool.
[11:56.540 --> 11:56.740]  Right?
[11:56.780 --> 11:58.900]  They're relying on the tool to actually have functional crypto.
[11:59.080 --> 11:59.560]  True.
[11:59.860 --> 12:04.440]  But they're also relying on the tool to tell me who's in the certificate authority cartel.
[12:04.440 --> 12:07.000]  Who are these certificate authorities that I should actually trust?
[12:08.460 --> 12:13.780]  And then the service administrator has to go to the certificate authority cartel and basically purchase.
[12:13.900 --> 12:14.820]  This is a business model.
[12:15.000 --> 12:16.240]  It's an amazing business model.
[12:16.380 --> 12:20.200]  If you can get a business where what you do is you sell large numbers to people, do it.
[12:20.620 --> 12:21.400]  It's awesome.
[12:23.500 --> 12:27.600]  So they go to the certificate authority cartel, and they make a deal with the certificate authority cartel.
[12:28.020 --> 12:41.740]  And now that they've made that deal, they've got that single certifier certificate, Then I, as the user, now have a relationship with the CA cartel that I have to keep because I want to keep going to that user, to that service, right?
[12:41.980 --> 12:46.760]  So all of a sudden now I have to have this relationship with the CA cartel, independent of what tool I'm using.
[12:47.180 --> 12:59.580]  If my web browser was to say, drop VeriSign as a default, which you might argue would be a reasonable thing to do, all of a sudden, if I'm a naive user, I would howl, your update broke my connection to my bank.
[13:00.260 --> 13:04.680]  Because I can no longer... because the bank has already made the agreement with VeriSign.
[13:05.400 --> 13:16.900]  And then, of course, now there's a relationship also between the service administrators and the tool vendors, in that the service administrators, when they choose which certificate authority to use, they choose it by looking at what web browsers their users use,
[13:16.980 --> 13:21.280]  and what are the default lists, because no one's actually explicitly setting any of these things, because you can't.
[13:21.640 --> 13:25.080]  I mean, you technically can, but, well, another show of hands.
[13:25.140 --> 13:25.640]  Who does?
[13:25.640 --> 13:29.960]  Who here has actually removed entities from their trusted certificate authorities list?
[13:30.380 --> 13:31.640]  Just the China one.
[13:31.640 --> 13:32.800]  Just the China one.
[13:33.080 --> 13:35.840]  Okay, who has removed anything other than China?
[13:37.320 --> 13:38.200]  Okay, good.
[13:38.500 --> 13:40.660]  And who here has removed all of them?
[13:41.860 --> 13:43.720]  All right, very interesting.
[13:43.980 --> 13:46.020]  I want to hear about how you browse the web at some point.
[13:48.900 --> 13:49.340]  So...
[13:49.340 --> 13:51.600]  A really good Firefox add-on.
[13:51.720 --> 13:53.180]  A really good Firefox add-on.
[13:53.260 --> 13:53.780]  Okay, cool.
[13:53.940 --> 13:55.380]  I want to talk with you about that afterwards.
[13:55.560 --> 13:55.920]  That's great.
[13:56.980 --> 13:57.420]  So...
[13:58.760 --> 13:59.640]  Yes, well...
[14:05.280 --> 14:05.720]  Yeah.
[14:07.400 --> 14:07.840]  Cool.
[14:08.220 --> 14:12.820]  So, who here has actually added certificate authorities to their list of trusted certificate authorities?
[14:14.080 --> 14:14.520]  Okay.
[14:14.860 --> 14:17.820]  Anybody want to call out a favorite one that you think other people should add?
[14:17.820 --> 14:18.480]  Mine.
[14:18.780 --> 14:18.940]  Mine.
[14:19.260 --> 14:19.820]  Oh, yeah.
[14:20.100 --> 14:20.360]  Right.
[14:20.520 --> 14:21.760]  Let's all do that at HOPE, right?
[14:21.860 --> 14:22.640]  Let's all do it.
[14:23.300 --> 14:23.940]  So, okay.
[14:24.080 --> 14:26.340]  So, let's get back to me talking to my bank here.
[14:26.420 --> 14:27.260]  Who do I really trust?
[14:27.380 --> 14:29.520]  Do I really trust these various entities?
[14:29.980 --> 14:30.840]  Let's do a browser.
[14:31.140 --> 14:34.400]  Well, I do have to trust my browser, but what about some of these other folks, right?
[14:34.620 --> 14:40.500]  I could trust the University of Washington, who has a relationship with the Seattle Metropolitan Credit Union.
[14:40.580 --> 14:43.000]  I could trust another credit union, the Boeing Employees Credit Union.
[14:43.160 --> 14:45.120]  I could trust the National Credit Union Association.
[14:45.120 --> 14:52.440]  I could trust another credit union from the Mission District in San Francisco, or some other user might trust me.
[14:52.640 --> 14:53.260]  That's me.
[14:53.500 --> 14:54.680]  When I was a little hairier.
[14:56.800 --> 14:58.360]  I'm actually not the Unabomber.
[15:02.040 --> 15:04.720]  So, it says me, and you should trust me.
[15:07.300 --> 15:14.420]  So, why are all of these entities that are out here in this white field, why are they excluded from being the trusted entities?
[15:14.560 --> 15:23.640]  They have a lot more to say about whether this is actually my credit union than does Firefox, or VeriSign, or Starfield, or CNNIC, right?
[15:24.180 --> 15:31.060]  So, how come they're all excluded because of this dense network of relationships that creates this sort of insecure sticking point?
[15:31.220 --> 15:33.100]  So, let's break open the logjam.
[15:33.200 --> 15:34.100]  Well, let's briefly...
[15:34.100 --> 15:39.880]  Maybe we could argue that the logjam will get broken because if they screw up, well, we'd have to kick them out, right?
[15:39.980 --> 15:40.820]  That doesn't happen.
[15:41.180 --> 15:42.500]  It does not happen.
[15:42.500 --> 15:48.620]  We haven't seen major certificate authorities get ejected because you simply can't afford to remove them.
[15:48.880 --> 15:51.420]  If you're a tool vendor, you can't afford to remove VeriSign.
[15:52.100 --> 15:59.440]  So, 2001, VeriSign issued a bogus Microsoft certificate to we don't know who to 2010.
[16:00.080 --> 16:08.340]  Microsoft is not only including them still, but they're actively choosing them to sign off on all of their software deployment for Windows Mobile.
[16:09.420 --> 16:13.440]  RapidSSL, I don't know if you guys remember the hash clash stuff that went on.
[16:13.900 --> 16:14.580]  When was that?
[16:14.900 --> 16:15.300]  2008?
[16:17.160 --> 16:21.820]  Has RapidSSL been removed from your browsers?
[16:21.980 --> 16:23.020]  Oh, no, they don't do that anymore.
[16:23.020 --> 16:23.680]  Don't worry.
[16:24.940 --> 16:28.180]  But there's been no punishment for...
[16:28.180 --> 16:32.120]  There's no demonstration that people actually get ejected from the cartel because of the logjam.
[16:33.180 --> 16:35.960]  And so, some other reasons you might not want to trust people in the cartel.
[16:36.660 --> 16:38.060]  Commercial and historical reasons.
[16:39.880 --> 16:46.380]  So, some of this stuff, the secret key material has been held by multiple different for-profit parties over the course of many years.
[16:46.720 --> 16:49.080]  How secure is a secret that's been held by multiple parties?
[16:49.220 --> 16:51.100]  Especially if it's information that can just be copied.
[16:51.300 --> 16:51.880]  It's not so much.
[16:52.040 --> 16:52.660]  There are governments.
[16:52.860 --> 16:56.080]  I don't care which governments you don't trust, but you can take your pick.
[16:56.320 --> 16:57.140]  You might not trust China.
[16:57.220 --> 16:57.900]  You might not trust Turkey.
[16:58.040 --> 16:58.780]  You might not trust the Netherlands.
[16:58.920 --> 16:59.500]  You might not trust Brazil.
[16:59.720 --> 17:01.300]  They're all in there right now.
[17:01.300 --> 17:04.300]  Look at your list.
[17:04.500 --> 17:09.600]  Those folks can man in the middle any of your TLS connections by being present in that trusted authority.
[17:09.860 --> 17:16.820]  You might not trust them for technical reasons because they do stupid things like using a 1024-bit RSA key that was created in 1998.
[17:18.840 --> 17:23.360]  So, NIST is saying, get rid of RSA, 1024-bit RSA at the end of this year.
[17:23.580 --> 17:24.560]  Do not use it.
[17:24.720 --> 17:24.980]  Period.
[17:26.500 --> 17:29.120]  And even for previous years, it was like, don't use it.
[17:29.200 --> 17:32.760]  Don't expect to use it for more than, you know, three or four years at the max.
[17:32.860 --> 17:34.680]  This is 12 years old now.
[17:35.840 --> 17:38.820]  And there are companies that actively market man-in-the-middle devices.
[17:39.240 --> 17:41.280]  There was a paper on this relatively recently.
[17:43.040 --> 17:45.720]  And there's a bunch of discussion on the TLS working group about them.
[17:46.220 --> 17:50.380]  These folks, the only way to make something like this work is if you actually have a relationship.
[17:52.120 --> 17:58.080]  Either you've already rooted the end user's box, which is the way some of them work, or you have a relationship with a certificate authority.
[17:58.240 --> 18:06.680]  And I don't think anything's been documented of any particular widely trusted certificate authorities selling these men in the middle boxes or partnering with them.
[18:06.760 --> 18:11.340]  But it's not hard to imagine that it would be lucrative, a lucrative quiet deal for somebody in that position.
[18:11.520 --> 18:14.400]  So, we break the log gem with a multi-certifier option.
[18:14.400 --> 18:20.000]  If each certificate can have multiple certifiers, then it breaks the whole thing open.
[18:20.120 --> 18:26.380]  The users can choose now to say, no, no, I don't need to trust VeriSign because the certificate's been signed by some other folks and I trust those other folks.
[18:27.120 --> 18:28.580]  Service administrators get more options.
[18:28.660 --> 18:30.140]  They don't have to just choose from the cartel.
[18:30.380 --> 18:33.840]  The tool vendors don't have to be in the position of shipping the default cartel anymore.
[18:34.020 --> 18:38.920]  Or if they do, it's a much less pressured position the wider the adoption gets.
[18:38.920 --> 18:43.160]  And there's, if we want to, we can remove the weakest link failure mode.
[18:43.360 --> 18:51.620]  You no longer have to say, okay, here's the list of 30 parties that can do a man in the middle attack on all of my connections.
[18:51.700 --> 18:57.400]  You can say, here's 10 parties and I'd like to see two of them corroborate each other's certifications.
[18:58.260 --> 19:02.200]  So it makes it, it starts to make things a little more secure for people who want to choose that.
[19:02.280 --> 19:10.200]  You can still represent the current arrangement, the current, you can still decide I'll trust any of these guys to man in the middle if you want to.
[19:10.400 --> 19:13.180]  But now there's options to start having more nuanced policy.
[19:13.440 --> 19:17.500]  So what's an open, what's a multi-certifier public key infrastructure?
[19:17.860 --> 19:18.520]  We've got one.
[19:18.640 --> 19:19.660]  It's existed for a long time.
[19:19.880 --> 19:20.720]  It's OpenPGP.
[19:22.380 --> 19:24.680]  It's the original social network, right?
[19:24.680 --> 19:30.060]  So you find out who you know and you figure out who they are.
[19:30.280 --> 19:38.060]  And once you've done that key exchange, you can actually have secured and authenticated and potentially private communications with those people over the network.
[19:38.240 --> 19:51.140]  It's usually used for email, but the certification format is just like the certification format we looked at for X.509 in a lot of ways, except that it's multi-certifier capable.
[19:51.800 --> 19:56.020]  And it doesn't provide as nice of a business model for the folks who are already in the cartel, unfortunately.
[19:57.460 --> 19:59.800]  But I'll argue on the business model thing if you want me to.
[20:00.600 --> 20:05.340]  Because I think there is still a business model if we want to let people continue in that position.
[20:06.640 --> 20:08.220]  So why OpenPGP?
[20:08.440 --> 20:15.880]  It turns out it's the authentication that happens in TLS and in SSH is analogous to situations like figuring out email.
[20:17.520 --> 20:19.520]  We want to make sure we're reusing existing tools.
[20:19.700 --> 20:21.380]  We don't want to invent new certificate formats.
[20:21.900 --> 20:27.060]  We don't want to... well, one, we don't want to do that because we'd do it wrong.
[20:27.060 --> 20:31.080]  I'm sure I would do it wrong if I invented a certificate format off the shelf myself.
[20:31.360 --> 20:34.220]  This has a lot of people looking at it over the years.
[20:34.540 --> 20:45.700]  And for two, we don't want to do that because the more that we can get an authentication format to work across a bunch of contexts, the more useful it is to participate in that authentication format.
[20:45.860 --> 20:46.900]  There's a network effect here.
[20:47.300 --> 20:49.340]  So we want to reuse tools for that reason alone.
[20:50.220 --> 20:53.220]  And it turns out we can do it without changing any of the protocols on the wire.
[20:53.720 --> 20:56.460]  So there's this neat out-of-band possibility with OpenPGP.
[20:56.940 --> 20:59.200]  So, okay, quick overview of what we've got.
[20:59.300 --> 21:00.220]  We've got X.509.
[21:00.380 --> 21:01.300]  We've got OpenSSH.
[21:02.260 --> 21:07.400]  We've got... I think people pronounce this Spooky, but I don't actually know anyone who uses it.
[21:08.640 --> 21:09.220]  Spooky, okay.
[21:13.460 --> 21:14.800]  Spooky and Sudsy, all right.
[21:15.800 --> 21:17.260]  I used to be the working group chair.
[21:17.400 --> 21:17.980]  Oh, all right.
[21:18.140 --> 21:18.260]  Cool.
[21:19.280 --> 21:21.600]  I don't think it's actually really widely used right now.
[21:22.100 --> 21:22.880]  No one uses it.
[21:22.980 --> 21:23.300]  Okay.
[21:23.520 --> 21:25.420]  No one uses it, says the working group chair.
[21:25.800 --> 21:26.480]  I'm sorry.
[21:27.600 --> 21:37.000]  And then OpenPGP, which has a fairly wide user base, not anything approaching the user base of X.509, which is included by default with your browser, but OpenPGP is out there.
[21:37.000 --> 21:37.640]  It's been used.
[21:38.000 --> 21:39.940]  And we have some tools.
[21:40.140 --> 21:40.980]  So, more is possible.
[21:43.020 --> 21:44.460]  I already talked about this.
[21:45.220 --> 21:48.880]  So, the out-of-band feature is done with OpenPGP key server network.
[21:49.060 --> 21:53.460]  So, the key server network for OpenPGP is a really neat system that is distributed.
[21:53.640 --> 21:54.460]  It's globally distributed.
[21:54.460 --> 21:55.320]  It is...
[21:56.060 --> 22:00.340]  It's not something that one entity could take control over.
[22:00.580 --> 22:05.000]  It's basically a publish once and it's there forever because it's mirrored around the world.
[22:05.520 --> 22:06.400]  And everybody who...
[22:06.400 --> 22:07.780]  There's a key server network.
[22:07.860 --> 22:08.640]  You can participate in it.
[22:08.720 --> 22:10.180]  You can run a key server if you want to.
[22:10.400 --> 22:14.560]  It requires a couple dozen gigs of hard drive space.
[22:16.520 --> 22:21.040]  And, you know, it doesn't require a super powerful machine, but it needs a machine that's on the network.
[22:23.120 --> 22:25.760]  And you'll get updates to keys as they come in.
[22:26.200 --> 22:29.140]  So, okay, let me step back a second.
[22:29.460 --> 22:34.100]  Another concern that I haven't even addressed in all of this is issues about revocation and re-keying.
[22:34.100 --> 22:41.320]  And one of the things that the key servers let you do is that they let you actually do a re-keying because you can publish new keys.
[22:41.520 --> 22:50.800]  And they let you issue revocations because it's a canonical place, a non-centralized canonical place to publish certificate revocations.
[22:50.980 --> 22:53.880]  So, when would you want a certificate revocation?
[22:54.940 --> 22:55.540]  Compromise.
[22:56.120 --> 22:56.720]  Compromise.
[22:57.000 --> 22:57.220]  Yep.
[22:58.540 --> 22:59.640]  Outdated technologies.
[22:59.800 --> 23:01.040]  Outdated technologies.
[23:01.920 --> 23:02.320]  Expi...
[23:02.320 --> 23:02.720]  Sorry?
[23:06.310 --> 23:07.530]  Expiration is a matter of policy.
[23:07.530 --> 23:07.630]  Expiration is a matter of policy.
[23:07.810 --> 23:10.290]  Just don't have a secret that you're keeping for too long.
[23:10.410 --> 23:10.990]  Plausible deniability.
[23:11.670 --> 23:12.470]  Plausible deniability.
[23:12.630 --> 23:14.470]  Revoke your key and then continue using anyway.
[23:14.930 --> 23:15.210]  Ooh.
[23:15.590 --> 23:15.950]  Okay.
[23:16.610 --> 23:21.830]  So, just for folks who didn't hear, that was plausible deniability if you revoke your key and then continue using it anyway.
[23:22.150 --> 23:23.190]  I have to think about that.
[23:23.310 --> 23:23.830]  That's interesting.
[23:30.380 --> 23:30.480]  Yep.
[23:30.680 --> 23:36.480]  Going out of business, getting acquired, accidentally using a bad library to generate a key.
[23:36.480 --> 23:38.940]  I don't know if anybody here has ever done that.
[23:45.580 --> 23:46.100]  Yes.
[23:46.220 --> 23:48.820]  X.509 has two certificate revocation systems, in fact.
[23:49.200 --> 23:51.060]  Neither of which are actually widely used.
[23:52.460 --> 23:57.180]  They're becoming more widely used, but those are certificate revocation lists.
[23:57.420 --> 23:58.780]  Depends on where you mean.
[23:58.880 --> 24:03.120]  The U.S. military has a CRL so large that the software can no longer load it.
[24:03.620 --> 24:03.980]  Okay.
[24:03.980 --> 24:11.000]  So, the comment was, the U.S. military has a certificate revocation list that is so large that most software can no longer load it.
[24:12.640 --> 24:14.240]  So, that's not very useful.
[24:15.060 --> 24:21.640]  Can you just say something, though, about what happens when you have CRLs in your model and things get widely deployed, which is something you have to worry about?
[24:21.760 --> 24:21.960]  Right.
[24:22.140 --> 24:25.100]  Revocation can break.
[24:25.100 --> 24:25.620]  Yep.
[24:26.120 --> 24:43.520]  And then the other X.509 revocation model is OCSP, the Online Certificate Status Protocol, which is even less widely used than CRLs and basically amounts to a per-connection checkup of, hey, is the certificate still valid, where you go back and you ask the certificate authority.
[24:43.780 --> 24:47.100]  So, it presents another series of potential problems.
[24:48.060 --> 25:01.580]  But anyway, we get revocations and recertifications, expirations, and you can even update your expiration dates for free by taking advantage, again, of existing infrastructure, widely deployed, widely used.
[25:01.580 --> 25:04.520]  Almost not as widely as the web or anything.
[25:04.800 --> 25:06.840]  But the key server network is out there.
[25:07.000 --> 25:07.440]  It's functional.
[25:07.760 --> 25:09.060]  And so, we can just take advantage of it.
[25:09.640 --> 25:10.680]  Do the CRLs...
[25:10.680 --> 25:13.860]  Are CRLs used at all right now, or...?
[25:13.860 --> 25:14.260]  Yes.
[25:14.520 --> 25:16.700]  You can... depending on how you configure your systems.
[25:16.960 --> 25:26.700]  I mean, the fact that the U.S. military is publishing their CRL suggests that there probably is policy within some branches there that you have to have your browser configured to check CRLs every so often.
[25:26.700 --> 25:27.980]  Let me repeat that.
[25:28.040 --> 25:28.520]  There was...
[25:28.520 --> 25:29.820]  Is anybody using it?
[25:30.600 --> 25:31.960]  Is everybody using it?
[25:32.040 --> 25:32.320]  Is everybody using it?
[25:32.320 --> 25:32.340]  No.
[25:32.580 --> 25:33.860]  Everybody is not using CRLs.
[25:34.300 --> 25:37.700]  And if you look at your browser, I don't actually think any of the standard browsers...
[25:38.340 --> 25:40.080]  Seth can answer that probably better than I can.
[25:40.940 --> 25:42.520]  One place that uses...
[25:44.220 --> 25:45.080]  Okay.
[25:45.220 --> 25:48.400]  One place that uses CRLs a lot is digital rights management.
[25:54.120 --> 25:54.560]  So...
[25:54.560 --> 25:55.060]  Got
[25:59.250 --> 26:00.710]  it.
[26:00.890 --> 26:01.050]  Okay.
[26:01.050 --> 26:10.190]  So the comment was that the digital rights management companies are using CRLs to basically disable devices.
[26:10.470 --> 26:14.530]  Saying, here's a list of devices you should no longer send content to.
[26:16.190 --> 26:18.190]  So there's a place where they're being used.
[26:18.690 --> 26:19.810]  Maybe not for good.
[26:21.930 --> 26:22.410]  So...
[26:22.410 --> 26:22.570]  Okay.
[26:22.710 --> 26:24.630]  So, quick visualization overview.
[26:25.070 --> 26:26.670]  SSH out of the box looks like this.
[26:28.230 --> 26:34.170]  And then we use the key server network represented by this little cloud to get a certificate from the key server.
[26:34.270 --> 26:35.350]  It's an open PGP certificate.
[26:35.690 --> 26:37.790]  And in this case, there's two certificates.
[26:37.930 --> 26:39.730]  That represents the sort of multi-certifier nature.
[26:40.030 --> 26:47.310]  This client can decide whether they trust certifier Y or certifier Z or neither or both to make the certification.
[26:50.130 --> 26:52.410]  And then here's the standard...
[26:52.410 --> 26:54.810]  So then here's the web doing the same thing.
[26:55.830 --> 26:56.810]  So you can...
[26:56.810 --> 26:58.990]  It doesn't matter that this has been certified by X.
[26:58.990 --> 27:02.350]  If all I care about is certifications by Y and Z, we can use the same model.
[27:03.490 --> 27:03.930]  So...
[27:04.750 --> 27:10.250]  So the overall goal is we want open PGP certificates to be used in as many contexts as possible.
[27:10.430 --> 27:11.270]  We've got email.
[27:11.610 --> 27:12.770]  We've got SSH functioning.
[27:12.990 --> 27:14.950]  We've got HTTPS in one direction.
[27:15.170 --> 27:18.030]  If folks are interested in the other direction, talk to me.
[27:18.030 --> 27:25.090]  I want to see client certificates as well, as problematic as client certificates are, especially in the face of the renegotiation attacks.
[27:25.370 --> 27:30.030]  But we need to have the infrastructure in place once those fixes actually do propagate out.
[27:30.650 --> 27:37.050]  And then there's other mechanisms where we can potentially start injecting the open PGP certificates in the stream themselves so it's not out of band anymore.
[27:37.250 --> 27:39.250]  We don't need to do that absolutely.
[27:39.610 --> 27:41.250]  It's probably a good idea for performance.
[27:41.250 --> 27:44.410]  But the point here is we can ramp this up, right?
[27:44.650 --> 27:47.410]  We can start by leaving all the bits on the wire exactly the same.
[27:49.470 --> 27:58.490]  And people can start authenticating using trust models that are actually more closely connected to the way humans think and not to these default weird business models.
[27:59.150 --> 28:08.370]  And then we can also, in the process, we can then start looking at things like RFC 5081, which is open PGP keys within a TLS session.
[28:09.090 --> 28:13.530]  And we can start pushing for those as performance improvements, which I do think we will need.
[28:14.810 --> 28:16.510]  Can you tell me about TLS's name?
[28:16.830 --> 28:18.490]  TLS is transport layer security.
[28:18.790 --> 28:23.910]  So HTTPS is standard HTTP over a transport layer security tunnel.
[28:24.130 --> 28:31.090]  And transport layer security is the successor to SSL, the secure sockets layer, which you may or may not have heard of.
[28:31.290 --> 28:40.470]  But so TLS is the name going forward of what we're supposed to call it because Netscape owned the copyright for SSL, I think.
[28:41.270 --> 28:44.670]  But I'm sure there are other variants of why we're switching the terminology to TLS.
[28:44.810 --> 28:46.110]  But TLS is the term these days.
[28:47.410 --> 28:48.070]  IETF politics.
[29:00.540 --> 29:01.200]  IETF politics.
[29:01.720 --> 29:02.120]  IETF politics.
[29:02.120 --> 29:02.260]  And I think it's the same.
[29:02.260 --> 29:07.900]  And because the sheer amount of time is that you can set up your trust and that you can set up your trust networks.
[29:08.360 --> 29:10.780]  Especially for a user who doesn't have to know what your trust needs.
[29:11.300 --> 29:18.320]  So how do you plan, how do you plan, how do you plan, how do you plan in some ways to avoid the whole issue of the process of speaking authorities?
[29:18.760 --> 29:21.060]  Because nonetheless, the user-tacking...
[29:24.170 --> 29:29.470]  Okay, so the question for folks who didn't hear it was, the reason...
[29:29.950 --> 29:37.770]  The proposal was that the reason that people aren't using OpenPGP as widely is because of the immense amount of work that it takes to set up your trust network.
[29:38.150 --> 29:46.490]  Particularly for users who don't understand what the word trust means, who are perhaps confused by systems that use the word trust wrong or whatever.
[29:46.490 --> 29:54.530]  So, how do we propose to have this work without forcing users to go through the painful process of setting up their trust network without trusting certificate authorities?
[29:55.310 --> 29:56.950]  One...so there's a bunch of ways to answer that.
[29:57.210 --> 30:00.970]  One way to answer is, you can still trust certificate authorities in this model.
[30:01.470 --> 30:05.190]  If all you care about is, I actually do trust VeriSign, you can do that.
[30:05.390 --> 30:10.050]  And you can...and we can set up default trust along those lines if we want to.
[30:10.590 --> 30:15.690]  So, there's room for existing certificate authorities to set themselves up as OpenPGP certificate
[30:20.250 --> 30:30.290]  Another answer is, well, you can actually leave all the X.509 stuff in place and leave the SSH stuff in place and we just want to provide more ways that it is useful for you to set up a trust network.
[30:30.430 --> 30:42.130]  Even if your initial trust network is just me and my buddy and we each have accounts on each other's SSH servers, then that's, you know, that's a trust network that's worthy of actually being able to authenticate and rekey the machines.
[30:42.130 --> 30:46.710]  So the more reasons you have to build the trust network, I think the more incentive there will be to build it.
[30:46.890 --> 30:51.910]  Let me just comment very briefly that we definitely do acknowledge, though, that that's a challenge.
[30:52.650 --> 31:00.670]  That's probably the biggest impediment right now for widespread use of OpenPGP, in my opinion, is developing these trust networks.
[31:00.930 --> 31:10.210]  So we need better tools to make it easier for people to do that in a way that makes sense and is not stupid.
[31:10.790 --> 31:22.130]  Yeah, and actually, if any of you guys are user interface folks who enjoy thinking about this and want to help figure out how to visualize it, I would love to talk to you about it.
[31:22.130 --> 31:33.670]  Because good key management, so trust and, like, actual trust, knowing who someone is and deciding whether you think that they can introduce you to people and you believe them.
[31:34.110 --> 31:36.710]  That's a natural thing for humans to do, right?
[31:36.890 --> 31:38.090]  We do this all the time.
[31:38.090 --> 31:40.710]  Like, I've known this guy for a long time.
[31:40.710 --> 31:48.030]  If he tells me that, you know, here's, here's, you know, so-and-so, my professor, well, you know, I'm gonna believe him.
[31:48.350 --> 31:49.690]  Because I know who he is.
[31:49.770 --> 31:52.170]  And I don't even have to, I don't even have to think about it that much.
[31:52.370 --> 31:55.010]  So it would be nice to be able to take advantage.
[31:55.250 --> 31:57.090]  This is something humans already do really well.
[31:57.390 --> 31:59.470]  Why are our tools so bad at doing it?
[31:59.470 --> 32:03.550]  What we want to do is we want to make the tools expand what the humans are already good at doing.
[32:04.330 --> 32:06.990]  Which is where the name Monkeysphere comes from, for those who are curious.
[32:07.190 --> 32:07.330]  Yeah.
[32:10.550 --> 32:10.950]  Question.
[32:11.190 --> 32:12.870]  I actually work for one of the CEOs.
[32:13.090 --> 32:22.650]  And the question I've had about PGP over the years is, although we're not perfect, before we sign a cert or issue one, we do a certain level of validation on the entity.
[32:23.230 --> 32:31.170]  We do, we make a certain limited, and yes, you could probably run some social engineering attacks and get a cert that you're not supposed to have.
[32:31.390 --> 32:35.050]  But for the most part, we verify to whom we're issuing the cert.
[32:35.210 --> 32:45.610]  And then we assure the public, yes, we issued the cert to this company that's listed in this business directory that does business, this address that we've done a reasonable amount of due diligence to verify.
[32:46.330 --> 32:48.930]  Does open PGP propose to do any of that?
[32:49.090 --> 32:49.990]  And if so, what?
[32:51.270 --> 32:59.730]  So the question was from someone who's working at a certificate authority saying, hey, we do some legitimate verification, and does open PGP propose to do that?
[32:59.870 --> 33:03.750]  My answer to you is, I'm very grateful to you for doing the services that you're doing.
[33:03.990 --> 33:05.350]  Your verifications are very useful.
[33:05.630 --> 33:09.150]  However, I don't necessarily need to trust you.
[33:09.410 --> 33:11.630]  I could trust somebody else to do the same verifications.
[33:12.210 --> 33:18.530]  And so, if I know you, and I know that you're the one who's actually doing the certifying, and I know what your policies are, then yeah.
[33:18.870 --> 33:24.990]  And if you're actually doing good diligence, there's no reason to totally reject these certificate authorities out of hand.
[33:25.130 --> 33:27.150]  However, the certificate authorities are compromisable.
[33:27.850 --> 33:29.790]  They have... some of them have crappy policies.
[33:29.870 --> 33:31.750]  The ones that have good policies, the policies can be broken.
[33:32.030 --> 33:35.630]  And so, the same issue holds for anybody doing any certification.
[33:35.830 --> 33:37.630]  X.509, OpenPGP, whatever.
[33:37.630 --> 33:43.310]  I want to break the log jam so that there isn't a cartel that actually holds those keys.
[33:43.710 --> 33:46.410]  Because right now, it's insecure because there's no way to get out of that cartel.
[33:46.690 --> 33:51.730]  Everybody's just agreeing to trust this group of corporate middlemen to actually make the certifications.
[33:51.970 --> 33:55.210]  So, I'm not saying every certification made by a CA is bad.
[33:55.530 --> 33:58.250]  I'm saying, I don't want to have to trust this cartel.
[33:58.370 --> 34:00.170]  But there's also the issue of the weakest link.
[34:00.310 --> 34:13.230]  So, even if one certificate authority is doing a really good job of checking, the fact that my browser automatically trusts a different certificate authority that could be doing nothing, or being malicious, completely nullifies all of the work that you've done.
[34:13.350 --> 34:15.290]  It makes it completely useless.
[34:15.650 --> 34:17.650]  So, I mean, I don't know why...
[34:18.450 --> 34:30.230]  I mean, again, no offense to you, but your business model is completely subverted by the fact that some other entity that you have no association with at all could just be maliciously subverting your work.
[34:30.230 --> 34:33.670]  So, I actually would call on people who work at certificate authorities.
[34:34.030 --> 34:35.630]  If they want to, come talk to me.
[34:35.790 --> 34:40.930]  I would love to talk to you about how you can issue open PGP certificates alongside your X.509 certificates.
[34:41.210 --> 34:45.190]  I actually think that there's a room for some differentiation there as a business model.
[34:45.390 --> 34:51.030]  You can be the certificate authority that will issue open PGP certifications as well as X.509 certifications.
[34:51.950 --> 34:55.770]  And I'd be happy to talk about what the consequences of that would be and how it would actually be done.
[34:56.770 --> 34:58.510]  I want to get through a few more slides.
[34:58.510 --> 35:00.390]  Can you hold your questions for a little bit?
[35:02.390 --> 35:04.490]  So, quick visualization, how it is now.
[35:04.630 --> 35:08.290]  I think you guys got this point here and how it could work with the monkey sphere, right?
[35:08.510 --> 35:10.930]  Got a bunch of folks able to say the same thing.
[35:12.790 --> 35:14.370]  Surprising, potentially, technical observations.
[35:14.610 --> 35:17.170]  One is that we actually didn't need to make changes on the wire.
[35:17.410 --> 35:19.930]  I thought that was a pretty nice result.
[35:21.150 --> 35:28.970]  Not that we can't make changes on the wire, but it's a lot harder to deploy changes on the wire X.509 model.
[35:29.190 --> 35:32.810]  The way that the certification is done is actually a subset of what you could do with OpenPGP.
[35:33.130 --> 35:37.410]  So, if you really actually like the current hierarchical model, you can do it with OpenPGP.
[35:37.510 --> 35:39.130]  There's no need for X.509.
[35:39.330 --> 35:42.710]  Just use OpenPGP certificates to create your hierarchical structure.
[35:43.310 --> 35:43.590]  Done.
[35:43.790 --> 35:52.150]  And for people who know anything about OpenPGP, the analogous X.509 model in OpenPGP speak is pretty absurd.
[35:52.150 --> 35:56.610]  You have like a trust depth of like, you know, 10 or something.
[35:56.750 --> 36:00.110]  Yeah, it's ultimate owner trust on like several dozen keys with a depth of 10.
[36:00.110 --> 36:03.930]  Something that you would never, ever, ever do with your OpenPGP keys.
[36:05.070 --> 36:09.490]  And then another interesting observation is that for TLS anyway, this actually fixes...
[36:09.490 --> 36:13.250]  For HTTPS, it fixes the multiple sites per IP port combination.
[36:13.710 --> 36:17.570]  Also fixed with a TLS extension, which is the server name extension.
[36:17.570 --> 36:21.650]  But it turns out you can have one key in OpenPGP.
[36:21.790 --> 36:24.910]  You can not only have multiple certifications, but you can have multiple user IDs attached.
[36:25.150 --> 36:28.710]  So you could have the one key and you could say these three websites are served by that key.
[36:28.990 --> 36:36.310]  And then individual certifiers can certify one or the other or all or whatever of those identities.
[36:36.650 --> 36:44.550]  And so you can actually solve that problem this way without having to have both server and client have this on the wire change of supporting the server name.
[36:45.730 --> 36:49.370]  So, and it works today, just to be clear, this is not all pie in the sky stuff.
[36:49.530 --> 36:51.150]  It works with unpatched OpenSSH.
[36:51.670 --> 36:53.050]  We have a Firefox extension.
[36:53.310 --> 36:55.270]  It works with any TLS capable web server.
[36:55.770 --> 36:59.210]  And if you adopt it, how many of you here run servers or administer servers?
[37:00.870 --> 37:01.270]  Nice.
[37:02.170 --> 37:08.610]  And how many of those services that you administer have crypto, whether it's OpenSSL or OpenSSH?
[37:08.930 --> 37:13.390]  How many hands do you have?
[37:16.470 --> 37:25.590]  So, you can adopt this for your server without sacrificing the existing users who maybe can't currently verify things via OpenPGP.
[37:25.750 --> 37:37.430]  You can participate in this and without breaking any of the existing stuff, any of the existing already broken infrastructure, you can leave that broken infrastructure intact and the folks who have to use it will keep on using it.
[37:37.430 --> 37:45.570]  But, you can also use OpenPGP so that the folks who do use OpenPGP now can identify your services.
[37:46.550 --> 37:49.570]  So, this is a quick overview for folks who are running systems.
[37:50.390 --> 37:53.350]  On the server side, you install the monkey sphere package.
[37:53.770 --> 38:00.410]  If you don't have it installed and you don't... it's available in Debian and Ubuntu in different versions.
[38:01.870 --> 38:03.510]  We have a FreeBSD port.
[38:03.610 --> 38:06.750]  If you want to get it to other operating systems, please come, you know, talk to us afterwards.
[38:07.230 --> 38:08.550]  So, you install the monkey sphere package.
[38:08.650 --> 38:09.390]  You say monkey sphere host.
[38:09.530 --> 38:10.110]  Import key.
[38:10.670 --> 38:12.190]  Here's my secret key.
[38:12.810 --> 38:13.990]  And here's the host name.
[38:14.650 --> 38:16.490]  Note that there's the protocol included here.
[38:16.630 --> 38:18.710]  So, this is an SSH key.
[38:18.950 --> 38:20.830]  And we're importing it as SSH with the host name.
[38:21.090 --> 38:22.210]  And then you say publish keys.
[38:22.510 --> 38:22.630]  Okay.
[38:22.890 --> 38:25.130]  The key is now in the OpenPGP key servers.
[38:25.330 --> 38:25.690]  It's public.
[38:27.030 --> 38:30.130]  However, that doesn't solve the problem because your users...
[38:30.130 --> 38:31.210]  Anybody can do this.
[38:31.290 --> 38:35.110]  And your users still don't know that it's actually the host that you've provided.
[38:35.110 --> 38:38.550]  And so, you need to pull the key yourself.
[38:39.450 --> 38:40.790]  Verify its fingerprint, of course.
[38:41.150 --> 38:41.670]  Sign it.
[38:41.950 --> 38:45.090]  And then push your certifications back to the key servers.
[38:45.310 --> 38:45.750]  And that's it.
[38:46.290 --> 38:48.210]  It works the same way for HTTPS.
[38:48.370 --> 38:51.430]  So, you just need to know where your HTTPS secret key is.
[38:51.570 --> 38:54.910]  It's the thing that says begin RSA private key in the top of the file.
[38:56.230 --> 38:58.510]  If you don't know where it is, I can help you find it on your server.
[39:01.390 --> 39:03.810]  So, you can do the exact same thing with HTTPS.
[39:03.810 --> 39:05.550]  This is not a hard process to do.
[39:05.730 --> 39:08.130]  It doesn't change the bits on the wire at all.
[39:08.510 --> 39:12.270]  And it enables a new form of authentication for your users who want to use it.
[39:13.610 --> 39:15.670]  So, again, this is what we started with.
[39:15.810 --> 39:17.290]  This is some garbage for SSH.
[39:18.590 --> 39:20.830]  So, what we should say is no.
[39:22.750 --> 39:26.550]  So, here's an example chunk of configuration for your SSH config.
[39:27.090 --> 39:28.670]  This is just the relevant bit here.
[39:28.830 --> 39:34.470]  For any host, let's just add a proxy command line, which says use the monkey sphere proxy command to connect to the server.
[39:37.050 --> 39:40.170]  And then, so I'm going to copy that into my SSH config.
[39:41.070 --> 39:43.990]  So, as an end user, now I connect to this machine.
[39:44.310 --> 39:46.670]  And the monkey sphere says, oh, got the key.
[39:47.050 --> 39:47.590]  Checked it out.
[39:47.790 --> 39:52.170]  It's certified by somebody that you believe makes reasonable certifications.
[39:52.290 --> 39:54.210]  So, I'm going to go ahead and add it to the known host file.
[39:54.390 --> 39:56.870]  I didn't have to see any of the garbage, right?
[39:56.870 --> 40:00.470]  I wasn't presented with stuff that I don't understand or stuff that I don't know.
[40:01.130 --> 40:02.510]  And then I just have to authenticate myself.
[40:02.710 --> 40:03.250]  And there you go.
[40:03.350 --> 40:03.550]  I'm in.
[40:03.890 --> 40:10.090]  It actually also works in the other direction as well, where your GPG key can now be used to connect to SSH servers.
[40:10.230 --> 40:16.310]  If those SSH servers are configured to authenticate users via the OpenPGP Web of Trust, which is also functional.
[40:16.470 --> 40:17.610]  I don't have a demonstration of it here.
[40:17.810 --> 40:18.070]  Anyway.
[40:18.730 --> 40:20.410]  So, I'm going to open for questions.
[40:20.550 --> 40:23.270]  Just the point, the takeaway here is that authentication is critical.
[40:23.270 --> 40:27.090]  Public key authentication is really useful in both directions.
[40:27.910 --> 40:33.750]  And OpenPGP can be used to solve, you know, many, if not most, of the issues about digital authentication.
[40:34.590 --> 40:35.970]  And we want to get it in more context.
[40:36.150 --> 40:39.570]  So, if you've got ideas for other places that could be used, you know, come talk to us.
[40:49.470 --> 40:51.230]  How much time do we have left?
[40:51.430 --> 40:52.390]  We've got 15 minutes.
[40:52.750 --> 40:53.010]  Cool.
[40:53.250 --> 40:53.370]  Okay.
[40:54.690 --> 40:55.210]  So, yeah.
[40:55.310 --> 40:56.230]  Some questions?
[40:56.930 --> 40:57.370]  Chromium.
[40:58.170 --> 40:58.610]  Chromium.
[40:59.070 --> 40:59.970]  Was that a question?
[41:00.230 --> 41:00.430]  Yeah.
[41:03.430 --> 41:07.150]  So, I'm assuming the question was, do we have extensions for Chromium?
[41:07.450 --> 41:08.550]  The answer is no.
[41:09.290 --> 41:12.750]  If you're interested in working on them, we would love your help.
[41:13.390 --> 41:16.270]  I actually don't even know what the plugin architecture looks like for Chromium.
[41:17.170 --> 41:28.970]  And let me also point out here that depending on the level of the stack you all are interested in working in, you could be writing extensions for web browsers, or you could also potentially be writing plugins for...
[41:32.130 --> 41:34.270]  You could be writing plugins for the crypto layer.
[41:34.710 --> 41:36.150]  So, there are...
[41:36.150 --> 41:43.190]  Whether that's LibNSS, or OpenSSL, or GNU TLS, if we can find ways to get plugins for those that do the certificate authentication, that would be good.
[41:43.190 --> 41:43.930]  Yeah.
[41:44.090 --> 41:45.590]  Just a quick plug for...
[41:45.590 --> 41:53.630]  So, what I put up on the screen here is, this is our website for the project.
[41:54.310 --> 41:56.110]  And it's under HTTPS.
[41:56.110 --> 41:57.270]  You can't really see it.
[41:57.350 --> 41:58.170]  It's cut off at the top.
[41:58.430 --> 42:01.990]  But if you look down at the bottom right, the...
[42:01.990 --> 42:02.170]  Yeah.
[42:02.390 --> 42:13.170]  The little monkey head is what's indicating to me that this site has been authenticated via the monkey sphere, via the Zool extension that we have put together.
[42:13.170 --> 42:13.270]  Right.
[42:13.270 --> 42:18.150]  So, this is just a Firefox extension, and it works by...
[42:18.150 --> 42:18.650]  If it doesn't...
[42:18.650 --> 42:29.530]  If it can't validate it through the standard X.509 model, then it goes to the OpenPG Web of Trust, looks for the key, figures out whether the certification is valid, and then goes ahead with it if it actually is.
[42:30.630 --> 42:38.390]  So, this is Web of Trust, but is there a way to kind of have some metric as to whether or not you want to mistrust on that?
[42:38.470 --> 42:42.650]  Can there be a Web of Mistrust or something that, you know, isn't really...
[42:43.510 --> 42:43.850]  I mean...
[42:43.850 --> 42:47.510]  Well, I mean, it's the whole thing.
[42:47.830 --> 42:48.170]  Right.
[42:48.330 --> 42:50.310]  When does...
[42:50.310 --> 42:56.510]  So, the question was, there's a Web of Trust, and do we have a need for something like a Web of Mistrust?
[42:56.650 --> 42:59.990]  Is there a way to identify when things are not trustworthy?
[43:00.950 --> 43:10.110]  And I think that the default is that we have a universe of mistrust, and we are building a Web of Trust within the universe of mistrust.
[43:10.210 --> 43:11.810]  So, by default, things are mistrusted.
[43:11.930 --> 43:13.370]  But I'd be curious about other people's take on that.
[43:13.370 --> 43:14.190]  You
[43:28.360 --> 43:36.620]  trust a central agency that it's not going to serve you food that's not healthy.
[43:36.860 --> 43:42.180]  When you go to a doctor, you trust one central authority that they're actually licensed to practice medicine.
[43:42.980 --> 43:46.320]  And in fact, you have a certain, you have sort of three levels of trust.
[43:46.780 --> 43:48.680]  You have a deep law, I don't know.
[43:49.320 --> 43:55.060]  You have the, I'm going to trust you because I'm central authority, or my friend happened to have said so.
[43:55.540 --> 43:58.300]  But when you have the level of mistrust, or you're a committed criminal,
[44:01.410 --> 44:02.190]  you know...
[44:02.190 --> 44:02.710]  Okay.
[44:02.910 --> 44:07.690]  So, the comment is that, actually, we have all these different kinds of trust in society.
[44:08.010 --> 44:10.670]  I hope I'm getting this characterizing accurately.
[44:10.910 --> 44:16.410]  And that we trust, for instance, when we go to a restaurant, we trust them not to poison our food, or we trust a central authority to make sure that they're healthy.
[44:17.710 --> 44:20.370]  And that there is actually a default level of trust that we have.
[44:20.510 --> 44:21.750]  So, let me back up a second.
[44:22.770 --> 44:31.470]  The kinds of trust that I'm talking about here, and the kinds of trust that are relevant for the web of trust, are not the kinds of trust that says, it's okay to eat at this restaurant.
[44:31.930 --> 44:35.630]  They're not the kinds of trust that say, this person is a good person.
[44:35.870 --> 44:40.370]  They're not the kinds of trust that say, I've known this person since I was a child.
[44:40.670 --> 44:49.870]  What they are is, the trust in particular is, I trust this person to properly identify other parties.
[44:50.130 --> 44:52.670]  It's a very, very narrow definition of trust.
[44:52.670 --> 44:58.490]  And it's useful to keep it narrow, because we can actually make reasoned inferences if we keep it narrow.
[44:58.710 --> 45:08.130]  And we avoid exposing too, too much of sort of social graph kind of things.
[45:08.590 --> 45:13.110]  If we were to publish things like, oh yeah, this restaurant is great, here's my cryptographic seal of approval.
[45:13.470 --> 45:14.510]  That's a different problem.
[45:14.730 --> 45:16.590]  I'm not trying to address that problem with this.
[45:16.670 --> 45:23.570]  I don't think any of the folks in the monkey sphere are trying to address issues beyond, do I trust these parties to authenticate other people?
[45:23.690 --> 45:28.020]  My point was, you don't have a web of trust.
[45:28.200 --> 45:30.560]  We tend to rely on central authorities.
[45:30.900 --> 45:35.740]  And this conference is... so the comment was, we don't have a web of trust, we tend to rely on central authorities.
[45:36.020 --> 45:40.300]  And this conference is a great example of why that doesn't actually work.
[45:40.880 --> 45:41.320]  Right?
[45:41.560 --> 45:44.540]  What we actually have as a web of trust is we are...
[45:45.400 --> 45:48.360]  I think it's more important to say, because you're saying people naturally do it.
[45:48.360 --> 45:50.740]  But I think people do, people do do it.
[45:51.200 --> 45:55.060]  I mean, I don't need a central authority to tell me that this is my friend Daniel.
[45:55.260 --> 45:57.860]  And I wouldn't even... I mean, it would be absurd.
[45:58.440 --> 45:58.840]  Right?
[45:59.180 --> 46:09.220]  I mean, I think pretty much everybody that I interact with in this room, there's no centralized authority that's told me anything about any of these people that's going to be relevant to my interaction with them at all.
[46:09.220 --> 46:12.000]  This is issued by a centralized authority.
[46:13.660 --> 46:14.360]  That's true.
[46:14.480 --> 46:25.380]  More to the point, one of the biggest lessons we learned from the development of certificate authorities was there was this whole notion that CAs were going to take counterparty risk away.
[46:25.980 --> 46:39.320]  And it turns out that every CA in existence has a practice, you know, statement that more or less says that you gain absolutely nothing in terms of liability protection through the use of the CA.
[46:39.600 --> 46:48.060]  And in fact, any time two businesses interact with each other, there are credit departments and other people, et cetera, and it's an entirely bilateral relationship.
[46:48.620 --> 46:53.160]  And you inject these CAs in who explicitly disclaim all liability.
[46:53.160 --> 47:03.220]  At the end of the day, they've given... they've said absolutely nothing whatsoever, other than the fact that the person who got the certificate at one time was in possession of $50.
[47:05.760 --> 47:08.080]  They certify that and only that.
[47:08.380 --> 47:26.320]  Because the thing is that the certificate... the practice... they will... if you read what they actually say, they basically... you go to Bereson, it doesn't matter how much money you paid, they take no liability for someone who relied on their certificate and went to the wrong person.
[47:26.320 --> 47:29.900]  So it's all bilateral relationships in the end anyway.
[47:30.780 --> 47:32.100]  The CA added nothing.
[47:32.500 --> 47:37.680]  And so what they're talking about is more or less that in the real world, people have bilateral relationships.
[47:37.940 --> 47:38.980]  And it's true.
[47:39.760 --> 47:42.620]  And the CA model didn't add anything to that.
[47:43.020 --> 47:44.920]  If anything, it just confused things.
[47:47.180 --> 47:49.120]  Question about the implementation among the spheres.
[47:49.240 --> 47:54.100]  Can you tell, for example, when you go to a website or you're logging into an SSH code, who you're trusting?
[47:54.100 --> 47:57.060]  Yeah, that's a really, really, really good question, actually.
[47:57.280 --> 48:00.700]  And that's what we internally refer to as the marginal UI.
[48:01.100 --> 48:07.020]  So basically, you know, you don't necessarily always have a direct trust path to something, right?
[48:07.200 --> 48:14.140]  So you want to know in those cases, well, who has made certifications and do, you know, what is my relationship to them?
[48:14.420 --> 48:16.480]  And that's a really hard problem.
[48:16.600 --> 48:18.880]  That's another thing that we've been working a lot on.
[48:18.880 --> 48:24.320]  And in fact, with the web stuff, we don't actually currently have a marginal UI.
[48:24.480 --> 48:25.800]  That's what we're working on right now.
[48:25.880 --> 48:30.980]  But we do have the sort of a rough marginal UI in SSH.
[48:31.100 --> 48:47.380]  So for instance, if you SSH to a server and that you don't have a full trust path to that server key, you'll be shown before you get to the key acceptance prompt, the list of people who have certified that key.
[48:47.480 --> 48:50.220]  The list of people who you know have certified that key.
[48:50.520 --> 49:05.580]  So, you know, if you take my OpenPGP fingerprint after this talk and then you try to connect to a server that I maintain, you have no reason to actually believe that... to believe me when I certify, say, Google's SSH services.
[49:06.060 --> 49:12.740]  But you might have reason to believe my certifications for services that you believe I do actually control.
[49:12.960 --> 49:18.060]  And so there's more nuance there than in the traditional OpenPGP models, right?
[49:18.080 --> 49:23.860]  The traditional OpenPGP model says, I, you know, I think this guy really doesn't issue bad certifications.
[49:23.860 --> 49:28.160]  I'm going to, I'm going to rely on him to make any certification that he wants.
[49:28.360 --> 49:42.680]  And so the marginal UI really is important because it shows, it lets users, I think, if we can build it properly, I think we can let users build, build those, those more tightly scoped delegations of authority.
[49:45.060 --> 49:45.580]  Yeah?
[49:45.980 --> 49:50.140]  I just wanted to challenge the notion that we live in a universe of mistrust.
[49:50.140 --> 49:53.720]  And I would characterize the universe as one of the ignorance in IFA.
[49:54.500 --> 49:58.560]  Just to put that out there, it's about average users.
[49:58.780 --> 50:03.460]  And most of them, if you ask them what HTTPS is, they have no idea.
[50:03.620 --> 50:07.240]  They don't even barely know what HTTPS is other than they see it in commercials.
[50:08.440 --> 50:10.940]  Advertising for where to go to buy their nice product.
[50:11.060 --> 50:12.820]  We don't even say HTTP anymore.
[50:12.880 --> 50:15.180]  We just say, go to whatever.com.
[50:15.280 --> 50:16.480]  We don't even bother saying HTTP.
[50:16.480 --> 50:27.000]  When you get into this issue of we have an existing universe of mistrust, I don't think that's the case.
[50:27.160 --> 50:28.940]  I think most people have no idea what they're doing.
[50:29.080 --> 50:30.800]  If you tell, how do you know that the site is secure?
[50:30.960 --> 50:32.480]  They say, well, of course it's secure.
[50:32.600 --> 50:33.520]  I put in my password.
[50:33.860 --> 50:34.220]  Right.
[50:34.440 --> 50:34.540]  Okay.
[50:34.540 --> 50:38.660]  So I completely agree with you.
[50:39.560 --> 50:44.460]  And I think the statement that I made was probably not as clear as it should have been.
[50:44.580 --> 50:54.640]  So when I said there's a universe of mistrust and we're building webs of it, I was referring to the sort of security mindset and the way that software should be built to act on behalf of the user.
[50:54.640 --> 51:09.220]  And I believe you are correct in that the majority of users are actually not starting from that position of distrust, mainly because they don't understand the nature of the mediated network and how many points of failure there actually are in the communication.
[51:09.480 --> 51:17.480]  Because as we've brought stuff closer and closer to the users, I think the result is that people say, oh, well, it's like I'm talking to my buddy.
[51:17.620 --> 51:18.160]  I'm on Facebook.
[51:18.160 --> 51:19.100]  I can see their face.
[51:19.300 --> 51:20.460]  The messages are right there.
[51:20.460 --> 51:21.680]  How could it not be from them?
[51:22.180 --> 51:31.320]  And we haven't done a good job of explaining how the mediated nature makes the sort of interaction that we can have here face to face actually illusory online.
[51:31.620 --> 51:33.840]  If I could just extend a little bit.
[51:34.700 --> 51:41.020]  If what you're getting at is with the social TGP stuff that I can trust arbitrarily who I decide I want to trust.
[51:41.460 --> 51:45.560]  If I'm the average user, who do I trust?
[51:45.560 --> 51:51.360]  The only other people I know if I'm the average user are the idiots who send me AOL pointers.
[51:52.060 --> 51:54.000]  And do I trust their OpenPGP?
[51:54.060 --> 51:54.780]  How did they get it?
[51:56.060 --> 51:57.860]  So you're raising a good question, right?
[51:58.000 --> 52:07.220]  There are a lot of users who don't actually know anyone who does have the mindset of, oh, I'm going to actually take this stuff seriously and I'm going to do the right thing with it.
[52:07.820 --> 52:14.940]  But there are some other average users and I would imagine that everybody in this room knows a user who has the naive mindset.
[52:16.040 --> 52:21.480]  But that user also knows someone who doesn't have the naive mindset and that person is you.
[52:23.200 --> 52:23.480]  Okay?
[52:24.080 --> 52:29.420]  You guys actually understand the situation and you understand why this is something that needs to be taken seriously.
[52:29.420 --> 52:35.880]  And I would actually consider certifications made by people who think about that more important.
[52:36.160 --> 52:38.300]  And so many people do have geek friends.
[52:38.520 --> 52:41.320]  Many people do have friends who are in that position.
[52:41.480 --> 52:47.720]  And yes, it gives us a particular weird position of power over people who don't have that mindset.
[52:47.720 --> 52:56.800]  But if we understand the situation, we need to either make sure everybody else knows about it or do the responsible thing with that power.
[52:57.920 --> 52:58.660]  Or both.
[52:58.800 --> 52:59.840]  I would argue for both.
[53:00.200 --> 53:01.480]  But yeah, I think it's us.
[53:01.700 --> 53:02.700]  I think we need to do it.
[53:02.800 --> 53:04.780]  And that goes for... and us is everybody.
[53:20.960 --> 53:22.840]  Like you have your little friends.
[53:23.000 --> 53:26.140]  There is... I think there's in fact a project that's attempting to do that.
[53:49.120 --> 53:50.140]  That's an interesting idea.
[53:50.740 --> 53:54.800]  My initial gut reaction to that is, though, that you just end up selling points.
[53:55.680 --> 53:56.860]  You make a market for points.
[53:57.100 --> 53:59.500]  So the proposal for folks who didn't hear was...
[53:59.500 --> 54:01.940]  Is there a way that we could sort of have points assigned to people?
[54:03.380 --> 54:07.040]  I just want to respond to it real quick, also, because I think we're starting to run short on time.
[54:07.480 --> 54:08.600]  There are groups that do that.
[54:09.080 --> 54:15.940]  CACERT is a group that uses that kind of point system to make a sort of web of trust.
[54:16.160 --> 54:18.780]  The trouble with that, though, is that those points are not all the same.
[54:19.040 --> 54:20.300]  I actually know this guy.
[54:20.520 --> 54:21.660]  I've known him for a long time.
[54:21.660 --> 54:24.600]  And I think he actually does a really good job of making certifications.
[54:24.980 --> 54:26.860]  But that doesn't mean that you should.
[54:27.520 --> 54:31.820]  Now, it might if you decide that it does, but you shouldn't be forced to take that on faith.
[54:31.820 --> 54:34.440]  So not everybody has the same view of the points.
[54:34.640 --> 54:36.640]  So I think that's the problem with that plan.
[54:38.280 --> 54:39.500]  Oh, the user could...
[54:39.500 --> 54:39.700]  Yes.
[54:39.920 --> 54:46.380]  And actually, OpenPGP allows you to assign marginal owner trust or full owner trust to a given...
[54:46.380 --> 54:50.840]  So you could say, this is somebody who I would rely on any of their certifications.
[54:50.900 --> 54:53.960]  Or this is somebody who can issue a certification.
[54:54.160 --> 54:57.720]  And maybe I'll buy it if it's also corroborated by somebody else.
[54:57.940 --> 54:59.280]  And OpenPGP offers that.
[54:59.280 --> 55:01.160]  So that's built in to what we've got.
[55:01.580 --> 55:03.680]  So I think we're basically out of time.
[55:03.820 --> 55:05.440]  But a couple of quick, please.
[55:06.080 --> 55:11.840]  The two things I want to point out is that we are always looking for development help.
[55:12.060 --> 55:14.320]  I mean, there's a lot we have left to do.
[55:14.400 --> 55:18.040]  I mean, we could put OpenPGP in OTR.
[55:18.040 --> 55:20.940]  We could, you know, in SMTP.
[55:21.320 --> 55:25.560]  There's just a lot of places that, you know, doing the client authentication.
[55:25.560 --> 55:27.320]  There's just tons of stuff we could do.
[55:27.460 --> 55:31.180]  Working on marginal UIs, OpenPGP UIs in general.
[55:31.400 --> 55:32.960]  All of this stuff needs development.
[55:33.340 --> 55:34.980]  And in particular...
[55:34.980 --> 55:35.240]  JavaScript.
[55:35.820 --> 55:42.620]  We have essentially only one working implementation of OpenPGP right now, which is GPG.
[55:42.620 --> 55:45.000]  Which is okay, but...
[55:45.000 --> 55:46.060]  Yeah, there's also...
[55:46.060 --> 55:47.080]  There's also...
[55:47.080 --> 55:47.120]  There's also the...
[55:47.120 --> 55:48.400]  The BSD license for...
[55:48.400 --> 55:49.700]  Done by all those different folks.
[55:52.140 --> 55:52.660]  Okay.
[55:53.600 --> 55:53.780]  We...
[55:53.780 --> 55:54.460]  What's it called?
[55:54.900 --> 55:55.400]  Um...
[55:55.400 --> 55:56.140]  NEPTGP.
[55:56.740 --> 55:57.100]  Oh.
[55:57.100 --> 55:57.960]  I'll tell you about it after.
[55:58.140 --> 55:58.360]  Okay.
[55:59.200 --> 55:59.340]  Anyway.
[55:59.720 --> 56:00.000]  Yeah.
[56:00.580 --> 56:01.100]  So...
[56:01.100 --> 56:02.980]  Anyway, there's lots of development work to do.
[56:03.100 --> 56:04.420]  So if anybody's curious...
[56:04.420 --> 56:05.260]  And at all different levels.
[56:05.420 --> 56:09.400]  So if you're interested in, you know, user-friendly, front-facing stuff.
[56:09.400 --> 56:10.860]  If you're interested in data visualization.
[56:10.860 --> 56:12.020]  If you're interested in crypto.
[56:12.360 --> 56:13.780]  If you're interested in network schemes.
[56:14.100 --> 56:15.680]  If you're interested in protocol development.
[56:16.100 --> 56:17.580]  All of that stuff is sort of wide open.
[56:17.800 --> 56:18.300]  If we...
[56:18.300 --> 56:19.740]  If we step up to it and...
[56:19.740 --> 56:20.420]  And take it on.
[56:20.720 --> 56:21.460]  So if...
[56:21.460 --> 56:22.060]  Chromium development.
[56:22.260 --> 56:24.140]  Yeah, chromium development, for example.
[56:25.560 --> 56:26.000]  So...
[56:26.520 --> 56:27.360]  Thank you guys.
[56:27.580 --> 56:27.920]  Thank you.
[56:28.100 --> 56:28.640]  It's been a good time.