[00:01.130 --> 00:01.610]  Raderman?
[00:01.730 --> 00:02.170]  Raderman.
[00:02.190 --> 00:03.090]  Raderman, sorry.
[00:03.510 --> 00:04.870]  I still got used to the name too.
[00:05.490 --> 00:05.990]  I just got married.
[00:06.190 --> 00:06.610]  I know what you mean.
[00:06.930 --> 00:08.070]  Yeah, marriage is great.
[00:09.470 --> 00:12.410]  Laura Raderman with PGP versus PKI.
[00:16.390 --> 00:19.910]  Okay, so let's go ahead and get started.
[00:20.530 --> 00:22.270]  This is PGP versus PKI.
[00:22.730 --> 00:25.010]  I'm going to assume that you know some of the basics.
[00:25.270 --> 00:29.830]  I'm not going to go over any kind of real deep detail into the cryptography.
[00:30.330 --> 00:36.770]  If you want cryptography, I've got some links on books and websites that you can look at for all the nitty-gritty mathematical details.
[00:37.570 --> 00:43.350]  We're primarily going to concentrate on the trust issues and the relationships within PKI and PGP.
[00:44.430 --> 00:45.430]  So who am I?
[00:45.570 --> 00:49.190]  Right now, I am the Director of Security Assessments at Gemini Security Solutions.
[00:49.250 --> 00:52.210]  We are a security consulting firm in the Washington, D.C.
[00:52.270 --> 00:52.810]  metro area.
[00:53.950 --> 00:55.290]  Yeah, Director doesn't mean much.
[00:55.390 --> 00:56.550]  We've got seven people in the company.
[00:57.070 --> 00:59.170]  So it's just a fancy title.
[00:59.750 --> 01:04.170]  I've participated in the Federal PKI Working Group Thanks to being in the D.C.
[01:04.390 --> 01:04.410]  area.
[01:04.970 --> 01:05.670]  The U.S.
[01:05.870 --> 01:10.890]  federal government has one of the largest PKIs in the world, thanks to the Department of Defense and the Federal Bridge.
[01:12.010 --> 01:28.230]  We provide consulting services for very large enterprises with PKIs, some of whom actually rival the federal PKI for size and number of certificates issued, although most of that has to do with lost tokens and broken tokens rather than actual size.
[01:29.110 --> 01:31.070]  I do occasionally do pen-testing still.
[01:31.490 --> 01:35.230]  I'd rather do more than more of it, but my background is in pen-testing.
[01:35.810 --> 01:42.410]  Unfortunately, I've kind of moved to the middle management, but it pays more and I started a family to support.
[01:43.350 --> 01:56.430]  And also, you know, I do have a Master of Science in Information Networking from Carnegie Mellon, the INI program, which is now an NSA approved security program, which what my opinion doesn't mean much.
[01:58.610 --> 01:59.610]  So what are we going to talk about?
[01:59.770 --> 02:01.330]  Real quick, public key cartography.
[02:02.250 --> 02:06.230]  Some of the key management of PGP and GPG.
[02:06.670 --> 02:10.790]  I'm primarily focusing on open PGP, which is the open standard that's used now.
[02:11.330 --> 02:12.530]  And the same with PKI.
[02:12.770 --> 02:14.190]  And then why would you choose one over the other?
[02:14.710 --> 02:16.190]  Each has its strengths and weaknesses.
[02:16.590 --> 02:17.470]  And what are they?
[02:19.030 --> 02:20.530]  So public key cartography.
[02:20.730 --> 02:23.050]  It has, you've got two keys, your public and your private.
[02:23.230 --> 02:24.650]  They're mathematically related.
[02:25.610 --> 02:31.770]  Basically, you have trapdoor functions, which are one-way functions that have a key to go back the other way.
[02:32.950 --> 02:43.710]  Basically, if you know the public key, it's very, very difficult mathematically and computational, needs a lot of computational power to get the private key, even though they are related.
[02:43.710 --> 02:45.170]  So it is possible.
[02:45.910 --> 02:50.470]  But with key links that are in use today, 1024 or 2048, it's very, very, very difficult.
[02:51.410 --> 02:55.890]  Although it keeps getting easier every month as we get more, as we get more competing power.
[02:56.730 --> 02:58.450]  There are several algorithms that are in use.
[02:59.110 --> 03:00.950]  RSA is based on competing factors.
[03:02.130 --> 03:06.590]  DSA and El-Gamal are based on competing logarithms, both of which are complex problems.
[03:06.590 --> 03:11.430]  So just the algorithm you use just dictates what problem you're trying to solve.
[03:13.410 --> 03:17.150]  Basic premise is that one key undoes whatever the other one does.
[03:17.630 --> 03:22.130]  So if you encrypt with your private key, you unencrypt with the public key.
[03:22.250 --> 03:24.810]  If you encrypt with your public key, you unencrypt with your private key.
[03:25.390 --> 03:29.690]  So that's basically the relationship of your public and private keys.
[03:30.910 --> 03:36.810]  If you want more very detailed information on public key cryptography, the Handbook of Applied Cryptography is free online.
[03:37.310 --> 03:38.470]  And I have the URL.
[03:38.910 --> 03:44.110]  And actually, I might check with my boss and see if I can upload these to our server after the talk.
[03:44.390 --> 03:46.270]  And let you guys download the slides.
[03:48.410 --> 03:51.970]  Also, the Practical Cryptography book with Niels Ferguson and Bruce Schneier.
[03:52.570 --> 04:00.590]  Both of those...I actually recommend The Practical Cryptography Book over The Applied Cryptography Book, because The Applied Cryptography is how to implement them.
[04:00.910 --> 04:03.710]  Whereas The Practical Cryptography tells you, you know...what's the background?
[04:03.890 --> 04:04.670]  How are they were developed?
[04:04.850 --> 04:05.490]  And things like that.
[04:05.890 --> 04:10.250]  So, for people who are just interested in learning about the cryptography, I recommend Practical Cryptography.
[04:10.530 --> 04:12.810]  If you want to implement it, go for the read book.
[04:14.350 --> 04:20.910]  So, public-key cryptography is a little different from Symmetric Key, AES, etc., because it allows for digital signatures.
[04:22.030 --> 04:27.490]  You basically, you sign with your private key and that's your signature.
[04:28.410 --> 04:30.030]  It allows for message integrity.
[04:30.470 --> 04:34.410]  You use hashes with your private key.
[04:34.650 --> 04:36.590]  People can tell if your message has changed or not.
[04:37.270 --> 04:39.870]  And also, it supports key exchange.
[04:41.250 --> 04:49.510]  Most public key cryptography actually, when you exchange an email with somebody using one of these methods, you're actually not encrypting it asymmetrically.
[04:49.510 --> 04:52.730]  You're encrypting a key asymmetrically.
[04:52.990 --> 04:57.150]  People decrypt the key and then use that symmetric key to decrypt the rest of the message.
[04:57.830 --> 05:00.490]  So, just because symmetric is still faster.
[05:01.650 --> 05:08.010]  And what public key cryptography lets you do is exchange all these keys with an in-band manner.
[05:08.170 --> 05:10.590]  You don't have to call somebody on the phone and say, what's your key?
[05:10.850 --> 05:14.150]  It can be, you know, publicly on a web page, key server, whatever.
[05:15.990 --> 05:19.270]  So, digital signatures are using a private key to encrypt them.
[05:20.070 --> 05:23.070]  You usually encrypt the hash, not the actual entire message.
[05:24.010 --> 05:25.310]  Provides non-repudiation.
[05:25.570 --> 05:30.490]  If I send you a message signed, I can't later say that, no, I didn't send that.
[05:30.790 --> 05:33.050]  Because theoretically, I'm the only one who has my private key.
[05:33.550 --> 05:37.010]  And since I signed with my private key, I sent it.
[05:38.310 --> 05:39.770]  And also, the message integrity.
[05:40.070 --> 05:41.710]  So, people check the hashes.
[05:41.910 --> 05:45.890]  If the hashes aren't exact, then the message has changed in some way.
[05:46.310 --> 05:49.930]  There's starting to be issues with that, with collisions in SHA-1.
[05:50.790 --> 05:56.350]  So, as of now, you can't do known collisions, but in the future, you may be able to.
[05:57.790 --> 05:59.850]  So, how do we share all our public keys?
[06:00.070 --> 06:00.870]  Give them to your friends.
[06:01.070 --> 06:02.230]  Stick them on a USB stick.
[06:02.490 --> 06:03.710]  Publish them on your web page.
[06:04.170 --> 06:05.970]  Use key servers, PGP key servers.
[06:06.530 --> 06:09.630]  And also, you can also use X500 or LDAP directories.
[06:09.850 --> 06:15.270]  And all of these ways, you can share any public key, PGP or PKI.
[06:15.890 --> 06:16.730]  And they're public.
[06:16.910 --> 06:19.050]  So, I mean, your keys are public.
[06:19.050 --> 06:20.430]  It does not matter who has them.
[06:20.790 --> 06:22.670]  Except for one case, when you want to revoke them.
[06:24.510 --> 06:24.870]  So...
[06:26.030 --> 06:28.650]  Well, what about all the public keys that you've collected that aren't yours?
[06:29.290 --> 06:31.370]  You know, all of your friends, all the ones you've downloaded.
[06:32.050 --> 06:39.670]  How do you know that the person that you have the public key for has the corresponding private key and is who you think you are?
[06:40.470 --> 06:42.950]  Well, this is how PGP and PKI are different.
[06:43.310 --> 06:44.950]  They deal with this differently.
[06:45.870 --> 06:50.030]  For PGP, and like I said, this is open PGP mostly.
[06:50.590 --> 06:53.390]  Pretty good privacy, 1991 by Phil Zimmerman.
[06:54.150 --> 06:56.890]  It's changed quite a bit since he created it.
[06:56.890 --> 07:02.870]  There's really two big changes starting with 2.6 and earlier and 2.6 and later.
[07:03.330 --> 07:05.250]  Have quite different algorithms.
[07:05.970 --> 07:14.390]  Right now it's owned by the PGP Corporation, which actually still does publish PGP software, desktop, enterprise-level software.
[07:15.450 --> 07:25.890]  Open PGP was an ITF working group created in 1997 so that PGP stayed open and did not have problems with network associates, just not wanting to deal with it.
[07:27.710 --> 07:33.290]  RFCs 4880 and 3156 are the two RFCs that deal with open PGP if you want more details.
[07:33.930 --> 07:36.490]  And like I said earlier, I'm talking about open PGP.
[07:36.830 --> 07:39.290]  So, which is the standard, the ETF standard.
[07:40.670 --> 07:46.550]  So, both open PGP and PGP Corporation support the traditional web of trust method.
[07:47.030 --> 07:49.790]  You know, they also actually support a hierarchical model.
[07:50.290 --> 07:54.270]  I was talking to some friends earlier and they had no clue that PGP could do something.
[07:54.290 --> 07:55.610]  some of the stuff I'm about to talk to you today.
[07:55.850 --> 07:57.050]  Even though it's in the code.
[07:58.090 --> 07:59.290]  Keys are kept on a key ring.
[07:59.990 --> 08:01.070]  You have at least two.
[08:01.350 --> 08:02.490]  One private, one public.
[08:02.630 --> 08:04.930]  You can also have multiple, however you choose it.
[08:05.610 --> 08:08.530]  Mostly, most public keys are exchanged in some kind of ad hoc manner.
[08:09.210 --> 08:10.810]  Key servers, web pages.
[08:11.710 --> 08:13.710]  So, like I said, you got the key servers.
[08:14.370 --> 08:16.950]  And each of you selects what key server you want to use.
[08:18.370 --> 08:21.710]  So, this is an example web of trust created using SIG2DOT.
[08:22.390 --> 08:23.270]  This is mine.
[08:23.550 --> 08:27.730]  And the kind of cluster in the middle there is actually from the HOPE 2004 key signing party.
[08:28.390 --> 08:30.810]  So, you can kind of see, you know, everybody's interrelated there.
[08:31.470 --> 08:34.830]  And then I have also, you know, like I said, you know, went to college, did masters.
[08:35.170 --> 08:38.010]  So, you can see kind of the other groups of friends that I hang out with.
[08:39.870 --> 08:43.430]  When you're validating a key with PGP.
[08:43.630 --> 08:48.870]  And this is, you know, either to use it as to send somebody an encrypted message or to check their signature.
[08:49.290 --> 08:50.590]  There's four levels of trust.
[08:50.870 --> 08:54.630]  And this is using the update trustdb command in GPG.
[08:55.550 --> 08:56.550]  You don't trust them.
[08:56.730 --> 08:58.110]  You don't know if you trust them.
[08:58.330 --> 09:00.850]  You have a marginal trust or you fully trust them.
[09:01.430 --> 09:05.230]  By default, your own key is a fully trust because you own the private key.
[09:05.230 --> 09:08.130]  Everybody else, by default, is don't know.
[09:08.350 --> 09:11.650]  If you actually use update trustdb, you can set it.
[09:12.290 --> 09:17.210]  In order to validate a key, you know, GPG requires enough valid keys.
[09:17.710 --> 09:22.690]  Or, well actually, and the key being validated must be within five keys of your own.
[09:23.570 --> 09:24.990]  So now, these are GPG defaults.
[09:25.050 --> 09:25.770]  You can change them.
[09:26.950 --> 09:30.230]  It defaults to requiring one of a key you've directly signed.
[09:30.390 --> 09:33.650]  So, if you've signed your friend's key, it trusts it fully.
[09:34.550 --> 09:36.490]  One fully valid key must have trusted.
[09:36.690 --> 09:41.170]  So, if you fully trust a friend, they sign a key, you'll trust it.
[09:41.510 --> 09:44.590]  Or, you have to have three marginally valid keys sign it.
[09:45.170 --> 09:51.990]  So, if you marginally trust three of your friends and those three friends have signed a key, then it's going to be fully trusted.
[09:52.570 --> 09:57.430]  So, as an example here, you know, I have Alice, Bob, and Charlie are people I've signed.
[09:58.830 --> 10:00.910]  And I marginally trust them.
[10:01.530 --> 10:04.850]  I don't, you know, for whatever reason, I don't trust them to check IDs.
[10:05.330 --> 10:06.830]  I just marginally trust them.
[10:07.130 --> 10:11.350]  They're okay people, but I'm not going to trust them to sign for me and check IDs.
[10:11.990 --> 10:16.390]  So, if all three of them sign Dan, I'm going to consider Dan a valid key.
[10:17.010 --> 10:19.490]  But, only Bob and Charlie have signed Eve.
[10:20.150 --> 10:22.430]  So, I'm not going to consider Eve a valid key.
[10:23.190 --> 10:25.410]  And that's about how GPG does it.
[10:26.810 --> 10:29.090]  So, what happens, you know, you have these middle keys.
[10:29.350 --> 10:30.070]  Where do you find them?
[10:30.250 --> 10:37.470]  If I've signed Alice, and Alice has signed Bob, and Bob has signed Charlie, where do I find the link between Alice and Charlie?
[10:38.550 --> 10:39.850]  I don't even know who Bob is.
[10:40.110 --> 10:41.350]  How do I find his key?
[10:42.290 --> 10:45.170]  Well, you know, say Charlie sends me a signed email.
[10:45.430 --> 10:48.490]  I don't know whether I trust it or not, because I don't know who Bob is.
[10:49.150 --> 10:55.950]  So, I have to find, somebody has to tell me about Bob's key, so that I can have it into my key ring.
[10:56.490 --> 11:02.150]  You know, I either have to ask Alice about it, or I have to ask Charlie who he thinks might lead back to me.
[11:02.670 --> 11:07.730]  There's really no good way of building paths with PGP.
[11:08.010 --> 11:10.370]  Yes, if they're on your key ring, it can build the path.
[11:10.610 --> 11:14.030]  But if you don't have these people on your key ring, you're not going to be able to build that path.
[11:15.010 --> 11:22.250]  This is kind of, this is one of the major problems with the decentralized web of trust, is that there's no go-to place to get all these keys.
[11:22.610 --> 11:26.950]  Like I said, you know, most of the major key servers are linked together, but not all of them.
[11:27.210 --> 11:30.810]  So, what if I use one set of key servers, and Charlie's using another set of key servers?
[11:31.310 --> 11:32.350]  I'll never find them.
[11:35.390 --> 11:39.830]  So, another thing that OpenPGP supports, is actually it does support a hierarchical model.
[11:41.330 --> 11:43.710]  Most people use the web of trust model though.
[11:44.150 --> 11:49.590]  Like I've said, I've talked to some friends who have used PGP forever, they didn't even know the option existed.
[11:50.810 --> 11:52.070]  There's no central authority.
[11:52.830 --> 11:56.030]  You are the central authority for your web of trust.
[11:57.830 --> 12:02.130]  So, I decide how much I'm going to trust a key, and I decide how many... how...
[12:02.130 --> 12:06.030]  I decide what I'm going to require from people for me to sign their key.
[12:06.570 --> 12:10.630]  So, if I want your passport to sign your key, that's my standard.
[12:11.570 --> 12:13.970]  But, how many people want a passport to sign a key?
[12:14.690 --> 12:17.790]  You know, there's no standards of identity verification.
[12:18.210 --> 12:20.250]  It could be, oh, I know Bob over in Cube 3.
[12:20.250 --> 12:21.690]  Okay, let me go sign Bob's key.
[12:21.970 --> 12:22.950]  He works for my company.
[12:23.170 --> 12:24.090]  I've never seen the guy.
[12:24.230 --> 12:25.330]  I just know he works for my company.
[12:25.770 --> 12:26.250]  You know?
[12:27.590 --> 12:27.990]  Okay.
[12:28.170 --> 12:30.950]  So, basically, you know, there's two types of signatures in OpenPGP.
[12:31.230 --> 12:32.710]  Signature that everybody knows.
[12:33.010 --> 12:38.790]  You just sign it, upload it to key server, you now trust it fully marginally, or you don't trust it.
[12:39.250 --> 12:40.310]  Whatever the case may be.
[12:40.750 --> 12:44.750]  So, when I sign a key, I'm saying that I have verified this person's identity.
[12:44.750 --> 12:47.170]  Whatever my idea of verifying is.
[12:48.210 --> 12:51.530]  So, and I might trust my friends to verify it to somebody else.
[12:51.750 --> 12:53.830]  So, there are a few friends that I trust to check IDs.
[12:54.070 --> 12:55.470]  And there are some that I don't.
[12:57.310 --> 13:03.850]  And, you know, once it's gone past my group of friends, I don't know what the standards of identity are.
[13:06.870 --> 13:09.010]  Kind of really end up with a one level chain.
[13:09.470 --> 13:10.490]  You to your friend.
[13:11.110 --> 13:12.050]  Maybe one more.
[13:13.070 --> 13:14.170]  One person in the middle.
[13:14.810 --> 13:17.750]  So, but, and in a lot of cases you have a key signing party.
[13:18.610 --> 13:21.470]  Half the people on the, on my web of trust from the HOPE Key Signing Party.
[13:22.190 --> 13:23.070]  Never seen them before.
[13:23.290 --> 13:24.090]  Never seen them since.
[13:25.510 --> 13:27.390]  But I checked their ID at the key signing party.
[13:27.870 --> 13:29.170]  When I was, I signed their key.
[13:29.810 --> 13:30.750]  I don't know who they are.
[13:30.850 --> 13:33.330]  I don't know that I can trust them to sign other people's keys appropriately.
[13:33.990 --> 13:37.050]  Yes, they did it at the key signing party, but does that mean they do it all the time?
[13:37.530 --> 13:38.090]  I don't know.
[13:38.870 --> 13:41.130]  So, you can't extend your trust very far.
[13:41.530 --> 13:51.470]  You know, you kind of have to get out of your group of close friends, go to other groups, go to a different LUG, go to a different 2600 meeting, in order to expand your web of trust.
[13:53.010 --> 13:55.550]  Most of the people I know aren't terribly comfortable doing that.
[13:56.530 --> 13:57.850]  Because it requires talking to people.
[14:01.910 --> 14:04.710]  So, the other kind of signature in PGP is trust signatures.
[14:05.450 --> 14:06.690]  It's not a direct command.
[14:06.830 --> 14:08.650]  You can only do it through the edit key command.
[14:08.790 --> 14:09.570]  It's called t-sign.
[14:10.350 --> 14:13.910]  And I'm not sure if you guys can read my screen capture there.
[14:14.110 --> 14:17.350]  But that's actually what happens when you do a t-sign on a key.
[14:17.730 --> 14:20.510]  It asks you, do you trust them marginally or do you trust them fully?
[14:21.270 --> 14:24.110]  And then it asks you the depth of trust.
[14:24.310 --> 14:25.870]  How far do you trust this person?
[14:26.570 --> 14:30.870]  It can be, you know, zero or it can be, you know, 500.
[14:31.070 --> 14:31.670]  Whatever you want.
[14:33.650 --> 14:34.650]  Zero means what?
[14:35.250 --> 14:36.730]  Zero means you don't trust them at all.
[14:38.070 --> 14:41.910]  One means you trust them, but you don't trust them to trust check identities.
[14:42.390 --> 14:48.550]  Anything above one means you trust them to check identities and whoever they sign to check identities.
[14:48.810 --> 14:52.270]  It's basically a measure of how far you trust people.
[14:52.490 --> 14:54.670]  How far down the path you're willing to trust people.
[14:55.570 --> 14:57.470]  You can also restrict it by domain.
[14:57.470 --> 15:08.450]  So if I say, I trust Bob from Company A to sign all of Company A's, A.org's signatures, I can say, okay, Bob can only sign A.org's.
[15:09.270 --> 15:11.150]  So you can restrict it by domain.
[15:12.450 --> 15:19.730]  But basically, when you do sign it with a trust signature, you're saying, you trust this person to verify somebody else's identity for you.
[15:20.270 --> 15:25.190]  You also allow them to make signatures on your behalf, basically.
[15:25.670 --> 15:31.710]  So, you know, when PGP makes its path building algorithm, it kind of takes you and your friend, puts them together.
[15:32.230 --> 15:37.410]  There's no, you know, it's basically the same thing as far as PGP is concerned.
[15:37.510 --> 15:39.150]  Now, the path length obviously changes.
[15:40.950 --> 15:43.610]  You've just become a CA of sorts.
[15:43.670 --> 15:44.670]  You've become your own CA.
[15:45.530 --> 15:49.770]  Like I said here, depth tells you how far you trust your friend's friend.
[15:49.770 --> 15:52.050]  So if I sign somebody, that's a depth of one.
[15:52.250 --> 15:54.990]  They sign somebody else, that's a depth of two, and so on.
[15:55.850 --> 15:57.290]  So it's just a measure of chain length.
[15:58.690 --> 16:00.730]  Then you have revocation with PGP.
[16:01.670 --> 16:03.650]  First, you have to actually generate your revocation.
[16:04.430 --> 16:08.290]  The GNU-PG manual recommends you do it as soon as you generate your actual key.
[16:08.930 --> 16:10.670]  I don't know too many people who do.
[16:10.670 --> 16:13.930]  And if they do, they have no clue where they saved it when they actually need it.
[16:15.210 --> 16:20.750]  So, and when you've lost the key and you haven't generated this revocation information, you can't.
[16:20.910 --> 16:22.470]  You no longer have that private key.
[16:22.610 --> 16:23.550]  You can't revoke your key.
[16:23.790 --> 16:26.690]  Even though you know it's been compromised or suspect it's been compromised.
[16:27.410 --> 16:30.170]  You and only you can revoke your certificate.
[16:31.190 --> 16:34.630]  I can't revoke a certificate for you, even though I know you lied to me.
[16:34.910 --> 16:38.190]  I can revoke my signature on your certificate.
[16:38.770 --> 16:41.350]  There's only two commands that won't let you.
[16:41.530 --> 16:43.730]  And that's NR sign and NRT sign.
[16:44.570 --> 16:47.810]  That means non-revocable signature, non-revocable trust signature.
[16:48.310 --> 16:50.270]  And if you use those, I pity you.
[16:50.770 --> 16:54.990]  You should always be able to revoke your trust in your friends, no matter how good friends they are.
[16:56.950 --> 16:59.650]  You also have an issue with publishing your revocation information.
[16:59.830 --> 17:07.410]  How do you tell all these people that may have your key, and you have no clue who has your key, because you put it in a public place, that you've revoked your key?
[17:08.570 --> 17:17.130]  Yeah, you can put it on your website, put it on the key servers, and if it's on a key server, most people are likely going to pick it up, assuming they refresh their keys every once in a while.
[17:17.130 --> 17:25.990]  But if somebody has downloaded it off your website, unless you really go back through five, six years of weblogs, how do you know who's downloaded it so you can notify them?
[17:27.710 --> 17:34.670]  And, you know, when you upload it, you don't know who has actually signed... you may or may not know who has signed your key.
[17:35.150 --> 17:39.850]  It's likely because you probably had to show your identity to them, but that's not always the case.
[17:40.110 --> 17:45.270]  I have actually seen people who have randomly signed keys on key servers, just because the name looked familiar.
[17:46.730 --> 17:50.970]  So, how do you tell these people that have signed your key, that you've revoked your key, that your key's no longer good?
[17:51.910 --> 17:54.130]  So, key server's the best method right now.
[17:55.250 --> 17:56.910]  Well, what's the problem with PGP?
[17:57.350 --> 17:59.610]  Lack of standards for identity verification.
[18:00.690 --> 18:11.450]  You know, in the U.S., driver's license, passport, school ID, company ID maybe, you know, what do you find acceptable?
[18:11.670 --> 18:13.070]  It may not be what I find acceptable.
[18:14.390 --> 18:16.310]  You know, how do you know what other people are doing?
[18:16.550 --> 18:22.450]  Further down the chain, you've trust signed somebody, how do you know what their identity standards are?
[18:22.450 --> 18:25.250]  You have no contract with them to hold them to those standards.
[18:25.690 --> 18:33.370]  So, if they just, most of the time they check the identities and then just the one-off time they don't, you know, it's kind of a trust issue with your friends.
[18:35.090 --> 18:36.270]  Referred trust is shaky.
[18:36.650 --> 18:45.950]  You know, when you say somebody else can act on my behalf, in all situations, legal, in the real world, online, et cetera, you have issues.
[18:45.950 --> 18:53.570]  You know, you no longer have, you no longer have control over your key and what your trust is.
[18:53.830 --> 18:57.790]  You basically publish and said, I trust this person to act as me.
[18:59.050 --> 19:05.610]  You know, and if for some reason you get upset, have a fight, whatever, you'd have no clue what they're going to do.
[19:06.990 --> 19:11.930]  Now, like I said, paranoid persons likely never ever to use a trust signature.
[19:11.930 --> 19:17.230]  In fact, how many people here have actually used trust signatures in PGP or GPG?
[19:17.870 --> 19:22.490]  We've got two, three, four people out of a group of maybe 50, 60.
[19:23.230 --> 19:25.610]  So, how many have heard about them before now?
[19:26.930 --> 19:28.130]  Okay, quite a few more.
[19:29.030 --> 19:32.150]  So, like I said, it's really not that popular.
[19:33.510 --> 19:35.550]  But PGP is a very flexible model.
[19:35.870 --> 19:38.690]  You have control over your little group.
[19:39.210 --> 19:41.550]  And you can trust them or not trust them as you choose.
[19:42.510 --> 19:47.270]  Still have problems of finding keys in the middle between you and whoever sent you a signed message.
[19:47.870 --> 19:50.370]  And also, revocation notification is a pretty big issue.
[19:52.130 --> 19:55.950]  So, PKI actually solves a lot of these and brings its own problems.
[19:57.070 --> 19:58.870]  So, PKI is public key infrastructure.
[19:59.210 --> 20:02.290]  It's based on RFC 5280, which just came out this May.
[20:02.970 --> 20:06.490]  You guys are probably more familiar with 3280, which is the previous version.
[20:07.670 --> 20:09.810]  It's also called X.509 in the ANSI standard.
[20:10.230 --> 20:11.130]  It uses certificates.
[20:11.410 --> 20:12.910]  You can actually use hardware tokens.
[20:13.090 --> 20:16.390]  And if anybody knows of a hardware token for PGP, I'd like to hear about it.
[20:17.090 --> 20:18.110]  I don't know of one.
[20:18.190 --> 20:19.950]  And if there is one, I'd be great.
[20:20.030 --> 20:25.170]  Because I'd like something that can store both my PGP key ring and my hardware certificates on the same token.
[20:26.310 --> 20:27.810]  You also have certificate policies.
[20:28.130 --> 20:29.310]  And you have directories.
[20:29.530 --> 20:32.390]  This all kind of comes as part of the whole infrastructure part of it.
[20:33.450 --> 20:35.350]  It's primarily a hierarchical model.
[20:35.530 --> 20:39.390]  It does actually support a Web of Trust-like model using cross-certificates.
[20:39.590 --> 20:42.310]  But that has really big interoperability challenges.
[20:43.730 --> 20:47.370]  Certificates are public keys that have been signed by another entity.
[20:48.130 --> 20:52.530]  So, once somebody has signed your public key, it becomes a certificate.
[20:52.730 --> 20:54.710]  Whoever signed it doesn't matter.
[20:55.870 --> 20:59.210]  Certification authorities actually issue certificates.
[20:59.750 --> 21:04.070]  So, they can issue certificates to other certification authorities and they can issue it to end users.
[21:04.390 --> 21:05.730]  Just people like you and me.
[21:06.390 --> 21:10.830]  A root CA is a special type of CA that has a self-signed certificate.
[21:11.830 --> 21:14.390]  This is the ultimate trust root of the hierarchy.
[21:15.450 --> 21:19.610]  So, this is the kind of machine that's, you know, most of them, no network.
[21:19.770 --> 21:21.550]  Network ports are actually epoxied closed.
[21:21.950 --> 21:24.310]  They're stored offline, stored in a safe.
[21:24.890 --> 21:30.970]  A lot of them use hardware security modules that have four or five key cards.
[21:31.290 --> 21:38.910]  And in order to boot up the machine, you actually have to have, say, three of the five or four of the five keys in order to even boot up the machine and use the keys for these.
[21:39.770 --> 21:44.190]  So, they're quite... they're the weak spot in the hierarchy, in the trust hierarchy.
[21:44.750 --> 21:46.390]  You also have subordinate CAs.
[21:46.390 --> 21:49.870]  These are certification authorities, don't have a self-signed certificate.
[21:50.570 --> 21:54.530]  Or where the self-signed certificate does not enter the certification path.
[21:55.390 --> 22:00.150]  A CA or an end user can have multiple certificates issued by multiple issuers.
[22:00.610 --> 22:02.810]  So, it makes an interesting graph picture.
[22:03.570 --> 22:11.870]  A validation path is a chain of all the certificates from one that you trust to the one you're trying to verify or validate.
[22:12.910 --> 22:16.070]  So, and it always has to go back to a root CA that you trust.
[22:16.590 --> 22:21.310]  So, validation paths would be completely different for everybody because not everybody trusts the same root CAs.
[22:22.230 --> 22:25.090]  And then you also have the revocation list, also known as a CRL.
[22:25.650 --> 22:28.650]  It's a list of all certificates that a particular CA has revoked.
[22:29.350 --> 22:30.970]  So, this is the publication method.
[22:32.190 --> 22:42.790]  So, the interesting parts of an X5 and ION certificate, the required parts are a subject and their key, issuer and their public key, a validity period.
[22:42.870 --> 22:44.190]  So, how long is it good for?
[22:44.310 --> 22:45.190]  When did it start being good?
[22:45.290 --> 22:46.210]  When does it end being good?
[22:46.510 --> 22:48.250]  And a CRL distribution point.
[22:48.470 --> 22:51.250]  Where am I going to find revocation information about this certificate?
[22:51.850 --> 22:54.350]  Some of the interesting optional parts are key usage.
[22:54.570 --> 22:55.470]  An extended key usage.
[22:55.810 --> 22:56.650]  I can tell...
[22:56.650 --> 23:01.230]  When I sign a certificate as a CA, I can say, this certificate is only good for encryption.
[23:01.450 --> 23:03.150]  This certificate is only good for digital signing.
[23:03.490 --> 23:04.970]  This certificate is only good for authentication.
[23:05.530 --> 23:08.890]  And there's also the code signing certificates, which some of you might be familiar with.
[23:11.150 --> 23:13.030]  Certificate policies are also optional.
[23:13.210 --> 23:17.850]  I can assign a policy to a certificate, saying this certificate follows this particular policy.
[23:18.350 --> 23:22.650]  And I'll talk a little bit more about policies later, but this is basically the rules of the CA.
[23:23.630 --> 23:27.770]  The other interesting part is the authority information access, the AIA field.
[23:28.130 --> 23:31.490]  This says where to find information about the key that signed me.
[23:32.890 --> 23:40.330]  So, say if I have an end user certificate, my AIA is going to have information about the CA that signed me.
[23:40.690 --> 23:42.330]  So, here, go find this key.
[23:42.890 --> 23:45.570]  That's where you solve the, you know, where to find the middle keys problem.
[23:46.610 --> 23:54.770]  Your general hierarchy has a root CA, like I said, usually offline, locked in a box, brought up maybe once a year to issue a CRL.
[23:55.790 --> 23:57.430]  Issues certificates to sub-CAs.
[23:57.590 --> 24:00.610]  These are the ones that are actually online and doing all the certificate issuance.
[24:01.330 --> 24:04.190]  The sub-CAs issue to people, or other CAs.
[24:04.330 --> 24:06.770]  I mean, I've seen, I've seen hierarchies five or six deep.
[24:07.150 --> 24:09.330]  I don't know why, but they had, they went five or six deep.
[24:11.710 --> 24:12.510]  Path validation.
[24:12.830 --> 24:13.870]  This is building the path.
[24:14.770 --> 24:17.650]  You have to start, you start with the certificate that you're trying to verify.
[24:18.910 --> 24:24.890]  Uses the issuer information, the AIA, until it finds one that, until it finds some CA that you trust.
[24:24.890 --> 24:28.270]  Just keeps going back up the hierarchy to find something that you trust.
[24:28.970 --> 24:31.130]  Then it checks all the certificates in that path.
[24:31.310 --> 24:32.230]  Are they still good?
[24:32.370 --> 24:33.150]  Are they revoked?
[24:33.470 --> 24:33.870]  Etc.
[24:34.910 --> 24:37.910]  It can actually be quite a lot more complicated than it sounds.
[24:38.410 --> 24:42.890]  It's a graph problem, and it has cycles in it.
[24:43.090 --> 24:49.110]  So you're, it's actually, because of specifics to X5 and 9, you're actually only talking about tree-spanning algorithm.
[24:49.110 --> 24:51.250]  So it's not NP complete, but it is difficult.
[24:52.350 --> 25:01.870]  But RFC, if you really want to learn about path building, RFC 4158 actually tells you, it doesn't tell you how you must do it, but it tells you, here's a really good way to do it.
[25:02.450 --> 25:10.290]  And in fact, most of the, most, most vendors who do path validation actually follow 4158.
[25:12.010 --> 25:13.530]  So, some of the key management.
[25:14.210 --> 25:15.690]  PKI supports key escrow.
[25:16.370 --> 25:17.270]  What's key escrow?
[25:17.850 --> 25:19.190]  Storing the key, storing your key.
[25:20.290 --> 25:21.730]  CA keeps a copy of your key.
[25:22.270 --> 25:23.110]  What's this good for?
[25:23.490 --> 25:25.310]  Signing, not so good at an idea.
[25:25.530 --> 25:27.170]  Because then you lose non-repudiation.
[25:28.470 --> 25:39.170]  But when you're encrypting, you're working for a company, and you have documents, you've locked out your hardware token, and you really, really need to get to this document to send it to your boss.
[25:39.490 --> 25:43.210]  You can go ask the CA and say, can I really pretty please have my encryption key back?
[25:44.450 --> 25:45.930]  So, that's one of the reasons.
[25:46.210 --> 25:52.410]  And the other reason is the CYA of companies, so that they can always unencrypt what people have encrypted in their company.
[25:55.010 --> 25:57.190]  Certificates are published in a central directory.
[25:58.230 --> 26:00.470]  All CA certificates are published.
[26:00.850 --> 26:02.610]  End user certificates may or may not be.
[26:02.730 --> 26:05.510]  Depends on how you set up your infrastructure.
[26:06.430 --> 26:09.370]  And that's just so that people can find your CA certificates.
[26:11.710 --> 26:16.150]  CA should have, publish, and follow a certificate policy.
[26:17.430 --> 26:22.090]  And the certificate policy, there is actually a RFC that tells you exactly what format it must be in.
[26:23.570 --> 26:24.530]  That's 3647.
[26:24.810 --> 26:27.690]  And that's just so that you can compare them between CAs easily.
[26:28.930 --> 26:31.690]  Describes exactly how identity verification is done.
[26:32.330 --> 26:33.610]  What IDs are acceptable?
[26:33.830 --> 26:35.870]  How many pieces of ID you must have?
[26:36.150 --> 26:38.330]  Who is allowed to do the identity verification?
[26:39.210 --> 26:41.150]  As well as how machines are identified.
[26:41.750 --> 26:44.110]  Especially, you know, PKIs used for SSL certificates.
[26:44.430 --> 26:45.710]  How do you identify a machine?
[26:45.870 --> 26:48.470]  A machine can't, you know, come up and show you a piece of ID.
[26:49.410 --> 26:51.610]  So, most of them actually have human sponsors.
[26:51.790 --> 26:56.090]  And the human sponsor must do the, you know, they actually identify the human sponsor.
[26:56.230 --> 26:58.490]  And the human sponsor says, yeah, I'll talk for this machine.
[26:59.750 --> 27:01.590]  The CP is a public document.
[27:01.970 --> 27:03.110]  Anybody can read it.
[27:04.530 --> 27:06.590]  So, like I said, I have a link to VeriSign.
[27:06.690 --> 27:14.490]  If you really want to read VeriSign, which, you know, unless you guys have been mucking around in your trust root store of either Microsoft or Linux, you trust VeriSign.
[27:15.110 --> 27:16.370]  Just because it's there.
[27:16.830 --> 27:18.290]  Even Firefox and Mozilla have it.
[27:19.490 --> 27:27.270]  So, you know, it might be useful to read up some of these CPs of all the CAs that you trust and see what they're doing to check people's identities and check certificates.
[27:28.010 --> 27:29.950]  Most CAs have yearly audits.
[27:30.050 --> 27:31.350]  It's part of their certificate policy.
[27:31.630 --> 27:34.630]  They check, you know, does their certificate...
[27:34.630 --> 27:39.070]  There's also something called the certificate practice statement, which says, okay, here's how we meet our policy.
[27:39.190 --> 27:45.470]  That's almost never published because it has information about where things are stored, what type of algorithms are used.
[27:45.890 --> 27:53.090]  It's kind of confidential information that if it was leaked or shared, somebody could easily break into the systems.
[27:53.090 --> 27:55.450]  So you almost never find those online.
[27:55.690 --> 28:01.290]  You can actually get a hold of them if you have some kind of corporate relationship with a CA.
[28:01.990 --> 28:02.990]  They are shared.
[28:03.570 --> 28:07.610]  But there's a yearly audit to say, okay, does your CPS match your CP?
[28:08.170 --> 28:11.490]  And then are you actually following your practice statements?
[28:11.510 --> 28:12.690]  And are you following your policies?
[28:12.950 --> 28:16.390]  So when you trust a CA, you can actually request their audit.
[28:16.390 --> 28:20.770]  You might not get the details of the audit, but you'll at least get, yes, the audit passed or yes, it failed.
[28:21.510 --> 28:24.570]  So you can say, are they following what their CP says?
[28:25.590 --> 28:28.610]  So I don't know how many people have tried auditing their friends.
[28:30.430 --> 28:30.830]  Yes?
[28:34.550 --> 28:36.430]  Some of them are done by the company themselves.
[28:36.990 --> 28:39.330]  Most are actually required to be done by third parties.
[28:42.110 --> 28:42.690]  Excuse me?
[28:44.610 --> 28:45.670]  Accounting firms do it.
[28:45.670 --> 28:47.270]  Our company actually does them.
[28:48.110 --> 28:50.410]  And there's a lot of companies that do them.
[28:51.030 --> 28:55.130]  The federal PKI has a whole list of companies that they will accept audits from.
[28:55.810 --> 29:03.910]  So it's really what, you know, you want to pick somebody as a third party that, you know, other people will trust to do the audit properly.
[29:04.190 --> 29:06.290]  It's almost always an independent third party audit.
[29:06.890 --> 29:09.750]  Some of the smaller CAs may do internal audits.
[29:10.190 --> 29:11.550]  Depends on what they're used for.
[29:11.670 --> 29:13.730]  All of the big CAs do third parties.
[29:14.930 --> 29:16.850]  Like I talked about the root CA protections.
[29:18.070 --> 29:21.370]  Hardware security module, these things, these little boxes that hold the key.
[29:21.730 --> 29:23.430]  So they're never actually in the computer.
[29:23.730 --> 29:25.850]  Some of them have temperature and motion controls.
[29:26.050 --> 29:28.290]  So if you bump that box, you've just wiped out the key.
[29:29.790 --> 29:31.870]  So these things are like very well protected.
[29:32.530 --> 29:35.450]  You log in more than like twice without the right password.
[29:35.450 --> 29:38.750]  It's going to just erase the key and see you later, root CA.
[29:40.570 --> 29:41.050]  Yeah?
[29:41.410 --> 29:44.290]  What happens if an air conditioner fails?
[29:47.230 --> 29:50.510]  The question was what happens if an air conditioner fails and the temperature spikes?
[29:50.670 --> 29:52.050]  We've all had that happen in us.
[29:52.050 --> 29:54.730]  Well, most root CA's are actually offline.
[29:55.930 --> 30:00.550]  And the cards that are required to boot up this hardware module are in them.
[30:00.750 --> 30:03.910]  So they actually aren't using those protections most of the time.
[30:04.150 --> 30:05.270]  Except for when it's booted up.
[30:05.950 --> 30:13.550]  If you are actually running an HSM in an environment that you expect the heat to spike, you're going to lose your key.
[30:14.210 --> 30:15.370]  There are backups.
[30:15.730 --> 30:18.830]  Depends on what vendor you buy the HSM from and things like that.
[30:19.030 --> 30:19.430]  Yes?
[30:19.650 --> 30:25.190]  You can always have a piece of monitoring equipment that contacts you when the heat passes a certain threshold before the spike.
[30:25.330 --> 30:25.730]  Right.
[30:25.910 --> 30:29.250]  He said you can always have monitoring equipment, let you know beforehand.
[30:30.110 --> 30:35.590]  But basically, you know, if you get outside of the approved operating conditions, it's going to wipe the key.
[30:36.030 --> 30:39.550]  It's basically so people can't take the box and, you know, walk out the door with it.
[30:41.070 --> 30:47.290]  And unlike PGP, which has variable levels of trust, you either trust or don't trust a PKI certificate.
[30:47.290 --> 30:48.410]  There is no in the middle.
[30:48.610 --> 30:49.810]  There's no marginal trust.
[30:49.990 --> 30:51.730]  It's all full or not trust at all.
[30:54.130 --> 30:57.010]  PKI's web mode, also known as cross-certifying.
[30:57.850 --> 31:08.150]  Each one of these little boxes, you know, blue PKI, red PKI, green PKI, different companies, corporations, however you want to imagine it, have decided to trust each other for whatever reason.
[31:08.890 --> 31:14.890]  As an example, say the blue certificate is... or the blue CA is a... this is the FDA.
[31:15.790 --> 31:22.950]  And the red and the green are a pharmaceutical company who wants to work with the FDA to submit electronic documents.
[31:23.650 --> 31:25.850]  Well, they need to make some kind of trust relationship.
[31:26.610 --> 31:31.570]  It's a lot... for anybody who's done Windows Administration, it's a lot like a cross forest trust.
[31:32.170 --> 31:36.610]  But there's a lot of policies and politics that go into it.
[31:37.950 --> 31:41.950]  One of the problems with this cross-certifying is that policies don't always match up.
[31:42.570 --> 31:58.490]  If you have one CA who wants two pieces of identification and one CA who wants one piece of identification, those policies don't match up and you're actually not going to issue a cross-certificate because you can't ensure that your users, that you have the same identity verification across the board.
[31:59.390 --> 32:00.630]  CA's have multiple policies.
[32:01.490 --> 32:03.610]  So you can have... like Federal Bridge has four policies.
[32:03.910 --> 32:05.530]  Basic, low, medium, and high.
[32:06.390 --> 32:13.310]  And you actually can cross-certify at one or more of those levels, depending on how you define your certificate policy.
[32:14.070 --> 32:18.990]  So that kind of helps the, you know, disparities in identification.
[32:20.390 --> 32:20.870]  Politics.
[32:21.910 --> 32:32.670]  Cross-certifying with another CA just brings two organizations who may or may not trust each other, may or may not like each other, together to try to figure all this out and actually do the technical part.
[32:32.730 --> 32:34.150]  The technical part takes about five seconds.
[32:34.730 --> 32:39.270]  The rest of it takes about three to four months to actually go through a cross-certification.
[32:40.870 --> 32:45.690]  Path validation becomes much harder because, as you see, there are now cycles in the graph.
[32:46.690 --> 32:48.470]  So you have to worry about these cycles.
[32:49.230 --> 32:51.430]  And there's also interoperability problems.
[32:51.870 --> 32:54.950]  So there are multiple vendors of CA software.
[32:55.470 --> 32:59.130]  Microsoft, Entrust, Be Trusted, Chosen Security, Take Your Pick.
[32:59.250 --> 33:00.350]  There are multiple of them.
[33:01.290 --> 33:03.230]  They don't all follow the spec.
[33:04.310 --> 33:05.190]  Big surprise.
[33:06.450 --> 33:09.290]  And in fact, the spec's not all that detailed.
[33:09.570 --> 33:11.570]  There are some areas that you have a choice.
[33:11.810 --> 33:14.710]  Should, may, you know, must, et cetera.
[33:15.430 --> 33:18.630]  And when you cross-certify, you've got to work out all these technical details.
[33:18.810 --> 33:28.030]  And make sure that when one user on PKI1, you know, wants to talk to PKI2's user, that they're actually going to be able to build the path.
[33:28.190 --> 33:29.450]  They're going to be able to talk to the directories.
[33:29.550 --> 33:32.210]  They're going to be able to query the CRLs, et cetera.
[33:33.330 --> 33:36.290]  So you've got major problems on the technical, like I said.
[33:36.510 --> 33:41.110]  The technical issues, you can probably resolve those in about a day or two.
[33:41.310 --> 33:43.130]  Whereas the politics, you've still got months.
[33:45.450 --> 33:48.330]  So why do you want to... I mean, there are major problems with cross-certificates.
[33:48.430 --> 33:50.270]  So why do you even want to bother trying to use them?
[33:50.990 --> 33:53.190]  Well, very few people actually need to be involved.
[33:53.510 --> 33:55.670]  Only the owners of the PKI.
[33:56.070 --> 33:59.190]  It's usually a board group of owners.
[34:00.250 --> 34:01.710]  They're the only ones who have to be involved.
[34:01.910 --> 34:05.370]  They might bring some technical people in to answer questions and do the work.
[34:05.670 --> 34:07.390]  But very few people are involved.
[34:07.710 --> 34:10.570]  But everybody, as part of these PKIs, benefits from that.
[34:11.410 --> 34:16.350]  It's not like, oh, you know, I need to go talk to every single person because I want to trust their keys.
[34:16.590 --> 34:17.610]  Like you would in PGP.
[34:17.890 --> 34:20.870]  Just, you know, four or five people have to get together, actually do the work.
[34:21.290 --> 34:22.270]  Everybody trusts everybody.
[34:24.190 --> 34:26.410]  Policies are mapped to each other so that they're consistent.
[34:27.090 --> 34:28.470]  And then I was talking about earlier.
[34:29.410 --> 34:32.370]  The identity verification is not the only thing that has to be mapped.
[34:32.790 --> 34:35.290]  It's also the physical security of the CAs.
[34:35.710 --> 34:41.670]  It's the how, you know, how many keys are required to bring up the hardware software, hardware security module.
[34:42.050 --> 34:43.810]  You know, is it two keys out of three?
[34:44.090 --> 34:45.110]  Is it two keys out of five?
[34:45.690 --> 34:46.590]  How do you bring that up?
[34:46.630 --> 34:50.370]  All that stuff has to be kind of ironed out and figured out before you can do a cross-certification.
[34:51.790 --> 34:53.510]  But they are mapped eventually.
[34:54.310 --> 34:57.450]  And so everybody knows that I have a certificate with this policy.
[34:58.190 --> 35:01.390]  It's going to map pretty evenly to somebody with another policy.
[35:01.610 --> 35:03.610]  And you guys never even see this part.
[35:03.750 --> 35:04.870]  It's all done in the software.
[35:06.610 --> 35:09.430]  It expands the web of trust for each user.
[35:09.850 --> 35:12.510]  And you don't even have to do anything unless you run the CA.
[35:14.130 --> 35:14.570]  So...
[35:15.410 --> 35:17.190]  Now, how's the revocation done in PKI?
[35:18.210 --> 35:21.530]  Either the user or the CA can actually revoke the certificate.
[35:22.150 --> 35:23.270]  Depends on the policies.
[35:23.550 --> 35:26.550]  Some CA policies don't let the user revoke their certificate.
[35:27.190 --> 35:28.630]  It must be the CA that does.
[35:28.750 --> 35:29.790]  It varies wildly.
[35:31.170 --> 35:34.510]  How to find the revocation information is right there in the certificate.
[35:35.110 --> 35:36.370]  CRL distribution point.
[35:36.510 --> 35:38.510]  I say, I want the revocation information for this.
[35:38.630 --> 35:41.290]  I need to go to this LDAP directory or I need to go to this webpage.
[35:41.590 --> 35:42.830]  And it'll give me the CRL.
[35:44.190 --> 35:46.630]  The CA issues CRLs on a regular basis.
[35:48.690 --> 35:51.370]  Usually, I've seen it on a six hour window.
[35:51.370 --> 35:52.630]  I've seen it on a month window.
[35:52.890 --> 35:57.810]  It depends on how sensitive it is that these certificates be active.
[35:58.210 --> 36:03.430]  If somebody revokes their certificate, how long can you wait before you have a problem?
[36:03.890 --> 36:04.910]  So you can change that.
[36:05.050 --> 36:05.630]  It varies wildly.
[36:07.210 --> 36:08.870]  CRLs can be huge.
[36:10.170 --> 36:13.770]  Would you love to download a six meg file every time you want to check somebody's certificate?
[36:14.150 --> 36:15.290]  See if they're revoked or not?
[36:15.510 --> 36:17.270]  Yeah, I do this on a regular basis at work.
[36:18.270 --> 36:20.890]  Because one of our clients has a six meg CRL file.
[36:21.630 --> 36:23.970]  So one of the ways you can get around that is OCSP.
[36:24.110 --> 36:25.790]  Online Certificate Status Protocol.
[36:26.090 --> 36:26.950]  Send one little packet.
[36:27.130 --> 36:27.750]  It says, is this good?
[36:27.910 --> 36:29.130]  It sends you a little packet back.
[36:29.130 --> 36:31.270]  It says, yes, no, you trust it.
[36:31.270 --> 36:35.030]  It's also signed by the CA and by the OCSP responder.
[36:35.330 --> 36:38.550]  So you don't have... you kind of trust it by default.
[36:39.070 --> 36:40.910]  The CRL is signed, by the way.
[36:41.310 --> 36:44.070]  So you know that it actually came from the CA that issued it.
[36:45.570 --> 36:49.110]  The user of the key does not control the revocation information.
[36:49.810 --> 36:56.830]  I can't say, you know, go to CA5 for my revocation information when CA4 actually signed my key.
[36:57.330 --> 36:59.610]  So it's the CA that puts that information in there.
[37:00.550 --> 37:02.550]  So the user can't kind of circumvent that.
[37:03.690 --> 37:05.990]  So why would you want to choose PGPA over PKI?
[37:06.330 --> 37:06.990]  It's real quick.
[37:07.290 --> 37:08.270]  It's easy to set up.
[37:08.530 --> 37:09.350]  Anybody can do it.
[37:09.650 --> 37:10.610]  It's not that difficult.
[37:11.050 --> 37:13.150]  Does not require an entire infrastructure.
[37:14.070 --> 37:16.510]  PKI is called an infrastructure for a reason.
[37:17.430 --> 37:22.990]  You really need all... you need the... you need... in order for people to trust your root CA, you need to have those protections around it.
[37:24.070 --> 37:27.550]  It's best suited for informal groups, close groups of acquaintances.
[37:28.830 --> 37:31.510]  Anybody can become a CA using trust signatures.
[37:31.890 --> 37:34.390]  So if you do want to go with a hierarchical model, you can.
[37:34.550 --> 37:34.850]  It's there.
[37:35.750 --> 37:37.130]  Just make sure you know what you're doing.
[37:37.310 --> 37:39.070]  Make sure you really trust your friends.
[37:39.370 --> 37:42.770]  Make sure you trust your friends to trust them if you're going to use the T sign.
[37:43.510 --> 37:46.750]  And if you want the variable trust, you're going to have to go with PGP.
[37:46.750 --> 37:48.950]  There is no variable trust in PKI.
[37:49.270 --> 37:51.510]  So if you do... if that's important to you, you want to use PGP.
[37:52.470 --> 37:54.150]  So why would you want to use PKI?
[37:54.890 --> 37:55.330]  SSL.
[37:57.430 --> 37:59.110]  There is no PGP SSL.
[37:59.230 --> 38:00.630]  It's... it's all certificate based.
[38:01.670 --> 38:06.350]  So... if you want an SSL certificate, you're going to have to at least be part of PKI at some point.
[38:08.190 --> 38:12.370]  Distribution of keys, certificates, and trust information to a very large number of users.
[38:13.150 --> 38:22.010]  If you're talking 20,000, 100,000, 500,000 users that you need to distribute this information to, you're going to want to choose PKI.
[38:22.210 --> 38:26.570]  Because you only have to worry about controlling the root and maybe the subordinates.
[38:27.310 --> 38:34.410]  And you don't have to worry about, you know, notifying all these users that things are revoked because the infrastructure takes care of it for you.
[38:35.810 --> 38:37.770]  You have more control over your subordinates.
[38:39.090 --> 38:41.590]  So if you don't follow their policies, you can revoke them.
[38:41.590 --> 38:50.130]  So if I sign my friend Doc's key and I find out he hasn't been checking IDs, you know, I can't... it's very difficult.
[38:50.310 --> 38:54.730]  I can revoke my signature, but it's difficult to publish that information.
[38:55.350 --> 38:58.690]  So, you know, it's kind of difficult to revoke in PGP.
[39:00.030 --> 39:02.390]  PKI actually allows legal document signing.
[39:02.670 --> 39:14.290]  In both Europe and the U.S., a PKI-based signature from a trusted CA, whatever you define as a trusted CA, is actually considered a legally binding signature on a legal document.
[39:15.310 --> 39:18.350]  So that PGP does not share that status as of right now.
[39:19.430 --> 39:25.290]  So, yeah, it's great for, like I said, pharmaceutical companies submitting clinical trial data to the FDA.
[39:25.290 --> 39:28.050]  They can sign it and say, yes, I've checked it.
[39:28.150 --> 39:29.970]  I, you know, I support this information.
[39:30.110 --> 39:30.830]  Send it to the FDA.
[39:31.290 --> 39:33.350]  That is actually a legally binding signature.
[39:35.150 --> 39:35.590]  So...
[39:35.590 --> 39:38.190]  So how can you participate in PGP or GPG?
[39:38.790 --> 39:39.450]  Download it.
[39:40.330 --> 39:42.050]  You know, GNU-PG is probably the most popular.
[39:42.170 --> 39:42.750]  There are others.
[39:43.750 --> 39:44.610]  Generate your keys.
[39:44.850 --> 39:45.570]  Make friends.
[39:46.150 --> 39:46.630]  Start signing.
[39:46.970 --> 39:48.210]  Host a key signing party.
[39:50.290 --> 39:54.370]  You know, I actually, I'm not going to sign any keys because I haven't changed my key name yet.
[39:54.490 --> 39:56.010]  I just got married and changed my name.
[39:56.010 --> 39:58.510]  So my key hasn't been changed yet for PGP.
[39:59.730 --> 40:01.450]  You know, 2600 meetings, lugs.
[40:02.010 --> 40:03.110]  Get your friends together.
[40:03.310 --> 40:04.090]  Have a key signing party.
[40:04.290 --> 40:04.870]  It's not difficult.
[40:05.130 --> 40:05.870]  It's fun.
[40:06.070 --> 40:07.450]  Have a couple beers with it.
[40:07.590 --> 40:08.170]  Beers and pizza.
[40:08.850 --> 40:11.550]  And then publish your key to a key server so that other people can use it.
[40:13.270 --> 40:14.750]  So how can you participate in PKI?
[40:15.230 --> 40:17.970]  There are several public PKI's.
[40:18.230 --> 40:19.190]  CA cert is one of them.
[40:19.750 --> 40:20.970]  If you use it, please donate.
[40:21.170 --> 40:21.810]  I am an assurer.
[40:21.950 --> 40:23.030]  I can assign 100 points.
[40:23.050 --> 40:27.630]  So if you fill out the documentation, I can assure you if you find me later.
[40:28.470 --> 40:34.150]  Basically, you have to build up a certain number of points by getting your identity verified by multiple people or by notaries.
[40:34.890 --> 40:39.430]  I actually went through the trusted third party model where I had to go to two notaries.
[40:39.430 --> 40:44.830]  They had to check two pieces of ID and I had to send them off to Australia to the CA cert.
[40:45.110 --> 40:48.210]  They assigned me 150 points, which makes me an assurer.
[40:48.630 --> 40:52.570]  And because I went through that process, I can now verify people's identities.
[40:53.970 --> 40:55.570]  Unfortunately, I can't make you an assurer.
[40:56.070 --> 40:58.950]  I can only assign up to 35 points per person.
[40:59.570 --> 41:02.570]  So you have to find two other assurers as well.
[41:03.410 --> 41:07.550]  If you want to go through that process, you can go ahead and you can talk to me there.
[41:09.130 --> 41:10.950]  There's also the thought web of trust.
[41:11.630 --> 41:13.890]  Very similar concept, but it's run by thought.
[41:14.370 --> 41:17.130]  You can get a PKI certificate from VeriSign for a fee.
[41:17.270 --> 41:18.250]  I think it's 15 bucks.
[41:18.310 --> 41:21.930]  It used to be 15 bucks, 14.95 for an email only signature.
[41:22.290 --> 41:25.750]  Basically, they check your email and they're going to charge you 15 bucks for that privilege.
[41:26.630 --> 41:28.330]  And it goes progressively up from there.
[41:28.910 --> 41:35.870]  If you want your organizations verified by VeriSign, they're going to charge you about $4,000 or $5,000.
[41:37.050 --> 41:41.970]  So, but they really actually like check stuff according to their CP.
[41:43.870 --> 41:46.370]  You know, private PKIs, you can make your own.
[41:47.050 --> 41:48.890]  You know, OpenSSL is a great CA.
[41:49.290 --> 41:51.090]  Not a very good interface, but it works.
[41:52.510 --> 41:54.970]  Unfortunately, probably nobody's going to trust you except for your friends.
[41:56.050 --> 41:58.790]  This is where most of the self-signed certificates on the Internet come from.
[41:59.190 --> 42:00.830]  Your employer might have a PKI.
[42:01.250 --> 42:04.990]  If you work for a federal government, a lot of the big pharmaceutical companies have them.
[42:05.190 --> 42:07.030]  A lot of defense contractors have them.
[42:07.230 --> 42:09.910]  A lot of schools have them for school employees.
[42:10.670 --> 42:12.850]  And actually, a lot of countries have them.
[42:12.950 --> 42:15.190]  Taiwan and China have their own PKIs for government.
[42:15.230 --> 42:16.330]  And so does Australia.
[42:17.310 --> 42:23.950]  So, you know, if you're also part of a trade or professional organization, they may have their own PKI in order for you to get a certificate.
[42:23.950 --> 42:28.230]  So, if you're a member of, you know, check your, if you really want like a real PKI certificate.
[42:28.490 --> 42:30.670]  And you don't want to pay VeriSign, you're a couple hundred bucks.
[42:31.030 --> 42:36.050]  Check with your employer, your school, you know, any professional organizations you're a part of.
[42:36.290 --> 42:39.050]  And they might have those PKI that can sign you a certificate.
[42:40.610 --> 42:41.890]  So, any questions?
[42:44.390 --> 42:44.830]  Yes?
[42:45.290 --> 42:49.170]  What happens when the CRL distribution point changes?
[42:52.450 --> 42:57.590]  Basically, you get a, I have no clue what the revocation status of this certificate is.
[42:57.710 --> 42:58.750]  I'm not going to trust it.
[42:59.530 --> 43:03.710]  What most people do is actually a big deal when a CRL DP changes.
[43:04.890 --> 43:06.830]  Of course, you can change DNS.
[43:07.430 --> 43:10.330]  You know, you've got a machine died, you bring another machine up, change the DNS.
[43:10.650 --> 43:11.370]  That's one option.
[43:11.670 --> 43:16.330]  But if for some reason, you know, the name of your organization changed, you have to reissue all those certificates.
[43:17.390 --> 43:26.650]  So, you want to actually, like, when you actually deploy and implement a PKI, you're probably going to spend six months to a year thinking about all of this stuff.
[43:26.930 --> 43:29.410]  What happens if the CRL DP goes down?
[43:29.590 --> 43:31.950]  What happens if the root CA gets flooded out?
[43:32.070 --> 43:34.850]  What happens, you know, if the data center gets blown up?
[43:35.130 --> 43:39.810]  You know, all that kind of stuff, you know, basically backup disaster recovery planning, you've got to worry about.
[43:40.630 --> 43:43.510]  So, it takes a lot of planning to do a whole infrastructure.
[43:43.510 --> 43:45.050]  I saw another hand.
[43:45.450 --> 43:45.970]  Yes?
[43:46.110 --> 43:54.670]  There are actually standards, RFC standard tracks for the ITF, for using PGP keys in TLS.
[43:54.910 --> 43:55.430]  Okay.
[43:56.270 --> 43:59.850]  The only implementation I'm aware of is in GNU TLS.
[44:00.370 --> 44:05.810]  The SSL guys and the open SSL guys and maybe you guys have been dragging their feet on this one.
[44:06.110 --> 44:07.670]  A bit of a chicken and the egg problem.
[44:07.670 --> 44:08.130]  Okay.
[44:08.770 --> 44:16.330]  So, what he was saying is that there are, there is a working group in the ITF that is using PGP for GNU TLS.
[44:16.930 --> 44:20.430]  So, if you want to examine that, like, do you know what the status is?
[44:20.630 --> 44:22.450]  Uh, GNU TLS fully supports it.
[44:22.470 --> 44:24.450]  Okay, GNU TLS fully supports it.
[44:25.210 --> 44:27.870]  So, what's up, back there?
[44:28.190 --> 44:36.150]  Uh, you said that on PGP when you do trust features that you have a green or a logical sign?
[44:36.330 --> 44:36.730]  Yes.
[44:37.010 --> 44:41.750]  That they sign one key that you fully trust that other key?
[44:42.330 --> 44:45.390]  It just means that you will, that key will validate for you.
[44:45.490 --> 44:48.470]  So that when you check an email, that signature shows up as valid.
[44:48.590 --> 44:50.230]  It does not mean that you fully trust that key.
[44:50.430 --> 44:50.870]  Okay.
[44:54.100 --> 45:02.200]  If you fully trust one key, you know, if you sign Bob's key and Bob, you know, you fully trust Bob, then you'll trust that key.
[45:02.420 --> 45:03.560]  That Bob is signed.
[45:03.860 --> 45:05.080]  I saw another hand.
[45:05.340 --> 45:05.740]  Yes.
[45:09.610 --> 45:10.950]  PGP hardware smart cards?
[45:11.190 --> 45:11.350]  Yeah.
[45:11.470 --> 45:12.090]  Who has those?
[45:12.510 --> 45:14.330]  Uh, it's a company in Germany.
[45:14.950 --> 45:16.650]  It's a kernel concept, essentially.
[45:16.990 --> 45:17.570]  Kernel concept?
[45:18.070 --> 45:18.590]  It's... a...
[45:40.050 --> 45:40.490]  Okay.
[45:40.730 --> 45:43.970]  So the smart cards from a company in Germany, you think, crypto?
[45:45.170 --> 45:45.610]  Kernel concepts.
[45:45.790 --> 45:46.430]  Kernel concepts?
[45:46.950 --> 45:52.510]  And somebody's gave me a note that Exalto, which I think is now Gemalto now, supports a PGP hardware token.
[45:53.950 --> 45:57.110]  Are they all smart cards or are they also USB format?
[45:57.270 --> 46:00.070]  There's a lot that does know that both smart cards are USB token.
[46:00.350 --> 46:00.610]  Okay.
[46:00.610 --> 46:00.870]  Okay.
[46:02.270 --> 46:03.850]  And I saw another hand back there.
[46:03.850 --> 46:04.450]  Okay.
[46:04.450 --> 46:10.690]  I just have a quick comment about, if you want to use BGP or DGP yourself, be sure to protect your private key.
[46:11.430 --> 46:14.290]  You need to make this secure or safe online backup.
[46:14.850 --> 46:16.330]  So he's...
[46:16.330 --> 46:18.790]  Public service announcement, protect your private key.
[46:19.430 --> 46:21.150]  Keep a secure offline backup.
[46:21.930 --> 46:25.510]  I just googled into the PGP.com and see two different smart cards.
[46:33.000 --> 46:35.480]  Smart card infrastructure, it's like OpenSC.
[46:35.760 --> 46:36.280]  Okay.
[46:36.280 --> 46:43.180]  So he's a GPG agent, actually uses like OpenSC, some of the smart card algorithms for talking to smart cards.
[46:43.480 --> 46:44.720]  Also the...
[46:45.340 --> 46:48.040]  I can't tell you, if you push hard enough, you can use your TPM.
[46:49.200 --> 46:51.060]  If you push hard enough, you can use your TPM.
[46:52.560 --> 46:53.580]  I have to play with that.
[46:55.820 --> 46:58.580]  Because the TPM doesn't have native support for SSL either.
[46:58.660 --> 46:59.700]  But you can't store your key on there.
[47:01.180 --> 47:01.640]  So...
[47:01.640 --> 47:01.870]  Yeah.
[47:03.720 --> 47:04.180]  So...
[47:04.180 --> 47:05.200]  Any other questions or comments?
[47:06.700 --> 47:07.160]  Okay.
[47:07.400 --> 47:08.260]  Thank you all very much.
[47:25.690 --> 47:27.870]  I think I was talking about the same one he was.
[47:28.070 --> 47:29.170]  They're 35 bucks.
[47:29.330 --> 47:29.530]  Are they?
[47:29.670 --> 47:30.030]  From the...
[47:30.030 --> 47:30.690]  From Gemalto?
[47:30.930 --> 47:31.330]  Yeah.
[47:31.330 --> 47:31.470]  Thank you.