December 2003 - cypherpunks-legacy

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

Re: NSA says strong crypto to China?
by tallpaul＠pipeline.com 17 Dec '03

17 Dec '03

Logically, it seems the best thing for the NSA to do (given the political character of the group) is to send strong-but-not-that-strong crypto out. In other words, they would want the various offically-USA recognized "dissidents" (as opposed to officially-USA recognized "terrorists") to have crypto strong enough so that the various defined-as-repressive governments cannot decrypt it while not-strong-enough to prevent NASA from reading it. -- -- tallpaul -- Any political analysis that fits on a bumper sticker is wrong.

3 2

Re: "Microsoft.com" added to my KILL file
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:51 AM 1/7/96, Lee Fisher wrote: >| 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?) I'm reading this, obviously. I use Eudora Pro, a mail program, to filter messages into various mailboxes, based on key words in the headers. Rather than immediately trashing messages I wish to filter out, I put them into a mailbox I've labelled "Kill File." It is, however, just another Eudora mailbox, and doesn't get emptied unless I explicitly transfer the files into the "Trash" folder. (And to confuse non-Eudora users further, even my Trash folder does not get emptied unless and until I explicitly say "Empty Trash," as I have things configured.) This allows me, when I am bored, to see what stuff has floated into my Kill File mailbox, and sometimes to even respond. My point about filtering out all Microsoft.com addresses was really to make the point that Microsoft needs to understand--as they seem to be doing, vis-a-vis their new Internet strategy--that if they want their mail to be read outside of Microsoft, then they have to conform to certain emergent standards. ... >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. This is a battle I've been fighting for roughly the past year. When I get a blank message from someone saying only "attachment converted," I add that username to my kill file. My feeling is that a mailing list with 1000+ subscribers, or even one with far fewer, is a terrible place to send non-ASCII messages. Readers will be using VT-100s on campus networks, old Amiga 1000s, EMACs, Suns, Macs, IBM PCs, Windows, and all sorts of configurations to read mail, and there is almost no chance that all or even most of these will be brought up to the latest MIME standards. Plain ASCII, such as 98% of this list has been for the past several years, is the lingua franca, the lowest common denominator (see, some number theory relevance for you purists!) of the Net. There has been little compelling need for embedded spreadsheets and embedded graphics. And as for attachments, such as attaching programs for running on a machine, mailing list messages are a very poor way to distribute such programs, for many reasons. (Sure, a chicken-egg situation. But most of what people have to say in chat groups, in Usenet groups, and on mailing lists is of a primarily _prose_ nature...few of us would be willing to prepare line drawings, graphs, spreadsheets, etc., for casual posts. My hunch is that if a fully graphics-supportive mailing list were to emerge, most people would not generate _new_ graphics for each post (such as graphs to make a point) but would simply clutter up their posts with cutesy logos, pictures of their cats, etc.).) --Tim May We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: "Re: NSA says strong crypto to china??
by Alan Olsen 17 Dec '03

17 Dec '03

At 10:47 AM 1/7/96 -0800, Raph wrote: > > My best guess is that we're seeing a distortion of this >interchange. If I were a Chinese dissident, I wouldn't want to use >GAK, for three reasons: using US-lackey encryption is certainly not >going to get you into any _less_ trouble than using independent >encryption, if you used GAK you'd be working as a US spy whether you >wanted to be or not, and finally, who says the Chinese can't decrypt >it, especially with the rapid growth of television. I can also think of another good reason that no dissident in their right mind would want to use US escrowed GAK. How many times have individuals been sold out for some "greater good". I can just imagine some dissident getting sold out as the result of some mega-trade deal or the like. (And I am sure that they can too...) Why does this news report sound more like someone trying to sell GAK to the US public and not "chinese dissidents? > >Raph > >P.S. To those who are suriprised that I'm still here - my flight got >delayed, and I'm waiting it out on the Net, in true geek style. > > Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "Governments are potholes on the Information Superhighway." - Not TCMay

1 0

Re: phone calls from hell
by jim bell 17 Dec '03

17 Dec '03

At 01:15 PM 1/7/96 -0500, you wrote: >SNS News Service "Exploding Phone" >January 7, 1996..15 Teves 5756..Number 850..Update from Israel >It is now being reported that the cellular phone that killed him was >detonated by a remote control. The son of Ayyash's landlord, identified >as Ikrimeh Hamad, was expected to have handed Ayyash the phone >earlier in the day. Some reports state that his whereabouts are >unknown but other reports stated that he is now hiding-out in Israel. >>>27 Heathway Court * London England * NW3 7TS * 44-181-458-6510 >Fax: 44-181-455-8701 > Copyright, Shomron News Service, 1996 > >*** > >Comment by bd: > >I suppose this phone was prepared especially for Ayyash, but the >imagination wanders. Imagine a world in which *every* cellphone >(or other net-connected computer or ....) had a little explosive built >in. For that matter, the case itself could be constructed of a plastic >explosive. > >Sure would make it easy to get rid of unwanted citizens. >Just match the voice pattern on the cellphone or confirm the password >issuing from the computer, send the special signal down the line and >*BOOM*, one less nuisance for the state. Sorta gives new meaning to the term "_Terminate_ and Stay Resident" program, doesn't it?!? (Or "end of file.")

3 2