December 2003 - cypherpunks-legacy

Re: CISS TSP MISSI
by Rich Salz 17 Dec '03

17 Dec '03

I don't know which is more annoying: The silly 3/4K of Comments that the freezone remailer puts out. (The use constraints are useless to email recipients, after all); or That some anonymous bozo is posting open WWW data to cypherpunks. I hope that the first, at least, can be fixed. Avoid clutter; note the reply-to. /r$

1 0

Re: economic espionage (@#$%^&*) (fwd)
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

NY Times, Oct 3, 1995, Business Employment Ad. 1984 Sarajevo, Olympics; 1995 Sarajevo, Battleground Every day in our world, new threats, new challenges, new missions emerge. The people of the Central Intelligence Agency are dedicated to meeting the missions of the day, providing information and resources that aid decision makers in solving the problems and responding to issues that affect us all. You can play an integral role in our mission, while advancing your own career. The Central Intelligence Agency is currently seeking professional men and women who will be comfortable living and working abroad. These positions entail extended overseas assignments in various parts of the world. Previous service in long-term foreign assignments, in either business or government positions, is a definite advantage. Changing international economic, political and social conditions make a broad range of professional backgrounds suitable for these positions. Your experience may be in economics finance, marketing, or general business. Scientific or technical experience in engineering disciplines, physical sclences, biological sciences, or any area of high technology research and development is of particular interest. These overseas positions require more than appropriate professional experience. Successful candidates must also demonstrate a high degree of individual initiative, self reliance and personal integrity. Naturally, the ability to speak or learn a foreign language is expected along with above average communications skills, both oral and written. A Bachelor's degree is a minimum requirement. Advanced degree or military service is a plus. All applicants must successfully complete a thorough medical and psychiatric exam, a polygraph interview, and an extensive background investigation. U.S. citizenship, or eligibility for citizenship, is required. CIA encourages applications from men and women of every racial and ethnic background from all parts of the nation -- we represent America and we want to be representative of America. We will respond within 30 days if your application is evaluated as being of interest. Central Intelligence Agency Dept. 15FS P.O. Box 12002 Arlington, VA 22209-8727 Fax: 703-482-7395 CIA is an equal opportunity employer [CIA eagle-headed all-points shield logo] [Motto] Meet the Challenge of a Changing World -----

2 1

Re: New Netscape bug (in version 1.12)
by Steven Champeon - Imonics Development 17 Dec '03

17 Dec '03

| From owner-cypherpunks(a)toad.com Tue Oct 3 11:07:33 1995 | Subject: Re: New Netscape bug (in version 1.12) | Cc: rjc(a)clark.net, cypherpunks(a)toad.com | X-Mailer: ELM [version 2.4 PL24alpha3] | Content-Transfer-Encoding: 8bit | Sender: owner-cypherpunks(a)toad.com Ray wrote, in reply to my message: | > | > Well, I'm still in Raleigh :-) but this doesn't do much of anything | > to my Macintosh, Netscape 1.1N, under System 7.5. Looks like a bug | > in your X server. However, Netscape 1.1N for Solaris, running under | > X11R6 X server, dumps core fairly quickly. I haven't had a chance | > to try out the 1.12 version on UNIX or Mac, but the 1.22 32-bit | > Windoze version handles it fine under NT 3.5.1. | | Could someone try this on Solaris using 1.12? Just tried it, with two different mailhosts - the first gave the following error: An error occurred sending mail: The "To:" header was invalid. Please check the email address(es) and try again. The second accepted the mail. (?) Neither caused it to core dump, under the X11R6 X server, Solaris 2.4, running Openwindows. Cheers, Steve -- Steven Champeon (919) 469-7833 Technical Lead, schampeo(a)imonics.com Imonics Web Services webmaster(a)imonics.com

1 0

STT Authentication
by Andrew Roos 17 Dec '03

17 Dec '03

Hi All Ramblings from a disturbed mind... I've had a look at Microsoft's Secure Transaction Technology (STT) protocol. The purchase order/authorization/receipt phase is authenticated using the card holder's credential ("cred", in MS speak). The credential is similar to a certificate except the binding is between a credit card and a public key, rather than between an identity and a public key. What interests me is the procedure for issuing cred's to cardholders. If I'm reading the spec right, this is done in response to a "Cardholder Credential Request" message which includes card details and the public keys to be associated with the card. This data, along with a SHA hash of the data, is encrypted and sent to the issuing bank, which then responds with a "Cardholder Credential Response" containing the signature and key-exchange creds, also encrypted. However there does not appear to be any authentication whatsoever on the credential request message, presumably becuase the cardholder does not have a published public key at the time when this message is issued. It may be that authentication is out-of-band - e.g. the bank may phone the registered owner of the card # before issuing a cred response message - but there is no mention of this in the spec. If there isn't OOB authentication, then this is a major hole in the protocol, since anyone who knew a credit card no, name and expiry date could request a cred for that card, and then go shopping... If someone will just tell me what I'm missing (because this is too obviously f'd up for even Uncle Bill) then I'll go sit on top of my mountain again and hum softly to myself. Andrew BTW, same apears to be true for Merchant creds. ________________________________________________________________ Andrew Roos <andrewr(a)vironix.co.za> // C++ programmers have class (but not much inheritance) PGP Fingerprint: F6 D4 04 6E 4E 16 80 59 3A F2 27 94 8B 9F 40 26 Full key: ftp.vironix.co.za/PGP-keys/AndrewRoos (or key servers)

1 0

Re: X.509, S/MIME, and evolution of PGP
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Tue, 03 Oct 1995 11:37:22 -0700 >From: Bill Stewart <stewarts(a)ix.netcom.com> >At 10:24 AM 10/3/95 EDT, Carl Ellison <cme(a)TIS.COM> wrote: >>I hear you but I object. >>Going along with the majority may be the fastest way to get a result out >>but it's morally wrong. > >A zillion and a half people are about to get the next version of Netscape, >which uses X.509 certificates, and they can get free Verisign personna >certificates to go with them; stores can get inexpensive ones. >They will use this for secure email, like it or not, >and as they discover the need for better certification (when there's >money involved), they'll go get it. Wherever they can. Yup. Verisign is probably going to fight hard to keep their certificate model. On top of them, there's the US Postal Service and a few others, fighting over the chance to set up a certificate hierarchy. The whole world is thinking of physical people and of tying things to those people. They think of names as the only handle on (pointer to) people. ...so they see certificates as right and proper. We need to show them a better way. (Tie attributes through the key to the person -- not through the person to the key.) >The question is, will they get a Web of Trust model from us, >or will they stick to the hierarchical model? As several have pointed out, a certificate structure (X.509, PGP or mine) can be used in a hierarchy, if you want it, or not if you don't. We don't care. What I care about is that a signed thing (one link in a chain of assertions) speak directly to what it is signing ("this key is good for _________") or ("the person who demonstrated to me that he knew the private key for this key has red hair and wore glasses") -- rather than try to sidle up to existing people structures (by tying to names of people) and then, on discovering that the people-structures aren't as strong as the digital signatures, make the people structures stronger (e.g., by unique ID number on a national ID card, with thumbprints for verification). > If we get something >halfway decent out there, fast enough, ideally with support >or toleration from Netscape, people will at least have distributed trust >models in their worldview, and will insist that the tools they use and >build around it be compatible. Otherwise, almost all of them _will_ be >using the hierarchical-only structure, and the next big Internet application >that >needs security will latch onto the now-big software base, and may not >be as decent as Netscape about the trust models they accept. Yes -- I agree. We should get cracking on this. >If you can define a better relational trust model than the Web stuff, >fast enough to avoid this, great! Go for it. But it'll be much easier >to get something like that adopted in a non-hierarchical world than in >a world of Drivers' Licenses on the Information Superhypeway. I'm still talking web of trust -- only I'm removing the person's name (or e-mail address) as a link between the assertion and the key. Haven't I described this well enough? Do I need to write it up in more detail? How about some analogies? I could have a driver's license (giving my name and address), a piece of paper saying that I (at my address) own bank account number 01732 at First Security Bank, and a certificate from Verisign also giving my name and address. This ties my public key to my driver's license (assuming I'm the only Carl Ellison at my address (which I wasn't, as a kid) and that I don't move). Alternatively, I can have First Security Bank open account 01732 for me and create a certificate binding my public key to that account number. Now, I can use that key to sign anonymous checks. (The bank knows me, perhaps, but the payee doesn't need to.) To tie my name to the public key, I sign my own certificate saying ``The person who knows the private key for 61E2DE7FCB9D7984E9C8048BA63221A2 goes by the name "Carl Ellison" and receives mail at "cme(a)acm.org".'' I don't need anyone else to attest to the validity of that statement because it's uni-directional (from key to my name), not the other way. It's only the other assertion direction which requires some witnesses to attest to validity, because the name is not capable of doing a digital signature without a key. [That is, if you were to go the other direction (which is what X.509 or PGP try to do), you need to sign a key with a name (DN or UserID). You can't sign with a DN or UserID. You can sign with a key. So, you have to fall back on human witnesses to use their keys to sign in place of the name (DN or UserID) and you have to decide how to trust those witnesses. If you reverse the arrow of assertion, this particular problem goes away.] - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHGLpVQXJENzYr45AQFS2QQAidMwZMBbv2ap2S4ZNVIWfZO6/W1FHOaw GZYHQk38o0qD5YOrth1Hab2IiyuvLtBG38hHJ8aZf3NsvzswSvNExuBQy+eLns8m ZcM2B4qPMRWOP1XMmAPaoaknRTmonKP/acO4KcKIR0K+x+n1DNwTwyDx4LbRjOnn hHp3fFfD7iI= =Fccl -----END PGP SIGNATURE-----

1 0

Re: Certificate proposal
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:21 AM 10/3/95 EDT, Carl Ellison <cme(a)TIS.COM> wrote: >The whole issue of CRLs is on shaky ground with me. I think it's gotten >lost in debates about how to distribute them offline (or perhaps via >e-mail) and have them work. No surprise; it's a tough job. I don't expect my laptop to be continuously on-line when I'm reading mail, and even on-line use needs to be more realistic than saying "Everybody must use X.400". >CRLs are like the old credit card or check stop lists which used to be at >every supermarket checkout station. They aren't there any more. >Checkout stations are now on-line. >I see nothing wrong with having a "certificate" which says ``certificate >available online only at xxx(a)yyy.zzz''. Interesting. Aside from the excessive cost of looking up cards in paper booklets, which can be avoided by having checkstands validate on the store's backroom computer system, on-line verification lets the card company not only refuse stolen cards, but also dynamically refuse cards that have reached their credit limits, which you can't do on a slow push-based offline system. However, it's _very_ tough to spoof a credit-card verification system, because the checkout device uses phones or private networks to reach the authorization company, so the response that comes back saying yes/no/stolen can be real dumb. On the internet, the response needs to be signed, though I suppose it could say "Key sssss at xxx(a)yyy.zzz authorized key uuuuu today yyyy/mm/dd/hh:mm:ss, valid for up to $500", and you'd then have to validate the key that signed it, etc.... On the other hand, you could have the cert require multiple confirmations, e.g. both the bank and the user have to authorize this use. >>3) Neither PGP nor X.509 (as documented in the RFC1422 and PKCS#6) have any >> mechanism for additional information other than cramming it into >> the username, but supposedly X.509 Version 3 includes something? >Yup -- and it's ugly. It counts on a defined OBJECT ID to define the OBJECT IDs solve two problems - one is that you need some kind of format (yuk), but the other is that fields to have mutually agreed on values to be meaningful, and central registration is an easy way to implement it, as long as there's a simple way to register things. I hope it at least supports an OBJECTID with parameters, e.g. "CreditLimitUSDollarsBankFoo integer" rather than needing excessively many OBJECTIDs "CreditLimit3700USDollarsBankFoo"? As you say below, there's certainly no need to use ASN.1 formats instead of readable ones... > What's invalid is the assumption that >there must be a relationship (or even a person) in physical space *before* >one can have a relationship (or a person) in cyberspace. Yeah. I've decided, as an experiment, to start signing keys for pseudonyms, though I haven't settled on how to deal with unauthenticated signatures for realspace people (in the one case where I've been asked, the person didn't have any independent signatures from other people, so so far I've declined, but I may re-evaluate and just do uniqueness.) #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

Oct 14 DC-area physical meeting
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

Sorry to send this to 800+ folks, this is the only announcement I'll send this month. The October DC-area cypherpunks meeting will be on Saturday, Oct. 14 at 3:00 PM at the Digital Express offices in Laurel. For more information (directions, agenda, etc.), please see url: http://www.isse.gmu.edu/~pfarrell/dccp/index.html Additional agenda topics solicited! Thanks Pat Pat Farrell grad student http://www.isse.gmu.edu/students/pfarrell Infor. Systems and Software Engineering, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer

1 0

(fwd) ETO TENDER
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Tue, 3 Oct 95 09:14:04 -0400 From: "GORD JENKINS" <jenkins(a)fox.nstn.ca> X-Minuet-Version: Minuet1.0_Beta_14.1 Reply-To: <JENKINS(a)fox.nstn.ca> X-Popmail-Charset: English To: www-buyinfo(a)allegra.att.com, untpdc(a)urgento.gse.rmit.EDU.AU Subject: ETO TENDER For List: Ref UN Trade Point ------------------ Attached is an alternative to the use of electronic brokers who charge per transaction. This sevice is free and very well organized. Check out the UNCTAD Trade Point Web site at: http://www.unicc.org/untpcd Gordon Jenkins Emailjenkins(a)fox.nstn.ca URL : http://www.infop.com/karoma ----- Forwarded message begins here ----- From: UNTPDC <untpdc(a)urgento.gse.rmit.EDU.AU> Thu, 28 Sep 1995 11:47:45 +1000 (EST) To: ETO gateway <etotrade(a)wtm.com> Subject: ETO TENDER TO : ETO ASSOCIATES - TRADE POINTS FROM : Carlos Moreira Head United Nations Trade Point Development Centre UNCTAD Subject : ETO Tenders Dear ETO users, we are introducing a new service to the ETO systems which relates to international tenders. The service ETO Tender is also free and we will disseminate the information via email. The tender data is always free text so we will not codify the information. Please send us your national tenders so we can increase the number of tenders on-line. With my best regards Carlos Moreira ETO TENDER Japan FOREIGN GOVERNMENT TENDER Description: S16 CONSTRUCTION Comments: PRODUCT DATA A. INDUSTRY SECTOR CODE: B. DETAILED PRODUCT DESCRIPTION: CONSTRUCTION TITLE: PRELIMINARY DESIGN OF THE KOYA JUNCTION BRIDGES; SUMMARY: PRELIMINARY DESIGN OF BRIDGES FOR GENERAL AND EXCLUSIVE USE AT THE KOYA JUNCTION (TENTATIVE NAME); DELIVERY DATE: MARCH 25, 1996. C. PRODUCT SPECIFICATIONS/TECHNICAL DATA: N/A (NOT AVAILABLE) D. QUANTITY: N/A E. U.S. DOLLAR VALUE: N/A F. OTHER INFORMATION: N/A RESPONSE DATA A. RESPONSE LANGUAGE: JAPANESE. B. BEST WAY TO RESPOND: LETTER. C. FROM MANUFACTURERS ONLY: N/A D. INFORMATION DESIRED FROM U.S. FIRM: N/A E. PRIMARY BUYING FACTOR: N/A F. OTHER INFORMATION: INTERESTED FIRMS MUST SUBMIT THEIR EXPRESSION OF INTEREST IN THIS DESIGN COMPETITION BY 17:00 PM, SEP. 29. THE PROSPECTUS MUST BE OBTAINED DIRECTLY FROM THE PROCURING AGENCY, NOT FROM U.S. EMBASSY. TENDER LEAD DATA A. ISSUING AGENCY: METROPOLITAN NATIONAL HIGHWAY WORK OFFICE, KANTO REGIONAL CONSTRUCTION BUREAU B. FINANCING AGENCY: SAME AS ABOVE. C. PRICE OF PROSPECTUS: N/A D. OBTAIN PROSPECTUS BY: OCT. 23, 1995. E. TENDER NUMBER REQUIRED IN ALL COMMUNICATIONS: N/A F. PERFORMANCE BONDS REQUIRED: N/A G. CLOSED PROCUREMENT PROCEDURE: NO. H. BIDDING PROCEDURES: SELECTIVE TENDER. I. PROPOSAL DEADLINE: 17:00 PM, OCT. 24, 1995. J. OTHER INFORMATION: "KENSETSU KOGYO SHIMBUN": 9/19/95. CRITERIA FOR QUALIFICATION, SELECTION, AND SCREENING: 1) QUALIFICATION CRITERIA FOR PARTICIPANTS: FIRMS PRE- QUALIFIED FOR OPEN COMPETITIVE OR SELECTIVE BIDDING ON CIVIL ENGINEERING CONSULTING WORK BY THE KANTO REGIONAL CONSTRUCTION BUREAU; 2) SELECTION CRITERIA FOR PARTICIPANTS: A) RECORDS OF SAME TYPE OR SIMILAR WORK; B) CONDITIONS OF REGISTERED BUSINESS; C) AVAILABILITY OF SPECIALIZED ENGINEERS; D) QUALIFICATION, BACKGROUNDS, AND WORK INVOLVED OF ASSIGNED ENGINEERS; E) PLAN FOR SUBCONTRACTING; AND F) RELATIONS WITH CONTRACTORS; AND 3) SCREENING CRITERIA FOR DESIGN PROPOSALS: A) HISTORY OF COMPANY'S BUSINESS: RECORDS OF SAME TYPE OR SIMILAR WORK; AVAILABILITY OF SPECIALIZED ENGINEERS; B) EXPERIENCE AND ABILITY OF ENGINEERS: QUALIFICATION, EXPERIENCE, WORK INVOLVED, AND WORK RECORDS OF ASSIGNED ENGINEERS; AND C) PLAN OF ACTION AND ITS METHOD: LEVEL OF UNDERSTANDING OF PROSPECTUS; APPROPRIATENESS OF PLAN OF ACTION; ADEQUACY, ORIGINALITY, AND FEASIBILITY OF PROPOSAL; AND APPROPRIATENESS OF PROCESS AND MANPOWER PLAN. POST REMARKS: POST CONTACT/PREPARED BY: HAOMORI APPROVED BY: GTAEVS CONTACT: FIRST PLANNING AND DESIGN DIVISION, METROPOLITAN NATIONAL HIGHWAY WORK OFFICE, KANTO REGIONAL CONSTRUCTION BUREAU, MINISTRY OF CONSTRUCTION, 86 TAKEGAHANA, MATSUDO-SHI, CHIBA-KEN 271, JAPAN PHONE: 81/473/62-4115 FAX: N/A Please send a copy of your response to: COMMERCIAL OFFICER (FCS TOP) AMERICAN EMBASSY TOKYO UNIT 45004 APO AP 96337 Refer to TC606 ------ Forwarded message ends here ------ -- GORD JENKINS e maik JENKINS(a)fox.nstn.ca tel 613 794 6735 fax 613 723 8938 --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Monkeywrenching Certificate Schemes
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:15 PM 10/3/95, Carl Ellison wrote: >Yup. Verisign is probably going to fight hard to keep their certificate >model. On top of them, there's the US Postal Service and a few others, >fighting over the chance to set up a certificate hierarchy. Almost needless to say, there is nothing particularly wrong with certificate-granting agencies. A big caveat: Providing the process is fully voluntary. (I'm not addressing issues of implementation, of the "X.509" messinesses, etc.) The big danger I see in all this talk of "certificate authorities" is that it won't be a voluntary process. (The same themes as with key escrow.) I'm not suggesting we waste our time arguing against such certificate authorities. Rather, we might better spend our time finding ways to monkeywrench the proposals. I don't want either the "Postal Service" or "Verisign" given the authority to approve or disapprove my identity or any identity I may choose to adopt. Isn't it about time for SAIC to acquire Verisign? --Tim May (Identity Subject to Approval) ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

HUL_loo
by John Young 17 Dec '03

17 Dec '03

The Economist of September 30-October 6 has a long survey of global telecommunications, excellently researched and written: The death of distance as a determinant of the cost of communications will probably be the single most important economic force shaping society in the first half of the next century. It will alter, in ways that are only dimly imaginable, decisions about where people live and work; concepts of national borders; patterns of international trade. Its effects will be as pervasive as those of the discovery of electricity. Buy it, see it at http://www.economist.com, or, in a pinch: HUL_loo (92 kb in 6 parts)

2 1