Transparent Email (WAS disable telnet to port 25)
-----BEGIN PGP SIGNED MESSAGE-----
I don't have an answer to your question, but you did bring up something I've been meaning to ask about for some time and I never really got around to it; Are there any short-term plans to press for an RFC utilizing digital signatures? With the exponential increase of mail users, as well and the influx of Compu$erv, AOL, Prodigy and other users, some methods for the transparent use of digital signatures needs to be worked out before it becomes too difficult to implement change because the commercial services have all the power. (or worse, before the government decides for us.)
Some still unformed thoughts on this subject: The big problem with transparent encryption and signatures is key distribution: if you've never sent a letter to me, your mailer will have to get my key (invisibly) before the mail can be sent. The big problem with key distribution is the web of trust: who gets to decide which keys are good? This is a subtle advantage that systems with centralized key generation have over systems like PGP, which let users generate their own keys. If big brother mints all the keys, then big brother can set up an authoritative keyserver. The best answer that I can come up with for this problem is to allow for several webs of trust to function simultaneously. Perhaps we would have a default web, which would have everyone's key in it. The idea behind the default web is that it should be able to return a key as often as possible, so we don't want to make it too difficult to submit keys for this web. But anyone else could devise his or her own web, and administer it however he or she pleased. A request to a keyserver would include a list of webs, in order of preference, that the user would be willing to deal with. At the end of the list would be the default web, in case nothing better was available. A web could be defined by a single top-level public key and a set of rules. Perhaps a text based program -- a sort of "meta-pgp" -- could check chains of signatures to validate a key. Suppose, for example, that I'm administering a web of trust. I set up the web so that I can deputize notaries who can in turn sign user keys. Lets further assume that all signatures are good for a year. A keyserver would return a text file containing: (a) the user's key, concated with a header specifiying the date it was signed by the notary, and (b) the notary's key, concated with a header specifiying the date it was singed by me. We'd want "meta-pgp" to be able to handle complex rules which would give it the flexibility to implement a wide variety of webs. Perhaps it could use prolog-ish style induction to determine if a key was good. Does this make sense? Is it something that was already proposed and discarded? == Alex Strasheim | finger astrashe@nyx.cs.du.edu alex@omaha.com | for my PGP 2.6.1. public key -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLtmV+hEpP7+baaPtAQH3kgP8DmycpNrZKQRpyK1rclxJnIY2bdT5m4iM p7IQ7nI07PSMn+ldye2xG5jjms42CR0BVvk4hhdGzDJwcgdd3FHFC7xNHvhk+SOE 4EHqpyW+YdNSe3A7+sMZp30mgWEnvHOpnrU9UiMUIaC8gcLk3GlkXdxDG+SWGwv/ 1yesnbaUxYM= =p2UQ -----END PGP SIGNATURE-----
The big problem with key distribution is the web of trust: who gets to decide which keys are good? This whole area of key distribution has generated much confusion. A perfect world is described, and then everyone is assumed to participate in achieving this world. This approach of generality, however, is notably more complicated than a world where responsibility for security is partitioned, where each user does not have to worry about all the possible systemic security issues. Proposition: You don't need to be responsible for making sure that the other person is being spoofed; that's their responsibility. A common situation where this proposition makes a significantly simpler system is exactly in the case described, where you and your email correspondents wish to exchange keys. Suppose, in addition, that you two met online and that your only channels of communication are electronic. The goal here is to create persistence of identity; identification with a physical body is not needed. In the PGP case you start with your own key, which you trust, then look for a chain of signatures to the destination. This chain can be rather cumbersome to produce. It's overkill, as well, since all you really needed to know is that the key was not being translated on your own end. The PGP trust chain largely accomplishes that, true, but not as simply as possible. Alternatively, you save the first piece of email that you receive from your correspondent; it has a digital signature on it. Now _by whatever means_, you obtain a public key by which to verify that signatures on email you receive are the same. You yourself need to ensure that you aren't getting spoofed; you can do this by, say, having your correspondent send mail to two different locations, or by using a second channel to obtain the key by, or by using a PGP trust chain, if one is available. The original model for public key communications seems to have been one channel with an interposer. The real world is much more complicated than that. One can obtain good protection, at least as good as a trust chain, by crossing organizational boundaries. The argument that trust chains are better because they are cryptographic carries no weight; the decision at each link to make a signature is of social, not cryptographic, character. In particular, the design of PGP that ties key management inextricably to encryption is bad and will contribute to an inflexibility that will eventually sink PGP if it is not corrected. Perhaps we would have a default web, which would have everyone's key in it. This is a really bad idea. Some "public" keys should not be made public, but rather revealed only to the correspondent. Forward secrecy is the reason. If the public key has never been in the possession of an opponent, and assuming the results of the public key operation yield little or no information about the modulus, then when the keys are changed and destroyed, no amount of factoring can find the private key because the public key isn't around to factor. Eric
participants (2)
-
Alex Strasheim -
eric＠remailer.net