 Thank you very much everybody. The question here is how do we get the world to start using message security? I don't have to explain to any of you why we need to be doing this, why it's a good idea. I don't have to go through the obligatory, oh your information is at risk, you know, CSIs, statistics and so on. We need to be doing this. An SSL alone doesn't solve the problem. While it is certainly a good thing to be using, and we use it all over the place, particularly when it comes to the case that was just in court in Massachusetts, it protects you against the places where it would have been illegal to intercept your traffic. So, you know, the places where it would be illegal SSL will protect. Anytime your message sits at rest, even for a millisecond, they said, and I don't know whether that's literal or figurative, then it's okay to snark your message. So you've got to be encrypting them. And because of this, anybody who's got a backup MX is taking your messages, whether they want to or not, whether they're malicious or not. And that's why you have to encrypt the content of them as well. Also, the people who need the most security understand at the least. Public key cryptography is not easy to understand. That I have been spending years and years trying to get people to understand it and they don't. The attitude that you see a lot of times, what I'm calling blame the victim attitude, oh you shouldn't click that, oh you should remember to do that. Just doesn't work because it gradually dragged down security because it only needs one or two percent of people to accidentally click on something to flood the network with little zip files. Or similarly, if you're a smart person, you might make a mistake. I mean there was a case where I was doing an email conversation with my business development guys who happened to be in Japan and one of them forgot to click the encrypt button. And so, you know, there's this entire conversation including bits and pieces of the previous ten messages all sent unencrypted. It's like oops. So, while doing security correctly, having good discipline about it is a good thing to have. That's not what we need to be doing. It isn't working. Security and human factors are cutting edge right now. There are people who are doing research, years so ago, Alma Witton who is now at Google, got the first PhD in the human factors of security, Simpson Garfinkel is now at MIT doing a PhD on human factors of security and it has to be easier for people to be secure than to not be secure. You have to make it so that people will by default follow good security practices and this requires patience, testing, more patience, humility, because people are going to say, I don't get that and your wonderfully designed human interface is not going to work. So, you have to go back and see what it is that they didn't do and make it so that it works correctly. It's how we got windowing systems to work. It's how we're going to have to get security to work. Now, here are a few references. I'm not going to go into these a lot. Really good book that has been an inspiration to me between Silk and Cyanide. It was done by Leo Marks. He was British SLE Operative who was teaching people how to use crypto before he dropped them behind any lines in World War II and they didn't do things correctly. It is interesting to see what happens when people whose life is literally on the line have other things to do. Also, the Veneno project and Witton and Tiger is why Johnny can't encrypt all great papers on why this is important. Now, you can play everything I'm talking about, too. I'm building systems that work this way right now. For example, I'm giving you the design principles and how we're putting together my new PGP Universal things. We are already interoperating with people like Hushmail. We are discussing all the time with the GPG guys. Also, we're talking to the crypto mail guys who have some really good ideas and will be here at four o'clock to talk about what they're doing. We're building things based upon open standards and open source that there is very little here that we are inventing new. The infrastructure has been built. The roads have been built. We just need to start building cars to drive on them. And as I say here, good artists steal bad ones borrow. Okay, one of my principles on this is to beware the security cliff. There are too many times when you start worrying about all the conditions and you end up where you say, well, you know, if you consider the fact that DNS is not particularly secure, then we might as well not bother. Well, you know, if you have to solve that, if you have to solve all of the problem, you end up with, you're either at the bottom of the cliff or at the top of the cliff. It's hard to climb up it. And most people will stay at the bottom because it's easier and cheaper and a lot of other people there, too. Remember also that when Phil first did PGP, he stood for pretty good privacy. The idea that he had was that you could not guarantee that people wouldn't hack your disk, that you wouldn't have viruses, that there wouldn't be all these other things that he just couldn't worry about. And so the whole idea is that you start rolling things in and you make it better. And next year you make it better. And next year you make it better. This is the continuous improvement process. Another principle that we're doing here is that by changing some of the risk reward equation, you can get dramatically different effects, especially when you want to take off some different things. And I'll go into some of that as I go on. Another principle, format agnosticism. No more format holy words. PGP is better than the other things. I believe that. I wouldn't be working at PGP if I didn't think of it. But the others are good enough. If you want to hear what I don't like about other standards I will tell you later, but they're good enough. It's also much better to have multiple simple protocols than to continue to make one protocol that will handle every weird condition that everybody has. So we're getting more of them. I'm going to be next week at the IETF working on some anti-spam signing things. It's another good standard and it would be much better to have a thing that does header protection than to try to jam header protection into the existing things. When new standards come out, if they're useful, people will use them. One of the other things that you can do that is innovative is you take the same key material and you wrap it in different bundles. We're doing this right now. So when you create with our servers and you have a key created for you, we make it as a PGP certificate. We make it as an X509 certificate. Which way do you want it? Anything you have. The first thing that you want to do is outgoing messages, sign in and encrypt them. The principle that we're using is the proxies are your friend. You put together a network proxy instead of having plugins which are really difficult to do, constantly being changed. You take the actual protocol which is much more stable than anything else. You take the message, you can find who it's to, you can see what things are going, you encrypt the message, send it on. By finding out what type of certificate you have, somebody's got an X509 certificate, they'll probably want an S9 message. If they want to have, if they've got a PGP certificate, they're probably going to want to do that as a PGP format message. This isn't new concept. When I started doing this, I kept finding out more and more people who had the idea. I mean, there's a Nubis which is an open source system out there that is an outgoing SMTP proxy, seven, eight years ago, Ian Brown in the UK, whose doctoral dissertation was outgoing SMTP proxy. You can also combine this with other systems like domain keys. Now there are some hard parts on here. One is what happens if you have one message that goes to different people with different certificate types? And the answer is you have to split it into two messages. One of the other things you have to worry about is blind carbon copy. Somebody sends a message to two people and then blind carbon copies it to three of them. You don't want to encrypt it to all five people because that means the people know who you've got, who are the blind recipients, and you leaked information that way. So one of the things that you have to do in this particular case is that you have to break up the message and send separate messages out. If you have the thing that I described, you're going to have to send essentially four copies of the message to the two main recipients and then one to each of the blind carbon copies so that nobody finds out that the others exist. One of the things that we're doing that is different is incoming decryption. This is how you get the people whose VCRs blink 12 to actually start using things because one click encryption is one click too many. Now you can in fact have the system and ours does interoperate with anybody who's got end user decryption. You've got PGP, GPG, you've got an S-Mind certain outlook you name it, we can interoperate with that and it works just like that before. The main effect that you see of these servers start appearing is that you start getting more encrypted messages. You can also have the servers go gateway to gateway. The advantage of this is that this has the least disruption on the network. You can drop one of these things in and people don't see it. You can also have any sort of automatic virus scanning, content filtering, so on and so forth continue to work. For other people who are doing things, they have regulatory requirements like financial institutions have so many requirements on them. One of the interesting things that's going on now is that the restrictions that are on people using crypto are not what it used to be where it was you might be a scary money launderer or terrorist, it is you might be Enron or Martha Stewart. This is a huge change. Now if the server has the private key for somebody you can decrypt their message and you can hand it to them and this is very useful. We do this, we also write in little messages of we've decrypted your message, we verified the signature you can have all of this working interoperably with people doing all of these things, sorry, at the same time. The hard parts of this are IMAP is a bearer. POP is a pretty nice protocol because you can lie to POP. If POP says how big is this message and you say oh it's 12k and it turns out that it's 15k or 4k, POP doesn't care. IMAP wants the exact byte count down to the last one. So this means that when you proxy IMAP and you are decrypting a message that has signatures, it's been compressed, it's been encrypted, you have to figure out exactly how big it is at the time when it's saying oh I just want the subject lying. This is harder than you would expect when we first started on this we thought no, no, no, no, no, you have to do both POP and IMAP. If we'd known how hard IMAP was, we might have said IMAP would come in version 2. The other hard problem that you have to deal with is anti-spoofing. Because you are writing in messages to the people who are smart about other things in crypto that says I decrypted this message for you, I verified the signature, you have to take into account the fact that somebody could send a message that just has the plain text in it, this thing was signed and verified correctly. So the total problem is very difficult to solve. However a good partial solution is relatively easy to solve and we do that in there where if we see for example somebody saying they put the line in that says PGP signature verified, we changed the little PGP to say old signature verified. In that way you know that you are not getting the same message and somebody still got to have to have a little bit of intelligence but it's not a spoofing problem. Oh yeah, them. Exchange, notes, group rise. They don't use standard protocols. They also use really nasty RPC based protocols and lots of people use them. In the business world probably about 70% of all email is running on one of these three systems. So you have a lot of work to do and I could give talks on each of them of what you have to do and I'm just going to go buy them, they're hard. That's also, since they're non-standard I'll skip by that. I'm going to get on to the power of proxies. Like I said before, proxies are your friend. There are all sorts of places that you can put a proxy and you can use the proxy for things. You can put it on a stand-alone server, which is one of the things that you're doing. You can put it on the end machine, which you've seen starts of what we're doing if you've looked at PGP Universal, we call this a universal satellite, but that's where the future is as well, is proxies on the local system. Everything in the world now that's an end-user machine just about is either going to be running some variant of Windows NT or it's going to be running some variant of Unix. And you have an equivalent of Divert Sockets, you have an equivalent of Firewalls in the same place, you can intercept ports and you can do the right thing. One of the important things that this allows you to do is it allows you to migrate away from the plugins. Plugins are absolutely way more experienced with them than anybody else. They're horrible. The APIs that you get given to use them, don't do what you want. They change them. They change them again. We had, as an example, several years ago there was one notorious bug where Outlook would call the prox, the plugins for the mail sending out for the plain text version, but it would also very helpfully send out an HTMLized version of the same message, which it would not call the plugin for. So anytime you use the Outlook plugin, you would get a helpful HTML plain text version of your PGP message just in case the person couldn't read it. So that was not our bug, but we got blamed for it. Similarly, when Outlook 2003 came out, between the last developer seed and the time that Office 2003 was released, there were enough changes that nobody told us about, that we had to do about a month's worth of work, to handle all sorts of weird cases like what happens if you were running Office 2001 and you only upgraded Outlook, or you were running Office 2001 and you only upgraded Word. Both of these had interesting weird bugs that had things work peculiarly. So we wanted to get out of this business. I can tell you some more. There was the time when the only way we could make the UDOR plugin work was to take advantage of a memory leak, and then they fixed the memory leak. It's hard explaining to people that you're adding security by taking care of their memory leak errors. So being at the protocol means that no matter what client somebody is using, as long as they're using the standard network protocols, they're using SMTP, they're using pop, they're using iMac, we can do the right thing. It also allows us to do some really other cool things. Like for example, you can have an email client that thinks it's doing port 25, just plain old SMTP, but actually what we're doing is we're wrapping TLS around it, moving it to the SMTP submission socket, 465 or 587, and that way you get SSL encryption bundled on top of it. Similarly, we do similar things where if you're just doing pop and iMac, we move you to the SSL version. So if you open up an unencrypted link, we move you to an encrypted link. And the app doesn't know. This also has other great things that we could do in the future. We're already doing experimentation with instant messaging, where you can have transparent encryption going right into anybody who's got the thing installed. You can do file serving this way, you can do theoretically voice over IP, other things. Once you know how to do pluggable proxies at the network level, there's all sorts of magic that you can do that you couldn't do otherwise, and it's a lot easier. Okay. I talked briefly about how you encrypt, decrypt, sign, verify automatically, but how do you find the certificates? How do you find people's keys? Well, there are a bunch of existing systems that are out there, particularly there are LDAP servers, there are some HTTP servers. Neither of these is what I would suggest. If you asked me what would be the best key serving protocol in the world, I would not pick LDAP. However, it is out there and it works. So we use it. There's also a really good open source implementation, open LDAP, and yes, yes, every time I say this people will tell me about what a pain in the neck it is. It, you know, lots of open source is not easy to use. But nonetheless, it works, it's robust, it is a very nice thing to have, and all you have to have is the right certificate scheme that you can stick them in there and things will work automatically. Our proxies will then go out and if you imagine that I'm sending the message, we have heuristics on how to look for certificates. One of our heuristics is that we look for keys.domain. So if you're sending a message to me, it'll go look for keys.pgp.com and it'll go to the LDAP directory and say, hey, you got a certificate for John at pgp.com it gets handed back to you and then proof you go, you're done. This technique will work with any certificate type. It'll work with anything that nobody wants to do for the new ones because there are people talking about XML based ones. In the future, there are things that we could go over to to make them better. Like for examples, you could make a very simple SOAP based protocol to do key searching. This is a good place for expansion, but on the other hand right now, like I said there's this perfectly good system that's out there and if you use it, things will interoperate. The public key server networks as they exist today have a number of flaws in them. One of the ones that is perhaps the most of a problem is that it's the Liberia Tar Pits. Once a key goes in, it does not come out. There's also only aggregation in there. So the classic problem is somebody gets all about using PGP, they go and they make themselves a key, they put it up there and then three weeks later is the first time that they actually get to use it and they can't remember the passphrase they put on the key. And because they can't remember the passphrase, they can't delete it from the key server. So what is advertised as the way to encrypt a message to them is in fact the way to destroy data. It's like encrypt data that you can't decrypt great way to destroy it. So we are actually building now and you will see in the next few months a key server that you can consider to be sort of a cross between normal key servers and mailman. You submit a key to it, we send you an email message and we say, hey, do you really own John at PGP.com? So you reply to that and it says fine, in six months I'll check it, we're in with you again. And it marks these things as being keys that are on, that have been verified at a certain date so that they have some moderate level of trust. This again is not a new concept. There's the robot CA, there are other people who have come up with very similar concepts. But the idea behind this is that you want to have an assurance that what is in a global public directory is reasonably accurate and that when people have bad data in it that is about them, but they can get rid of it. So you want to be able to have it so that when you lose a key that you can with nothing more than an email round trip delete the key. There is a really interesting paradox about key storage. There are some keys that are so valuable they got to be held really securely and you only want one copy of them. And on the other hand there are some keys that are so valuable they have to be easily recoverable. They're frequently the same keys. There are some keys that aren't very valuable so you don't mind if they get destroyed. And there are some that aren't very valuable so you can put them in weak storage and they're frequently the same but sometimes they're the others too. In human terms what this means is that about one person in 200 loses a password per week. This is what people who run help desks have told me as figures. So that's about one half of one percent per week of your users. So if you are running a help desk for a company of 200 people you'll get an I lost my password once a week. Now they also say that roughly half of all help desk calls are password resets or other things. Password problems and strong crypto are really bad. There are lots of people, the ones who are smart about other things that can't be trusted with their own keys. They're going to lose them. And when they lose them they won't be able to decrypt their email and they'll get really angry. So you have to have a way to protect these people from themselves. You have to have a way that they can get to the data because it's the data that's important. There is very little data in the world that must be lost before it is compromised. There's a lot of that where you'd rather the data be lost than it be compromised. But all those health records, HR things, the documents that you're sending around back and forth you want to keep those. I would not have wanted to lose this ten minutes ago. So we've introduced what we call server managed keys. These are keys as opposed to client managed keys which are the ones you know and love. We'll automatically create these for users who need them and we create them in whatever certificate format you like. You can convert them back and forth and we also mark them as being server managed keys. When I was writing RFC 2440 years ago, I put in a lot of features that we're only getting to use now. Like for example, red key server your key might be on so that if you want the definitive copy of it, where to go to. And one of the things that I put in was a little bit that said this key might also be in the hand of someone else so that you can know that this is not necessarily a secure key, somebody else's key. Every time we make one of these server managed keys, we mark that bit on it so that when you look in the UIs you can see that this is a key that has been handed off to a server and if you are really, really, really of the opinion that you rather have the data lost than compromised, maybe you want to get a different one. But you know, for most purposes, everything else is good enough. And this is how you let people whose VCRs Blink 12 have some sort of management, is that the server will do these things for them. We call the system that we're doing this self-managing security. I wrote a paper a couple of years ago I called it the self-assembly PKI. And this is again where proxies are your friend. You look at a connection that somebody's doing. Every one of the connections that I've been talking about has a, here's who I am, prove it, here's my proof, okay. So when you're a proxy all you have to do is sit and wait for the, alright, you're really authenticated. And then you say, ah, this is my user. You go look in your database if there isn't a key for them, you make one. If there is one, you know that this is your bare key and you should be using it for them. This has a number of other security advantages in that, for example, you don't have to have the passwords stored on the server. The server that's doing this doesn't have to know who you are. It's using the fact that it is in a privileged part of the network, like right next to the mail server, to be able to leverage the security weight forward. One of the first papers that I wrote about this, I called the man in the middle of defense. As opposed to the man in the middle of attack. This is the man in the middle of defense. You can create people's keys. It doesn't matter whether or not they're using smart cards or passwords. All you gotta do is observe the authentication and when it worked you know that they're your person. Another thing that you can do is use short-lived certificates. If you own the person's key, you can actually completely rewrite the certificate. If you don't own their public key, so their private key, what we do is we have an equivalent of a raw CA. There is a key signature in PGP terms that is on there that says, I verify that this is one of my managed keys. Where the occasion is the big problem that there is with any sort of crypto? How do you pull back a key? The first law of data-driven programming is that when you have emitted a data you can't pull it back. You can't unsay something. This is why in a lot of other protocols, look at what the network does. Look at what DNS does. There's a time to live on things. Whenever they hand you a little translation, they say, this is how long it's good for. If you consider the life of your certificates to be similar to a time to live, you can cut down a revocation problem. My servers, for example, will typically re-sign certificates once a week. The advantage of this is that as long as a user has logged in any time that week we know there are user and we just re-sign their certificate. If you have something where somebody leaves the organization you can pull the certificate out of your key server database and anybody who's got a copy of it, it's going to expire in a week anyway by the time you could track down everyone to say, hey, that one isn't good anymore. You just let it expire on its own. This is a way of using the same old standards in a new way, because typically when you create a certificate you create a new key to go with it. We keep reusing the key and we have a re-sign interval and we also have an idle time interval. So, for example, you might re-sign every week and if somebody hasn't logged in in three months you can't move from the database. This also allows one other very interesting thing which I call revocable revocation. You say, so why would I want that? Well, imagine that you work for a company and somebody leaves the company and then two weeks later they decide, oh wait, they're going to come back for another three months, because there's some stuff we need to have them do. Well, this is a place where you've already left. You took them out of the HR database and now you're bringing them back for a short time. And this is where you need to revoke your revocation. Short life certificates and you'll drive off of the LDAP servers is a way that you can manage keys in such a way that you get the maximum utility out of them. Because you don't care if something is out there and is expired. Now the classic problem that you have once you've done all of this is what do you do with people who don't have any certificates whatsoever. It's four o'clock in the morning. You're supposed to deliver a proposal to somebody by eight. You want to get the final review copy over to someone so that they can read it and they don't know anything about PG what. The solution that we have is web delivery. It isn't great but it works. There are two flavors that we have of it. One is, well they both work so that you send a pointer message to somebody that says John Kellis would like to send you a secure message. Please click this HTTPS link. And they click the HTTPS link and they're taken back to a web server where there's essentially a small web mail-in box. Now the problem is what do you do about the first-time authentication? There's the make it work solution which is that you figure that the very first message you send someone is not going to be intercepted. It's going to be something in the middle. It's going to be an established relationship that gets broken. If you don't like that we can have it so that the sender of the message gets a randomly generated password and then has to figure out how to get it to the person that they sent the message to. Which is much harder to explain to people whose VCRs blink 12 but it is more secure and take your pick. You can do either one. You also have to worry about what happens with spoofed messages this way. This is one of the hard parts. This is a trade off between usability and security. It is a if there were a better way and there probably would be one once we think of it. We'll come up with one. But for right now it handles a lot of edge conditions where you need to have something else. Again this is also not new. There are all sorts of other systems that use web delivery as the delivery of last reserve. One last problem. I know you've all been saying hey wait a minute you're talking about servers that have private keys sitting on the disk. What happens when that gets hacked? Because eventually it will. The best security is to have a hardware security module. Something like an encypher card. These are really nice systems. They've got accelerators. They have all sorts of really nice barriers in them so that you can make sure that there's no way that anybody can get to the key material that's in them. The really good ones will even do things like detect hardware tampering and zero themselves. Unfortunately they are expensive. They typically start at a few grand. 3, 4, 5 grand and go on up into the 10, 15, 20 grand per pop. And this adds to the cost of your email server especially when the sorts of things that we're talking about for servers will run on a $600 Dell server. So there needs to be also something that's better than that in the middle. We have an idea that we're building what we call the admission key. And the admission key is a plain old smart card. We take the private key database and we encrypt it to a key that is only on the smart card or on copies of the smart card, not anywhere on the computer itself. And when the system boots, we run the key database through the smart card which because it's typically 9600 watt is not fast but you know what the heck. You only want to do this once. But then you store it in MWAC memory off in kernel space where nobody is going to get it. It's not going to get swapped out or anything. And you use them from an in-memory database. This is a trade-off but it's better than having private keys sitting on the disk and it's also a lot cheaper. It is the $50 solution and if you really want the $4000 solution then you need $4000. To sum up on this so that I have time for some questions the way that we're handling this is worth rethinking the problem. We're saying what are the barriers that are making people not do encryption? What can we do to make it easy for those people? And what are the real effects of a trade-off that we make? We really do need to have simple, easy to use brainless crypto. I now have a server that my 70-year-old parents do encrypted email on and they don't even need to know. All they do is is pop over SSL and SMTP over SSL and they've got encrypted messaging to anybody else who's playing this game too. My VP of HR who gets really big eyes any time I say the words public keys, all of her messages are now encrypted. So the goal on this is to start ramping up the security to get rid of the cliff and to make it be something that people can slowly go up. You get some security now, you get some security better, you get it interoperating with the people who are doing the good stuff. This is important as well. Remember that in the battle of days when there was good crypto and exportable crypto, the our opponents didn't want them to interoperate and the reason they didn't want to interoperate was they wanted to get a rise as many people into bad crypto as possible. By making them interoperable, you make it easy for people to keep sliding up the ramp and to get more security tomorrow than they have today. Also, the existing infrastructure has all the pieces that we need. We don't need to go rebuilding all the new things. All the pieces are there, all the standards are written. There are starting to be more and more people who are starting to work on this with us to make sure that we get network effect and that in a few years, I hope, you'll really see a sizable percentage of the network with encrypted e-mail. Thank you very much and I'll take questions. I'll repeat the question. He was saying that based upon some conversations that he and I were having before, he's asking if he puts together an LDAP server and starts putting PGP keys in it, will it start interoperating with that? And that is that yes. We have LDAP schemas for open LDAP, NDS, active directory and iPlanet. If somebody wants them, ask me. You can put this schema in your LDAP directory and when you put your PGP keys in with this schema, they become available to all parts of this system including us and Hushmail, who will then start encrypting e-mail to you automatically. The answer was what happens when the certificates deliver trust? The short live on it is the life of the signature on the certificate. So if I have for example a PGP key that says that it was created on this Friday and will expire next Friday, when you come back next Friday, it'll say it starts this Friday and comes back next Friday. So all you have to have is the current version of it. The certificates that we're building now also have a URL of where to get the definitive version of it. So all you have to do is look in the certificate, find out where to get the new one is and if it's expired, see if there's a newer one. And if it has the same public key and the same trust, it's just a difference, it's just a different CA cert or a user cert because the user certifications, people signing each other's keys, don't have to have these online. You can have those continue to have whatever long or infinite life that you want. Okay, his first question was about encrypting the thing on the database. The trade-offs that we're having to make is that a smart card is a very slow device. It's an 8-bit microprocessor hanging on a 9600 board line. So the actual mechanisms that we're using are to get the keys out once, one at a time, and do a bunch of them based upon locality of reference, ones that we know have been used and then we'll pull the other ones in slowly. So that's the way that we're doing it for that. The other question was about LDAP and firewalls and difficulties of that. And yes, this is one thing where frequently people don't have a hole in their firewall for LDAP. That is a reason why experiments and things like soap-based systems which would then run over red ports. I mean, this is why everybody who has a protocol seems to be turning it into some web thing because 80 and 443 are allowed through. And that may be a direction that we have to go. Right now, we tell people that you control your flow of where you want your keys to go because some people say, I don't want my key database accessible to the entire world. The answer to that is to have authenticated LDAP over SSL. But if you want it available, then you have to control it in the firewall. It's just one board. The first question was, who is we? And I'm sorry about that. The we was PGP Corporation, my company. And there was also a we that I used a little bit freely that included people that are already doing these techniques with us like the people at Hush Mail who are the furthest down the road of working with us. The other question was how widely deployed is this? We now have, and that we as PGP Corporation has about 100 companies that are running PGP Universal today. The principles that we're doing, you'll also see starting to show up in more and more client software. We are talking to the guys because these are ways to make everybody make things more accessible. So the we is primarily me because I'm trying to get people to use this stuff and then there's the I would like people to play this game with me so anybody who comes along. Question here. The question was what happens if you get a subpoena and somebody does this? There are two answers to that. One is that you have a lawyer who will say what keys do you want and the other one is this is the reason why you still want to have client managed keys. Server managed keys are not for everyone. They are a medium level security option. And over here, could you repeat that? What are the implications of proxy based for what? The question was what are the implications of proxy based systems for males generated by worms? Well, you can actually do a lot better with that because you can have in the proxy, scanners that work on things as well. We have as part of the newest version of PGP universal integration with a server based virus scanner. So we will scan the message before it goes out for viruses and if it's virus based we can bounce it before we encrypt it. So that is one of the implications. The proxies actually make it easier for people to do total security on things. The problem is that there is more than just the confidentiality of the information that is part of the email security issue and you want to have these trade offs that you can make. So you want to have scanning that goes on the client because if you want to have your security be as close out end to end as possible you have to scan early and scan late. But if you are in a situation where you are willing to take the confidentiality risk to put the security encryption points at the servers, you can do content, virus, etc. scanning there as well. You have one in them so go ahead. He asked whether or not there are open source solutions that do what we're talking about. There are starting to be them. I'm now starting to talk with the crypto mail guys to have us interoperate with them. Open source systems like Anubis will also work with this provided that you load the key database in the right place. They aren't doing the same sorts of LDAP queries that we're doing on that. But there's no reason why you can't. I'll tell you what the schema is. Any more? I've got five minutes on the end then. The question was how do you deal with certificate databases and directories and stopping email harvesting? And the answer is you don't. This is a problem that if your name and phone number is in the phone directory people can call you and look you up. If you don't want to have that you need to have some sort of constraints on it. But there are other ways that people can do harvesting. SMTP can do harvesting. You simply send the messages. And if I go look at your own mail server logs I look at mine and there are all sorts of people who just hammer on hypothetical names. There was a question back here as well? Yes. The question was that if you're having proxy servers that you don't have the same sort of end to end that you have it when you're going from user to end user. What's the advantage of that over TLS? TLS is not only network encryption only but it is also only point to point. So because email is a store in forward protocol you have no idea of knowing where it's going to go. Many email infrastructures include agreements with people and we've done them as well where you have a friend who's working a company and they are your lowest priority backup MX. And in these particular cases you'll end up with the plain text of your message at the very best sent with SSL to this other thing that is under the control of somebody who's not your recipient or anyone else. So the advantage of the proxy servers that you have content encryption until you get to that. Now a proxy server that is doing pop and imap encryption has ciphertext on the server. It gets decrypted right before it gets sent over SSL to the user. So the most open link is the SSL between you and the proxy. And you can do any one of these that you want. So you can have ciphertext on the server, you can have ciphertext all the way to the end or you can have it within the gateway essentially. Anybody else? Okay, I think that's it then. Thank you very much.