October 1992 - cypherpunks-legacy

Some (Pseudo)Random Thoughts
by tcmay＠netcom.com 14 Oct '92

14 Oct '92

Some thoughts on the recent meetings and what we're doing: 1. The importance of trading physical goods in the Crypto Anarchy Game. This, in my view, has been given undue and misleading importance. Physical goods are inherently easy to trace through remailers (via sniffers, radioactive tracers, weight of packages, and many other physical cues), are hard to store physically (imagine getting 100 parcels for later remailing), and, most importantly, have none of the "envelope within envelope within...." protection accorded to the bits of a cryptographic remailing, or DC-Net, system! The elegance of cryptographic protocols is lost with physical goods. Furthermore, physical delivery of any good, whether drugs, stolen missile components, antiquities and art items, whatever, is fundamentally a hard problem to solve...smugglers and thieves have been dealing this since the beginning of time. Stings can be easily arranged, delivery is not anonymous (one merely watches who takes delivery, or who opens a train station locker, etc....this is all SOP for narcs and counterespionage types), and a raid on a remailing entity will result in confiscation of the physical goods and (likely) prosecution of those caught holding the stuff. (Raiding a bit remailing entity produces only random-appearing bits...granted, the authorities may well outlaw bit remailing, or use the RICO and conspiracy/sedition laws to prosecute, but that's another topic.) Our recent emphasis on physical goods, and all the ideas pouring in on what other kinds of "contraband" besides drugs can be used, is misleading. None of the richness of the cryptographic world is faithfully preserved. I urge we get back to our roots and deal only with things that can be expressed purely in bit form. 2. The "colonization of cyberspace" does not mean there is no interaction with the physical world, of course. But that interaction can be mediated with money made by converting information or digital money into physical money. Several methods for this conversion path can be considered: -Alice sells information in the cyberspace domain for the equivalent of, say, $30,000. She converts this to "real" dollars by using an escrow entity which hold both sides of the transaction until it's completed. They then mail the information to the purchaser and send an ordinary check "for services rendered" to Alice for $30K. She reports it on her taxes, probably as a "consulting fee" (for which essentially no government supervision currently exists, nor is likely to....), and the conversion has taken place. (Note: there are still elements of trust involved, notably involving the escrow agent, but trust works pretty well for many things, especially when reputations are at stake. Understanding how real businesses depend on reputations is a missing part of modern cryptology analyses of transactions...the protocol analyzers and number theorists almost never take into account how reputations work in the real world, But I digress.) -Alice and Bob trade information such that Bob gets the information worth about $30K, as above, and Alice gets another piece of information she can use in the "real world" that is worth about $30K. This might be stock tips, or, better, information she can turn around and sell in the "open market" of a service like AMIX! There are lots of wrinkles, inefficiencies, etc., to be worked out. -And then there is digital money. You all know about this, or should. David Chaum, DigiCash, blinded notes, credentials, etc. The handout for the first meeting had a glossary of terms. (IMHO, we should be spending more of our time at our meeting discussing this, and less in playing more interations of the Game.) The fascinating novel "Snow Crash," by Neil Stephenson, makes a mistake in having Hiro Protagonist a very wealthy man in the Metaverse (Stephenson's term for the virtual reality cyberspace) but a very poor man in the Real World. Information _is_ money. Information is liquid, flows across borders, and is generally convertible into real money. (One simple conversion strategy, alluded to above, is for Alice to sell her information for, say, $500K, and then to receive a "consulting contract," perhaps called a "retainer," of $50K a year for the next 20 years. Her retainer is fully legal, is perhaps handled through cut-outs who specialize in this kind of thing, and is a low-risk way to "launder" money from cyberspace into the real world. I have a lot more to say on these schemes, perhaps later.) 3. Are we emphasizing "The Game" too much? If the goal is to produce a paper-based game, similar to "Monopoly" or fantasy role-playing games, then I suppose more practice is needed. But I'm not sure how worthwhile it is to try to design such a game. (Those who wish to should do so, then commercialize it, and become the Avalon Hill of crypto games!) If the goal is educational, for newly interested folks, then I also question how much more effort should be put into it. The ideas of anonymous remailers, of digital money, etc., are, I think, gotten across in the first 60 minutes of the game, especially if some of the formalism is first explained (as it was at the first game, where digital mixes, tamper-resistand modules for implementing mixes, the "Dining Cryptographers Protocol," and digital money had all been freshly covered, so participants were putting the theory to test). I found the first game was instructive, the second much less so (and _not_ because of the focus on drug selling...that was a relatively minor issue). My impression is that many of the newcomers--and they should jump in here with their own reactions (too bad we don't have hypertext links!)--didn't really know how remailing mixes work, how digital psueodnyms can protect privacy in transactions, and how the "Game" was intended to exercise these concepts. 4. We need to talk about the charter or purpose of the "Cypherpunks" or "Cryptology Amateurs for Social Irresponsibility" (CASI--Eric Hughes's term) group. -Is it mostly educational? -Is it a lobbying group, as are EFF, CPSR, and the like? -Is it to produce remailers, digital money, and other programming? -Is it subversive? Now clearly we can't say it's subversive (any bets on who's gatewaying these messages to Other Listeners?). But we also don't want to skew things toward "YALG" (Yet Another Lobbying Group), nor do we want to be a spoon-feeding educational group for people with a casual (and transient) interest in crypto stuff. 5. There have have been several messages so far about worries about the legal implications of these topics, about how some corporate-affiliated subscribers will desubscribe "real fast" if certain discussion trends continue, and so on. Now we can't please everybody, but maybe we ought to talk about this sensitive issue soon, and _in person_. Since it relates to our charter, Point 4 above, I recommend we do this at our next meeting. I'd favor that over another iteration of the Game. In conclusion, we are in at the beginning of Something Big. While I'm somewhat skeptical about the claims for things like nanotech, I see this whole cyberspace/cryptology/digital money/transnationalism ball of wax being _much_ easier to implement. Networks are multiplying beyond any hope of government control, bandwidths are skyrocketing, CPUs are putting awesome power on our desktops, PGP is generating incredible interest, and social trends are making the time right for crypto anarchy. I look forward to hearing your views. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP 2.0 and MailSafe keys by arrangement.

1 0

game items
by Judith Milhon 14 Oct '92

14 Oct '92

You needn't timetravel to come up with instances of underground heroism. There is RIGHT NOW an underground dealing with AIDS meds. And there may be, soon, an RU-486 network. <Bruce Sterling is publishing a very funny story about this called Are You For 86?> These are worlds away from traffic in sleazy recreationals for profit. <Sounds even PC, ne? Of course, illegal and sleazy shd be clearly distinguished. How about LEATHER GOODS? Heh: nasty costumery, best advanced designs. Slings if not arrows of outrageousness. Branks, quirts. Hee.> <Keep in mind that this is meant to be an involving GAME. Games should be FUN. More whimsy, yes?> >jude<

1 0

Game items...
by Hal 14 Oct '92

14 Oct '92

I'm trying to think in terms of things which were illegal but which have good moral connotations today. Crosses and other Christian symbols were supposedly outlawed during the Roman empire (leading to the adoption of the fish as a symbol of Christianity). Posing as early Christians smuggling crosses ought to make the right-wingers happy! Abolitionists had to smuggle runaway slaves out of the South on the so-called "underground railroad". Perhaps cryptography would have helped them coordinate their efforts. Much of the support in the U.S. for freedom and privacy comes from our revolutionary heritage. I'm embarrassed at how little I can recall of what things were restricted in those pre-revolutionary days. I recall the Stamp Act and a few other laws, and I imagine that seditious materials were restricted. Perhaps the game players could be early revolutionaries trading items forbidden under British rule. Hal Finney - 74076.1041(a)Compuserve.Com -----BEGIN PGP PUBLIC KEY BLOCK----- mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK-----

1 0

Game items
by wixer!pacoid＠cs.utexas.edu 14 Oct '92

14 Oct '92

Just about any device for refining psychoactives... Alcohol stills, for one. We run one at home in TX, legal now, but which would have been jailbait in my grandmere's time. In certain parts of TX, wirecutters used to be illegal on strangers. They implied cattle rustling, etc. Phone recording equipment is legal now in many areas - formerly forbidden by wiretap laws, but now available through catalogs like Damark, etc. It would be so easy to find counter examples - non-weapon, physical items formerly legal, now illegal or heavily watched/licensed... precision scales, lab glassware, Kevlar, radio transmitters... pacoid.

1 0

re: Matching Text, Headders and Signatures with Crypto Hashes
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 14 Oct '92

14 Oct '92

U> From: hugh(a)domingo.teracons.com (Hugh Daniel) U> For example in NetNews I proposed changing the U> MessageId: headder such that part of the gobldyguk on the U> left side of the atsign was a crypto hash of the body of U> the message and some of the important sending host U> generated headders. With this system of MessageId:'s U> anyone who corrupts a message (intentionaly or otherwise) U> creates a bogus message, as the next machine that gets the U> message can see that the message does not match it U> MessageId: line. There's a FidoNet mailer (Dutchie) that uses MD4 to generate message IDs in exactly this way... They did some cheat, to allow certain filters (CR/LF vs LF, etc) to work. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings(a)f111.n125.z1.FIDONET.ORG

1 0

Integrated privacy...
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 14 Oct '92

14 Oct '92

U> Absolutely. The most crying need now, IMO, is to better U> integrate the cryptographic tools into mail readers and U> senders, so that it's not such a pain to use these things. U> People should be able to give a single command or press a U> button to decrypt an incoming message or encrypt an U> outgoing one. I just completed (well, it's in "beta") a mail-reader package for MSDOS and FidoNet. It does "rm" type stuff, and has PGP integrated reawonably well. Single character commands to decrypt, encrypt, sign, or encrypt/sign. It furnishes the distributed PGP.EXE program with it's imput (deriving it from the message itself). It'll extract keys from messages, and all that. It's MSDOS and .MSG-type FidoNet message base oriented, but it does all it's work in pure ASCII (FidoNet .MSG files are mixed binary and text). It is intentionally "RFC-822 like", and will become fully RFC-822 "soon". I was reasonably careful regarding de-cyphered plaintext laying about on disk, etc. It's available via Wazoo filerequest as magicname RM. (That's probably as obscure to you as FTP is to FidoNet.) It will be released as "copyleft" with all sources. Binaries only this week til I get it shaken down. * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings(a)f111.n125.z1.FIDONET.ORG

1 0

PGP implementation for FidoNet
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 14 Oct '92

14 Oct '92

There's a conference in FidoNet called PUBLIC_KEYS, devoted to PGP and surrounding issues. Most evreyone is enthusiastic but without security experience. As always, we find that the prevailing "right ways to do things" don't fit. FidoNet's main need is "privacy", not "Security". What would be considered very low "security" in traditional circles would be more than adequate. (And of course the usual ways work just fine with a for "real" security needs.) Follows is an article I ran in FidoNews, the weekly FidoNet newsletter. I hoep it makes sense. The FidoNet environment is a little different than other nets. * Security and authentication using PGP in FidoNet THOUGHTS ON SECURITY AND AUTHENTICATION FOR EMAIL SYSTEMS Tom Jennings (1:125/111) Some ideas on public key security systems. To sum up ahead of time, I assert that the public broadcasting of public keys is more than enough security and authentication for casual, privacy needs in the FidoNet or other email network. All of this article assumes the use of PGP version 2.0, the RSA double-key encryption system implemented as freeware. This is all new to most of us, this security/privacy thing. Both technologically and socially. What privacy we have we take for granted without much thought; letters in envelopes, "who is it?" to knocks on the door, etc. When we try to break down these things into their underlying assumptions, well, it's hard. We shouldn't get upset with ourselves or others if "we don't get it" right away. And we'll find some obvious things aren't, and vice versa. I will assume that if you really, really need utter absolute security, you can achieve that with PGP or whatever. If it's that sensitive, sending it over an electronic medium probably isn't recommended. This article isn't about how to achieve bank-vault security. Within the FidoNet, the most common use we all seem to talk about is PRIVACY, rather than SECURITY. I can only speak for myself, but, my netmail (not echomail) traffic is probably a reasonable example. I read about 100 messages a week, and send out about 50. There's a dozen or so people I talk with regularly, and about 50 per week that I do not know. Most of it is of the "Oh yeah, so and so said this. How's your mother. Did you get that file OK...". Even if an eavesdropper read this stuff, I would barely care. There are some times though when revealed message contents could be... personally compromising. Embarrassing. A real life example: a long time ago, a sysop in a net was having trouble with their net host. Some messages critical of that net host were intercepted by the host, some passed on, and some we each got replies to! Not Good. What *I* want is a way to ensure that sometimes, only the addressee can read a given message. I am willing to pay some penalty for this, but I won't live with a system that restrains me like a stone castle and moat. My needs and risks just aren't that great. With that as a background assumption, let's look at two separate issues that look at first to be the same -- SECURITY and AUTHENTICATION. SECURITY -- given an encrypted message, how likely is it that someone can ascertain what's inside it (assuming you're not the addressor or addressee)? As an operating assumption, I will take it for granted that PGP produces files that are secure in themselves (barring bugs, etc). Like the docs say, a frontal cryptological assault is hard, and in our casual privacy case, probably not what we've got to worry about. There are other ways to figure out what's going on. Imagine you're that net host. You've had trouble with this particular sysop before. You notice he's just sent a flurry of messages to the local RC, then the ZC. Hmmm!! Do you really need to know what's in those messages?! (This is called traffic analysis. In pre-WWII Germany, the Nazis tracked down "Jew sympathizers" with traffic analysis of telephone billing information; Europeans don't get itemized phone bills any longer... like here in the US. So I was told, the information is no longer kept. (Do I really believe that...:-)) Anyways, security is more than cryptographic strength. Turns out, there's a way around this: anonymous remailers. In a private Internet mailing list Eric Hughes came up with a trick to anonymously remail messages; you send mail destined for system X to the remailer instead; it strips off the header info and mails it to system X. Anonymity isn't really needed though in the case above, simple remailing will do. Again, our *general* FidoNet needs are modest. AUTHENTICATION is the sticky one for us. Authentication is determining: is this person really the person they say they are? But I think you'll see it isn't the fatal problem it appears to be at first. Let's get the obvious case out of the way first again: if you need utter and absolute security, you better damn well know the person ahead of time, you should get a key delivered by hand, and you should think about if you really want to conduct business over an electronic link in the first place. Authentication in this case isn't -- or shouldn't be! -- a problem. For our relatively-casual privacy use, authentication is almost moot. Some people I have already exchanged keys with, *I've never met face to face in my life* and may never. In spite of this I feel I know them. I trust or assume that they are who they say they are. This is the environment we need to work in. This, plus the fact that we've got (at the moment) some 16,000 potential keys, means we simply can't do the full-blast security thing. How much "security" can I expect, or need, with someone I've never met? Consider again the utter-security case again. But the bottom line is in fact already taken care of, PGP or not -- how do you know that "the real Tom Jennings" wrote this article? Our underlying social system, so frequently overlooked, takes care of it. You can assume I, and many people who have been in the net, are verifiable. You have a number of ways to determine if I really wrote this article. Simply asking via FidoNet will uncover most fakes. Looking at old nodelists to see what info on my name has changed. Ask people who might know me. And so on. If our public keys are scattered to the wind like plants scatter pollen, it is certainly possible that I could fake "your" public key, and gain access through all the methods discussed in detail in the literature. However, assuming the real person and the fake person(s) are both generating keys (and using them to sign and send messages), the more keyrings were passed around the chances of detecting the incompatible keys becomes almost certain. At that point, even a casual effort would be able to track it down, to at least determine that there *was* a fake. Example: Mary has been using PGP for a few months, and conversing with friends and acquaintances. Her public key is filerequestable, and probably appears on a hundred keyrings. Over the next few months, other people get messages from "Mary" making increasingly odd claims, via encrypted mail. The impostors fake key, in order to be useful at all, would also have to be widely distributed. Curious, someone sends Mary a message encrypted with what appears to be her public key, and a plaintext one telling her that the cyphertext was encrypted with her public key, and that he suggests if she can't decipher it someone may have faked her key. What Mary actually does depends on many things. If she has indeed been creating the crazy messages, well, the problem's elsewhere. If she finds she can't read the message, her recourse depends on what is available to her: if there are public key repositories, she would be advised to contact them and notify them of the alleged faked key(s), and follow whatever process is setup to generate a new key. The very knowledge of key collision would be enough to flag to users that there's a potential problem. There are more practical issues that limit our need for traditional security measures on keys. Even if you stored your private key on disk, it would take physical access of your machine to get it. This is not what I'm worried about in private FidoNet mail. If a FidoNet member tries to break into my house or system to get at my key, I've got other troubles! Practically speaking, it might even be a good idea to have two keys; a small (256 bit) one for casual, email privacy, and a big one (1024 bits) that you give to people by hand on diskette. The small key will mean better performance, more important on bulk casual email, and certainly adequate against eavesdropping. For high-security needs, which most people don't have (I certainly don't), the performance penalty probably won't matter as much. The worst part of security systems is that people will *rely* on them as absolutes. This is the only thing that makes a faked, encrypted message worse than a faked, plaintext message. Again, it's important to remember the goal (as if we could ever possibly agree to a *single* goal...) -- if it's privacy, the ability to stop eavesdroppers, then a broadcast public key system is more than adequate, and public key repositories even better. If you want a maximum-security vault, you take added precautions. No one system will solve all problems. I'm a firm believer in a broadcast public key system for email. PRACTICAL SUGGESTIONS FOR PGP USE IN FIDONET PRIVACY: * Use small (256 bit) keys for routine, low-security use, such as netmail privacy with people you don't know personally (and don't get keys from physically). * Public key encryption is most useful for email, ie. FidoNet netmail, especially when it flows through multiple hosts on its way to its destination. * The current password scheme for echomail links is proven to be adequate to safeguard what is basically a public forum, anyways. Further security doesn't seem to be needed on these links. * When adding keys received via FidoNet to your public keyring, answer "do you want to certify this key yourself" with NO, unless you received the key by hand. It doesn't hurt the usefulness of the key itself; however, if someone later uses your public keyring they won't be lulled into a false security. (Certification of keys can be done at any time.) * Passing keyrings around willy-nilly, though counter to "good security practice" in traditional uses is actually a good thing for us. "Key Repositories" scattered throughout the net (each exchanging keyrings as well as posting lists of "trouble keys") is a better idea. * Reserve large (1024 bit) keys for people who you know, and can ensure security in traditional ways (some pointed out in the PGP documentation). * As seems to be developing, have your public key filerequestable as magicname "PGPKEY" (your own public key only), and your keyring as "KEYRING" (all of your public keys). These should be ASCII-armor files (PGP -kxa) * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings(a)f111.n125.z1.FIDONET.ORG

1 0

Re: Mr. Squirrel
by Hal 14 Oct '92

14 Oct '92

||ugh Daniel raises some questions about using public keys to verify pseudonyms: > Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone > can use any public key they want also. But, once person A creates public key X, nobody else can sign messages using X. So if all messages from A are signed under X, we can know that they are all from the same person, even if they are sent anonymously or under a pseudonym. > So, in a many-to-one scope (as > in a maillist) where the sender can not use the one-on-one signed > signiture method how do we have proff of who the sender really is? You can use signatures even in a many-to-one scope. Messages from a particular person could be signed and the signature appended to the message. Then anyone who has the public key can check to see who the message came from. The process is a little unwieldy now in PGP because you have to separate the signature and message into separate files and run PGP on the signature file. This should be streamlined. > [Good points about keeping track of key-pseudonym pairs] > But all this needs to be done automaticly by the mailers and > interfaces, else the system will be mis-used and folks will tire of > the extra work that gets them little advantage. Absolutely. The most crying need now, IMO, is to better integrate the cryptographic tools into mail readers and senders, so that it's not such a pain to use these things. People should be able to give a single command or press a button to decrypt an incoming message or encrypt an outgoing one. Only then will these features be used by average people. There was a message posted on alt.security.pgp describing how to use PGP with the Emacs mail reading program. I'd like to see more messages telling how to use it with other systems. Hal 74076.1041(a)compuserve.com

5 4

anonymous bank accounts via
by Fen Labalme 13 Oct '92

13 Oct '92

Mail*Link( Remote anonymous bank accounts via pem FYI: [pem-dev is a private email list for developers of the Privacy Enhanced Mail protocol additions to Internet mail, originally published as RFCs 1113 - 1115, and now updated as four draft-ietf-pem documents. To join the list, send email to pem-dev-request(a)tis.com. By the way, most of the discussion is not nearly as germane to our ideas as this particular posting, but this one caught my eye as of some iterest to cypherpunks.] ----------- Forwarded Message ------------ Date: Tue, 13 Oct 92 01:07:39 EDT >From: uunet!ellisun.sw.stratus.com!cme (Carl Ellison) To: pem-dev(a)TIS.COM Subject: Re: [Peter Williams: Perhaps OSI security is not possible in a liberal community!] Sender: uunet!TIS.COM!pem-dev-relay Let me throw in another vote against the *necessity* of hierarchical certification by arguing against the necessity of certification itself. For example, it is possible, given digital signatures, to have totally anonymous bank accounts -- identified only by public key -- with no certification of relationship between that key and any other fact about any individual or corporation. Such accounts are at least as valuable as a Swiss numbered account -- perhaps more so since no one need know the identity of the person or people with the power to withdraw funds. Such funds transfers can be made not only anonymously but untraceably. It might even be possible for them to be made without it being possible to trace the transfer at either end (eg., using digital cash techniques). I don't propose that all bank accounts be anonymous. It's just that I don't like to see us jump into an attempt to relate public keys into the physical world so that our old established notions about relationships and responsibility can carry over into this new domain when by doing that we end up avoiding research into all the possibilities which digital signatures open up. That research needs to be both technical and social -- or we could shy away from it by forcing relationships between keys and those entities to which we are already accustomed. --Carl

1 0

Where to get further information about PEM
by gnu＠cygnus.com 13 Oct '92

13 Oct '92

Get the latest Internet Drafts for PEM; the RFC's are out of date. By ftp to nic.ddn.mil, directory internet-drafts: -rw-r--r-- 1 gvaudre 35978 Sep 4 03:36 draft-ietf-pem-algorithms-01.txt -rw-r--r-- 1 gvaudre 16031 Sep 2 03:36 draft-ietf-pem-forms-01.txt -rw-r--r-- 1 gvaudre 85132 Aug 7 03:30 draft-ietf-pem-keymgmt-01.txt -rw-r--r-- 1 gvaudre 104515 Jul 25 03:30 draft-ietf-pem-msgproc-02.txt -rw-r--r-- 1 gvaudre 128 Sep 2 03:36 draft-ietf-pem-notary-00.txt John PS: I too think that other key certification models besides "hierarchical" are appropriate. I think we can start from PEM software and PEM message formats and evolve and experiment as appropriate. Before you ask, currently there is no PEM software widely available. It's in alpha test. It will be released in full source code, and its development was funded by DARPA.

1 0