December 2003 - cypherpunks-legacy

Re: Revoking Old Lost Keys
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

On Fri, 05 Jan 1996 23:07:19 -0800, Bruce Baugh <bruceab(a)teleport.com> wrote: >I'd like to bring up a problem I haven't seen addressed much yet, and which >I think is going to come up with increasing frequency as PGP use spreads. >The problem is this: how can one spread the word that an old key is no >longer to be used when one no longer has the pass phrase, and cannot >therefore create a revocation certificate? [..] Keys should have built-in expiration dates (adjustable by the user manually the way one would change their user-id, passphrase, etc.) PGP should give a warning when the key passes the expiration date. It should not prevent you from using it, but should remind you that the key is rather old, and that the owner may have moved, etc. Users who want to extend the life of their keys should send special certificates (at least once a year or every other year?) that tell keyservers and those with copies of their public keys that the key is still being used, and to update the expiration time. Comments? --Rob

2 1

info
by j.miranda3＠genie.com 17 Dec '03

17 Dec '03

Anyone have any connections with the alternative/underground rock scene. I have been reality surfing it here in the L.A. area and am looking for people who are interested in coming along to assorted indsutrial/techno/gothic/rave places. Also, are there any cybernetic developments related to this scene I was thinking of something along a program which would be used when employing the mini-monitors (which you wear like sunglasses).

1 0

Re: Internet & Porno on A&E tonite
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 10:54 1/6/96, Jim Choate wrote: >Hi, > >Just saw an add for a Investigative Reports show tonite on A&E dealing with >the Internet and some of the current issues relating to porno and privacy. > > > Jim Choate I just got done watching it. Heavy on the porno and Light on the privacy. It did cover some of our hot buttons but stayed away from talking about their context (ie: They covered the TN prosecution of the CA BBS owner but ignored the question of if it was a prosecution or a persecution [as well as the question of if the charge/trial was legal in the first case]).

1 0

Re: FW: Undeliverable: Re: Massey, CEO of Compuserve, on Internet
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 11:25 1/6/96, blanc wrote: >From: Steve14571(a)aol.com > >Something else I want to know... Why is my mail going through microsoft.com? >........................................................................... >............................ > >There is an email 'alias' at Microsoft which was subscribed to the cpunk >list, to receive and distribute the cpunk list to members of that alias. > >A new beta version of Exchange is being used on a test basis by some >departments (apparently all of the cpunks at MS are using it), and the >programmers recently encountered a "little complication" (to use a phrase >from the movie 'Brazil'). I'm told that the problems were corrected, but >that now the spoolers are releasing messages which were backed up while >mail delivery was put on hold. I hate to agree with Timothy C. May, but >it is probably best to "use technology " to deal with it for a day or so. > > .. >Blanc I had a bounce from another list (<corp-welfare(a)ursus.jun.alaska.edu>) so it is not only cypherpunks which is having the problem.

1 0

Re: "Microsoft.com" added to my KILL file
by Lee Fisher 17 Dec '03

17 Dec '03

| After getting another batch of bounce messages from Microsoft's Postmaster, | I have reluctantly decided to filter out all messages from Microsoft.com | until they fix this problem with Microsoft Exchange. I'm not in the Exchange group, not the internal operations group responsible for this last error, but I'll try to clarify the two issues raised by this thread. (But perhaps this message was pointless, as the folks I'm attempting to explain to have already this filtered out by their KILL file?) MSMail and Exchange started before MIME started. They wanted to have "richer" email (as with MIME), and started some efforts, which put data in a uuencoded WINMAIL.DAT file. Exchange switched from TNEF (Transport Neutral something or another) to MIME. Originally the default was to send "rich" email but after beta feedback came in, it was changed to NOT be the default. So, these winmail.dat and MIME (and some TNEF) data included in some messages are from MSMail and Exchange clients. And while I expect that there are some things that our MS Mail and Exchange groups could have done better to introduce support for more than just ASCII messages, there is also some user education needed (that some forums -- such as mailing lists and newsgroups) often aren't the right place to post non-ASCII text like MIME attachments and older winmail.dat files. Another issue (the one mentioned in the above message). Last week the mail server operations group on Microsoft campus experienced a few "growing pains" switching over to later builds of Exchange server, switching over from MS Mail. Apparently there were some brief problems, causing some bounce messages, which would have manifested from a few users @microsoft.com. I don't know if it due to humans (operations group error) or computers (Exchange server bug) that caused it. The flurry of bounces was [hopefully] a one-time problem. Lee Fisher, leefi(a)microsoft.com

1 0

Re: Revoking Old Lost Keys
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

shamrock(a)netcom.com (Lucky Green) writes: >I would very much like to see expiration dates on public keys. Is PGP 3.0 >offering this feature? I would very uch like to see PGP 3.0, but that's another story... --Rob

1 0

RE: "trust management" vs. "certified identity"
by Frank O'Dwyer 17 Dec '03

17 Dec '03

On Sunday, January 07, 1996 12:22, Futplex[SMTP:futplex@pseudonym.com] wrote:>Frank O'Dwyer writes: >[I've adjusted the line breaks for those of us with 80-column displays] Apologies - this mailer doesn't give me any indication where the margin is. [...] >>a signator's job in signing for my identity is >> easier (and less risky) than signing for my trustworthiness. >I am doubtful. I can't vouch for the identities of very many people on this >list. (I've even met, e.g., Lucky in person and I certainly have no clue >what his verinym might be, nor do I particularly care.) On the other hand, I >am willing to sign onto all sorts of judgements about the trustworthiness of >various people on the list, and other aspects of their reputations. I've >driven hundreds of miles based on trust developed online with people whose >identities I still haven't verified. I've even agreed to loan hundreds of >dollars to someone I knew only as an online pseudonym. I'm not saying that trust requires identity (it obviously doesn't, since we all make trusted cash transactions all the time without having to produce any id.). But it is usually easier to determine (and vouch for) who a stranger is than how trustworthy they are, if only because there are quick and easy real-world mechanisms for this (driver's licence, passport,etc.). That's all I meant. (BTW, can you lend me a few bucks? :-) [...] >I am swayed by the view expounded by Carl Ellison that a key, not an >identity, should be the anchor to which attributes are attached. (Sorry if >I am misstating or oversimplifying the position here.) I think identity >should be hung off the key as just another (optional) attribute. That's an extremely useful way of looking at it, I agree. But the lifetime of a key is often less than that of some attribute. It's easy to imagine one email address having a succession of keys. But then again, one might acquire and discard email address more often than keys (I've gone through three addresses in the last year or so). So perhaps a better model is just a loose assocation of attributes, with "key(s)" and "identity(s)" being two very interesting ones, but no one attribute being primary all the time. (I'm thinking out loud here -- I'm actually trying to come up with some C++ classes for this sort of stuff, so this discussion is pretty interesting to me. Thus far, I'd got to the model you describe - a key has a bunch of attributes, one them identity. But now I'm thinking that this maybe isn't enough, and an 'identity-centric' view is also needed. Perhaps there should be multiple views into the same data?). >I think your comments apply pretty well to trust relationships in the flesh, >but don't fully take the net into account. Right. I was only talking about 'verinyms', really. Cheers,Frank O'Dwyer fod(a)brd.ie http://www.iol.ie/~fod

1 0

Key Expirations (was: Revoking Old Lost Keys)
by Don M. Kitchen 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- >From: shamrock(a)netcom.com (Lucky Green) >At 15:45 1/6/96, Bill Frantz wrote: >>Perhaps if keys could be made with expiration dates (certificates too), >>this problem might be reduced to managable proportions. > >I would very much like to see expiration dates on public keys. Is PGP 3.0 >offering this feature? (it would be nice to know of anything that PGP 3 will be offering) >From: wlkngowl(a)unix.asb.com (Mutatis Mutantdis) > >Keys should have built-in expiration dates (adjustable by the user >manually the way one would change their user-id, passphrase, etc.) I disagree, I think a key should be be given a specific lifetime. A master key, for example, might be given a life of 7-10 years, while a common-use key a life of, for example, 2-5 years. >PGP should give a warning when the key passes the expiration date. It >should not prevent you from using it, but should remind you that the >key is rather old, and that the owner may have moved, etc. I disagree. I think that it's the key owners' responsibility to provide transitions to a new key. (it would be nice to have a mechanism to auto transfer signatures to a new key, but I can't see that being both safe and practical) I also would also like to see PGP/keyservers with more of a current-status paradigm, rather than a from-the-beginning-of-time model. A "my master key is foo" and "I'm master of: fiz, bar, baz" fields would encourage the emergant practice of having a secure master key, and a common key that is replaced more often. Not-Secure Systems are Not-Secure Systems, and there should be Not-Secure keys to be used on these ISP/multiuser/whatever systems, without resorting to multiple keys, mutually signed, that merely proclaim their properties in the key ID. I'm certainly not calling for Someone[tm] to code it up, only pleading that the paradigms be established conceptually, so that everyone knows (and hopefully agrees) where it's going. We have security (stealth pgp, if generally indistinguishable from random data, will ensure that, and prevent all but human betrayal or tremendously draconian outlawing of random data from taking that security from us) but we do not have seamlessness, and we do not have a PGP that fits how PGP is being used, and not knowing if these things have even been planned is distressing. >Users who want to extend the life of their keys should send special >certificates (at least once a year or every other year?) that tell >keyservers and those with copies of their public keys that the key is >still being used, and to update the expiration time. I can only this working elegantly if the expiration date, as a signed block, could be expunged and a new expiration date block put in. Signatures, of course, would have to authenticate the parts that don't change. If the expiration date is inside the _owner's_ authentication block, everything would still be attack-resistant. (Everything absolutely should be designed to resist spoofing, etc. I would like to see PGP _IGNORE_ key ID's that are not signed, and naturally default to signing key-IDs when being added.) I too would like would like to see expiration dates built into the keys. The PGP key has too much of a static-model, long life paradigm. IMHO, I see two problems. First, key signature are for the key/ID string pair. Every time someone changes email addresses, a clunky ID string addition is made to the key, and subsequent signatures are made to _that_ pair. I don't disagree that it should be this way, only suggest that a more integrated, conceptual view even, should be presented. While I'm presenting my wish list, it would also be nice for PGP to be able to extract keys that are in the Web Of Trust[tm] relative to an arbitrary key. I attempted to do something like this with by Web Of Nobody's keyring for those of you who didn't see my posts, that's what I called what I generated because the brute-force way I extracted it necessitated the signatures going the opposite direction than they should have, resulting in a great many nobody's and missing a few somebody's.) which reduced the then-5 meg keyring to 1 meg. (I am considering doing it again, since I still don't know enough PERL to generate a web of trust instead of a web of nobodies) A feature like this would, in my opinion, largely negate (or at least greatly delay) the need for a DNS-style key lookup. And, after all, what's the purpose in having a list of all keys in the world, why not just have a list of keys that are actually interrelated, extracted from the former. Perhaps even a batch-mode "copy all new and trusted keys from keyring X", THAT would help tremendously with a "locally-trusted" / "globally known" dual-use of PGP and its keys. >From: "Frank O'Dwyer" <fod(a)brd.ie> >portion of the) web of trust was very large, you might find that the old key >kept popping up and you kept getting mail ... >It's just that PGP's certificates are particularly long-lived, and PGP's >revocation is particularly broken. Luckily the data formats do allow for a >validity time, and a revocation of a key's countersignature, so this can >perhaps be fixed sometime. ... >uploading their key with additional signatures. A practical solution >might be for the key servers to automatically remove keys older than X >years (or some time limit related to the key size). Ultimately though, what >is needed is a new revocation model (maybe implementing the unused fields >in the PGP certs is good enough to begin with). This is all a me-too. As I said, I would like to see a current, how-it-is-now list, rather than having keys whose replacement's replacements' replacements have been revolked long ago. >On Sat, 6 Jan 1996 09:47:16 -0000, "Frank O'Dwyer" <fod(a)brd.ie> wrote: > >The PGP formats do allow for a 'revocation' certificate, but PGP doesn't >implement it (yet, I guess). In any case, it's not really strong enough, >since what it says is "I retract all my previous statements that this key is >related to this user". This'd mean that you'd have to visit everyone who'd >ever signed your key and get them to issue this retraction. What would be >needed for this problem is either an "anti-certificate" ("This key does not >belong to this user"), or else some convention. For example, if two _trusted_ >keys are found for the same uid, the most recent one could be chosen, and >the earlier one be purged from keyservers, etc. This may be possible with >current PGP. I haven't tried it, but since I have some keys which have >fallen into disuse, I will need to do so sometime.). I think this is a feature that would be good to have, not necessary for all signatory parties to retract sigs, but certainly for one or more of them to do so. I do think, however, that both should be kept (and not just one cancel another like a current-status model would) and that perhaps the two should default to not being displayed, but certainly PGP explain it as "X revokes signature, contact both parties for explanation" type of thing; let the human be the judge. Don PS: This message may be double-signed, don't think it unusual if it is. - - --- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://students.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Junk mail to root(a)127.0.0.1 * This user insured by the Smith, Wesson, & Zimmermann insurance company * - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMO/FtsLa+QKZS485AQGcSwL/eyUiZ4YgKfLyQx94K+Vm/y2Jmsx1DnOm Anvv2EA98qY1wBxpg2HUCrV2NO97vafTPNJ5dcZsLUIDOnzjw3Pxj7ikNTnwL45Q 89NVqc6jHG3NCbIirDTPSN/q20N2yhEA =qRq9 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMO/FzcLa+QKZS485AQG8OQMAj9mDA9v7f68cKDl4z8JLieFsFo4EtzJb XDna9JXvYQj/tBd+AFuBNxhawzIgSn7ydIw/QtRcE/a9HbAY4eJDfuEANfoKZARb TpxLWpmGU1uDidEB9irGxGGZd4uen7Mz =Ku7l -----END PGP SIGNATURE-----

1 0

Re: CelBomb
by John Young 17 Dec '03

17 Dec '03

The New York Post, Jan 6, 1996. By Uri Dan from Jerusalem Palestinian police said Ayash [The Engineer] was killed north of Gaza City when he answered a call on a cell phone rigged with two ounces of explosives. Israeli sources said the phone had been secretly traded for Ayash's real phone -- and the explosion was triggered by remote control once it was determined he was on the line. ---------- No brand name given, however, another source writes that Mot runs the IL cel net. So use that neat audio-vox wire on MicroTAC Elites only with paid-up Shin Bet dues, absent TS-immunization.

2 1

Re: Revoking Old Lost Keys
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

On Sat, 6 Jan 1996 09:47:16 -0000, "Frank O'Dwyer" <fod(a)brd.ie> wrote: [..] >The PGP formats do allow for a 'revocation' certificate, but PGP doesn't >implement it (yet, I guess). In any case, it's not really strong enough, >since what it says is "I retract all my previous statements that this key is >related to this user". This'd mean that you'd have to visit everyone who'd ever >signed your key and get them to issue this retraction. What would be needed >for this problem is either an "anti-certificate" ("This key does not belong to this >user"), or else some convention. For example, if two _trusted_ keys are found for the >same uid, the most recent one could be chosen, and the earlier one be purged >from keyservers, etc. This may be possible with current PGP. I haven't tried it, >but since I have some keys which have fallen into disuse, I will need to do so >sometime.). Revocation of signatures is a good thing, but beware of anti-certificates, since one can create a nasty web of affirmations and denaials that is unresolvable. (Yes, literally from Logic 101 classes about paradoxes....)

1 0