December 2003 - cypherpunks-legacy

Re: DNS Security ( was Re: NetScape's dependence upon RSA down...)
by kerowe＠ncsa.uiuc.edu 17 Dec '03

17 Dec '03

At 1:58 PM 10/1/95, Donald E. Eastlake 3rd wrote: >DNS security is an important point. People not aware of efforts in this >area may want to check out draft-ietf-dnssec-secext-05.txt which has >more or less passed working group last call and is being considered by >th Security Area Directory / IESG. Reference code is also available >(see message pasted at end below). > >Donald But the proposed DNS extension itself does not deal with CRL and Key Compromise Lists. Ken. ------------------------------------------------------------- Kenneth E. Rowe (kerowe(a)ncsa.uiuc.edu) Senior Security Engineer (217) 244-5270 (Office) / Security Coordinator (217) 244-0710 (NCSA IRST) National Center for Supercomputing Applications *** email ncsa-irst(a)ncsa.uiuc.edu for computer incident response ***

2 1

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33.tar.gz For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)extropia.wimsey.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"ideath"} = "<remailer(a)ideath.goldenbear.com> cpunk hash ksub reord"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post ek reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"syrinx"} = "<syrinx(a)c2.org> cpunk pgp hash cut reord mix post"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub"; $remailer{"hroller"} = "<hroller(a)c2.org> cpunk pgp hash mix cut ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"crown"} = "<mixmaster(a)kether.alias.net> cpunk pgp hash latent cut mix ek reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)spook.alias.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"gondolin"} = "<mixmaster(a)gondolin.org> cpunk mix hash latent cut ek ksub reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut"; $remailer{"ncognito"} = "<ncognito(a)gate.net> cpunk"; $remailer{"precip"} = "<mixmaster(a)mix.precipice.com> cpunk mix pgp hash latent cut ek reord"; $remailer{"ecafe"} = "<remail(a)ecafe.org> cpunk"; $remailer{"wmono"} = "<wmono(a)spook.alias.net> cpunk mix pgp hash latent cut ek"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. News: the remailer list has been rewritten, and the new version is live! It should be more accurate, reliable, and faster than before. Penet is back up! Enjoy. remailer email address history latency uptime ----------------------------------------------------------------------- syrinx syrinx(a)c2.org --+-+++----+ 52:32 100.00% ecafe remail(a)ecafe.org *--********# 7:37 99.99% alumni hal(a)alumni.caltech.edu *##*#**+#*## 2:47 99.99% hacktic remailer(a)utopia.hacktic.nl *********+** 9:56 99.98% gondolin mixmaster(a)gondolin.org --+****+*--+ 2:04:31 99.98% robo robo(a)c2.org #+###**+#*## :59 99.98% replay remailer(a)replay.com +**+*-++*++* 11:35 99.95% bsu-cs nowhere(a)bsu-cs.bsu.edu #*#+###***-# 8:29 99.95% mix mixmaster(a)remail.obscura.com -++---+---++ 1:35:11 99.94% flame remailer(a)flame.alias.net *****++**+** 23:08 99.93% portal hfinney(a)shell.portal.com ## ##*+#*## 2:03 99.79% crown mixmaster(a)kether.alias.net ---+ --+-+- 1:18:05 99.70% ideath remailer(a)ideath.goldenbear.com -.-.---.--- 10:24:01 99.68% extropia remail(a)extropia.wimsey.com -.---.----- 8:06:45 99.54% rmadillo remailer(a)armadillo.com ++ +++++ ++ 43:52 99.08% vishnu mixmaster(a)vishnu.alias.net *+--*+ +** 20:36 98.79% c2 remail(a)c2.org ++++++ +++ 47:07 98.74% spook remailer(a)spook.alias.net ----------- 3:27:18 98.64% penet anon(a)anon.penet.fi - ++-++--++ 2:43:34 98.63% hroller hroller(a)c2.org #+###* **# :57 92.70% rahul homer(a)rahul.net **#****+### 2:05 99.52% wmono wmono(a)spook.alias.net **** 7:37 87.49% ford remailer(a)bi-node.zerberus.de **+*#***+ 6:37 68.05% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

`Hack Microsoft' challenge is NYT Computer News Daily's top story
by Rick Busdiecker 17 Dec '03

17 Dec '03

See http://nytsyn.com/live/Lead/275_100295_074418_19095.html MICROSOFT BECOMES NEW TARGET OF HACKING CHALLENGE (10/2) By HEATHER GREEN c.1995 Bloomberg Business News BERKELEY, Calif. -- Microsoft Corp. has been chosen as a new target for computer hackers. Community Connexion, an Internet service provider that last week promised a free T-shirt to anyone who found a flaw in Netscape Communications Corp.'s software, extended the challenge Friday to include holes in Microsoft products. . . . The article quotes Sameer and includes the URL http://www.c2.org/hackmsoft/ -- Rick Busdiecker Please do not send electronic junk mail! net: rfb(a)lehman.com or rfb(a)cmu.edu PGP Public Key: 0xDBD9994D www: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/rfb/http/home.html send mail, subject "send index" for mailbot info, "send pgp key" gets my key A `hacker' is one who writes code. Breaking into systems is `cracking'.

3 2

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

17 Dec '03

>Date: Wed, 27 Sep 1995 15:22:08 -0700 >From: Bill Stewart <stewarts(a)ix.netcom.com> Bill, >I'd always heard X.509 public key certificates were a hierarchical, evil, >anti-WebOfTrust ISOism. But Netscape is now doing them, and talking S/MIME, >so I sat down to read the specs, and they're really not all that bad. I was all set to scream, when I read this first sentence. Then I read on. >(Technically, I've only read PKCS#6 and RFC 1422, and not the real ISOisms...) >Yeah, they've got lots of clunky ASN.1 Ambiguous Encoding Rules and X.500 >Silly Name Format, but those can be lived with, and the X.500 may be possible >to simply ignore in most cases. At this point, I realized that we agree in evaluation but not in weighting. Twice now, I have had to deal with X.509 certificates in real code and it is excruciatingly painful -- especially for someone, like me, with some background in performance engineering and much background in software engineering. ASN.1 is not merely ambiguous, it is actively wrong as part of a design methodology. It encourages people to define structures in the BNF style -- and they do (witness X.509). When you translate this into C or PASCAL structures by an automatic translator, you end up with structures whose definitions are nested so deeply that even with short field names you would have variable names which occupy a substantial part of a line of text. However, ASN.1's BNF-ness encourages people to use longNamesWithEmbeddedCapitals -- so you end up with variable names which turn routine C function calls into multi-line, unreadable blocks. You also end up with too much code. I recently had to deal with X.509 certs for an authentication application (a firewall proxy). The proxy was about 30KB of code prior to the ASN.1. The ASN.1 code, just to do packing and parsing, was over 100KB (.o file sizes, in both cases). You also end up with too many bytes being transferred. I worked out an example of ASN.1 abuse -- defining a triple-DES key structure for encrypting and transmittal -- as a raw C structure (following long established practice and performance engineering (an array of unsigned char, with offsets for each key and the IV)) and as ASN.1 (following modern ASN.1 practice). The raw C structure was 32 bytes long. The ASN.1 structure was 86 bytes. Worse was the code dedicated to structure definition and packing/unpacking. In the raw C case, it took 48 ASCII characters to define the structure and its offsets (including comments) and nothing to pack/unpack. With ASN.1, it took 55085 characters of definition, pack and unpack code. This is a factor of 1148 in source code expansion. -------------------------------- I could go on at length, and have in other fora. Not only is ASN.1 clearly the work of Satan, the Distinguished Name definition is more than a victim of ASN.1 generality, it is a clear reason for the unpopularity of systems which use it. Do you remember when X.400 names started showing up in e-mail (e.g., with Lotus Notes). How many of those names do you see now? It didn't work. The concept is flawed -- but it lives on in X.509. [It reminds me of a flaky grad student's idea of a way to do things -- elevated to standard before people had the chance to try it and discover how completely bogus it was.] It is possible to implement something which reads and writes ASN.1 -- but it is ugly, it inflates your code and it hurts your runtime. I would like to see as many hold-outs against ASN.1 and Distinguished Names as possible. PGP is one such. TIS/MOSS has learned its lesson (from PEM days) and is making all of the ASN.1 and DN stuff (X.509) optional. With luck, the X.509 parts will die away (although MOSS was retarded so strongly in the PEM days that it may never recover -- may never acquire the market share to make it a force). I would strongly encourage others to join the battle. This might not be easy. It is clear that there is an ASN.1 juggernaut. It is taking over all sorts of standards. I believe I know why. It makes the job of the standards writer easier. However, I also believe it needs to be fought...not merely to save future S/W development efforts from the waste and abuse which ASN.1 creates, but also to take a stand against the process by which non-implementors get together on standards committees and come out with standards which preclude good software architectures -- and who, in a kind of old-boy-network, endorse other standards (e.g., the ISO set) as part of their own. Such a design process is destructive. - 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 | +--------------------------------------------------------------------------+

2 2

One-Time-Pad generation from audio device
by Rev. Mark Grant 17 Dec '03

17 Dec '03

Over the weekend I hacked up a one-time-pad generator from the random number code I've been writing for Privtool, which uses noise from the audio device to generate random numbers. The code basically reads in a 512-byte block from /dev/audio, then takes the MD5 of that block to generate 16 bytes of the OTP. The raw audio data I'm getting is not particularly random and will compress by 3:1 using gzip or compress, so I'm assuming that using a 32:1 ratio here via MD5 will give a truly random output (it's certainly uncompressible). Before I release the source code to the Net, can anyone give me any good reasons to believe that this won't produce physically random output, or make suggestions on how to test, or improve, the generated output ? There's a #define which can be used to easily increase the amount of data fed into the MD5, but at the moment it will only generate about 1 MB per hour on a Sparcstation (limited by the audio input rate), so I don't want to increase that if I don't have to. Mark

3 3

Introducing Johnson-Grace
by Publisher Program 17 Dec '03

17 Dec '03

Dear Web Publisher: You may have never heard of Johnson-Grace Company, but you have probably seen the benefits of our image compression technology in America Online and Apple's eWorld. "ART" compression substantially speeds up image transfers. In fact, ART formatted images transmit three times faster over conventional telephone lines than old-style GIFs and JPEGs. The immediate benefit is dramatically more compelling online content. Many of the hottest areas on AOL and eWorld are taking advantage of ART technology, including ABC, Business Week, The Smithsonian, NY Times, and 800-Flowers. Now, Johnson-Grace is able to offer the same benefit to Web publishers. To help you immediately reap the rewards of ART image compression on your Web site, Johnson-Grace is offering publishers the latest copy of our ART Press(TM) on a FREE trial basis for the remainder of calendar 1995. ART Press lets you easily convert your images to the ART format with its unique Web and online publishing features. For example, our proprietary Splash(TM) feature displays a full-size image in roughly one second; the image then becomes sharper as more detail is received and decompressed in additional layers, producing a high-quality final image within seconds. To get your free trial copy of ART Press, simply sign up for the "Johnson-Grace Publishers Program," a new program designed specially for Web and online publishers. At the foot of this email is an enrollment form. Just fill it out and email or fax it back to us. We'll send you the software right away (usually within 24 hours). For even faster results, just sign up online through the Johnson-Grace Web site (http://www.jgc.com/) Besides receiving ART Press, another prime benefit of joining our Publishers Program is that you will be automatically notified when any new versions of the software become available. Here are two more benefits: * FREE Technical Support -- For the remainder of calendar 1995 you will receive free expert technical advice on using ART Press. Support is available by email or by phone. * FREE Image Compression -- To help you get started with ART Press, Johnson-Grace will compress your original images into the ART format free of charge. Simply provide them to us in BMP, TIFF, or PICT format, and we'll do the rest. We've devised a method for allowing both ART and non-ART images to be accessed from your Web site depending on whether or not an ART-enabled browser is being used. Johnson-Grace and some of the larger browser companies have introduced a new extension to HTML, the X-ALTSRC attribute in the <IMG> tag. (<IMG> is the standard tag used to insert images into a Web page.) It indicates to ART-enabled Web browsers that an ART image is present. When an X-ALTSRC attribute is found, ART-enabled browsers will automatically use the ART image named in it, bypassing a SRC attribute it may find naming a GIF (or JPEG) image. Browsers that do not recognize the X-ALTSRC attribute will ignore it and read the SRC attribute instead, so there's no risk of incompatibility with these "old-style" browsers. Currently, AOL's built-in TurboWeb browser as well as other Web browsers including GNN and TeacherSoft recognize this new HTML attribute, representing a community of well over three and a half million users. As announced by Netscape, Johnson-Grace will be one of the first companies to provide a free plug-in for Netscape 2.0 which will allow Netscape users to take advantage of the ART format. This plug-in will be delivered as a "virtual bundle" so that support for the ART format will be automatically added to the browser the first time an ART image is encountered. Additionally, Johnson-Grace is in discussions with all the other major Web browser companies to include ART technology in their products. We expect broad support by the end of the year. Check out the Johnson-Grace Web site (http://www.jgc.com) to learn more about how to use ART's triple-speed advantage on your Web site. You'll also find a host of other useful information there designed specifically for publishers. In the months ahead, look for Johnson-Grace to provide additional "Instant Publishing" capabilities for Web and online service publishers. For example, later this year you'll see news of ART speech compression technology that will enable publishers to author interleaved sound and images for real-time playback at 14,400 bits per second. Think about what real-time sound can do for your Web pages! If you have any questions about the program, feel free to email techsupport(a)jgc.com. You can also call Tech Support at (714) 759-0700, or fax us at (714) 729-4643. Best regards, Geoff LeBlond VP, Licensing Johnson-Grace Company Enrollment for Johnson-Grace Publishers Program Please provide the following information to enroll in the Johnson-Grace Publishers Program Name: Title: Company Name: Company Address1: Company Address2: Company Address3: Company Address4: Telephone Number: Fax Number: email Address (email address is required to process your request) : Version of Software needed [ ] Windows [ ] Macintosh [ ] Both Type of Publisher (select one) [ ] Newspaper, Magazine, or Newsletter [ ] Merchant [ ] Company (e.g., product and sales information) [ ] Government or Non-Profit Organization [ ] Other (please specify) : Target Audience (check all that apply) [ ] Web [ ] Online Service(s) [ ] Both Web Site Information (1) Home Page Location (URL): (2) Launch Date: (3) Webmaster e-mail address: Note: By sending this registration form to Johnson-Grace Company, you agree to follow the following Publishers Program restrictions. (1) Do not use a trial version of ART Press after the end of the trial evaluation period. (2) Only Web and online service publishers -- defined as companies, organizations, or entities that offer content or information for display on the Web or on an online service for commercial purposes -- may qualify to participate in the Johnson-Grace Publishers Program. (3) Do not distribute copies of the program (all users must enroll), or attempt to reverse engineer the program. (4) Report any problems with the program to the Publisher Support Hotline at internet address techsupport(a)jgc.com, fax 714-729-4643, or telephone 714-759-0700 (ext. 215 or ext. 230).

2 1

Re: More forged cancels (fwd)
by Michael Froomkin 17 Dec '03

17 Dec '03

why is my mailbox full of stuff from mail.cypherpunks? **** PLEASE NOTE NEW E-MAIL ADDRESS: froomkin(a)law.miami.edu ********* A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin(a)law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | New address, but it's still just as hot here. ---------- Forwarded message ---------- Received: from relay3.UU.NET by law.miami.edu (4.1/3.1.012693-University of Miami Law School); id AA16017 for IFS=' '&&exec /home/faculty/froomkin/proc/procmail -t -f-||exit 75 #froomkin; Mon, 2 Oct 95 01:17:37 EDT Received: from toad.com by relay3.UU.NET with SMTP id QQzjqz13374; Mon, 2 Oct 1995 01:16:43 -0400 Received: by toad.com id AA17355; Sun, 1 Oct 95 22:13:04 PDT Received: from hudson.lm.com by toad.com id AA17346; Sun, 1 Oct 95 22:12:56 PDT Received: (from news@localhost) by hudson.lm.com (8.6.11/8.6.9) id BAA09549 for cypherpunks(a)toad.com; Mon, 2 Oct 1995 01:15:28 -0400 Path: hudson.lm.com!news.math.psu.edu!news.cac.psu.edu!newsserver.jvnc.net!newsse… >From: orbit(a)ix.netcom.com (Michael R. Grabois) Newsgroups: news.admin.net-abuse.misc,soc.culture.german,soc.culture.jewish,rec.radio.shortwave,alt.2600,mail.cypherpunks,alt.privacy.anon-server,alt.stop.spamming,alt.stop-spamming Subject: Re: More forged cancels Date: Mon, 02 Oct 1995 03:31:03 GMT Organization: Netcom Lines: 40 Message-Id: <44nmd0$q13(a)ixnews6.ix.netcom.com> References: <44n926$2dj(a)sundog.tiac.net> Reply-To: orbit(a)ix.netcom.com Nntp-Posting-Host: ix-hou6-03.ix.netcom.com X-Netcom-Date: Sun Oct 01 8:30:40 PM PDT 1995 X-Newsreader: Forte Free Agent 1.0.82 Xref: hudson.lm.com news.admin.net-abuse.misc:16173 soc.culture.german:76152 soc.culture.jewish:188004 rec.radio.shortwave:63171 alt.2600:125976 mail.cypherpunks:18586 alt.privacy.anon-server:4465 Apparently-To: cypherpunks(a)toad.com Sender: owner-cypherpunks(a)toad.com Precedence: bulk On Sun, 01 Oct 1995 23:45:24 GMT, jbyrd(a)tiac.net (Jim Byrd) wrote: [snip] >-----------------begin control message >Path: >sundog.tiac.net!news.sprintlink.net!in2.uu.net!sunic!mn6.swip.net!seunet!news2..swip..net!plug..ne >ws.pipex.net!pipex!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!news.gmi..edu!msunews!netnew >s.upenn.edu!ts7-28.upenn.edu!user >From: 73323.603(a)compuserve.com >Newsgroups: soc.culture.german,soc.culture.jewish >Subject: cmsg cancel <73323.603-3009951517290001(a)ts7-28.upenn.edu> >Date: Sun, 1 Oct 1995 17:56 GMT >Organization: The National Alliance >Message-ID: <cancel.73323.603-3009951517290001(a)ts7-28.upenn.edu> >NNTP-Posting-Host: ts7-28.upenn.edu >Approved: 73323.603(a)compuserve.com >Control: cancel <73323.603-3009951517290001(a)ts7-28.upenn.edu> >X-Cancelled-By: 73323.603(a)compuserve.com >Lines: 1 >CANCELLED. >----end control message Does this mean that the cancel came from the Compuserve account? Forging cancel notices is definitely against CIS rules, as is unsolicited e-mail. I've already talked to a sysop there about it, and he said he'd pass it along to the CIS Security folks. If nothing else, that may get his account revoked. Hey, small victories. Michael R. Grabois | orbit(a)ix.netcom.com Houston, TX | CI$: 74737,2600 ------------------------------------------------------- Gravity. It's not just a good idea, it's the law.

1 0

Certificate proposal
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- X.509 certificates are not totally bad. Their structure contains lessons for anyone designing a certificate structure. [Raw X.509 does not imply a hierarchy, I believe. Steve Kent & Co. do.] However, there are also some serious problems with X.509 certs, aside from their use of ASN.1. Perhaps the biggest problem is the use of a name -- a text string (or some abortion like the DN which can be reduced to a text string) -- as the anchor point. This anchor point needs to be unique. Since it is just a text string, that means that the certificate authority needs to guarantee uniqueness. However, it is also supposed to stand for a unique individual. Since it is not that individual's DNA sequence -- it is not testable. There has to be machinery set up outside the certificate definition for binding this text string to its individual. ------------------------------ PGP certificates have the same problem. In that case, it is an e-mail address and name (by tradition) as the text string. That needs to be bound to some physical body. If it is an e-mail name, there is some binding enforced by whatever access mechanisms protect access to that e-mail account. However, that binding is weak and also outside the certificate definition. ------------------------------ Let me propose an alternative unique name: the public key (or a good hash of it). The public key has an advantage over both X.509 and PGP names. The binding between it and its human being is testable. You can challenge the human in question to sign something. Assuming you use a public key as the unique name, you end up with a much simplified certificate. In fact, the notion of "certificate" may go away, in the sense that the certificate binds a key to a person through a unique name. The person binds himself to his key, on challenge (or on any message signature). What remains is a need for attributes to be bound to a key. For example, someone might testify that E0414C79B5AF36750217BC1A57386478 has brown hair, is balding and wears a pony tail, by signing a message to that effect. Someone else might sign a message stating that the person who owns the private key of 61E2DE7FCB9D7984E9C8048BA63221A2 is authorized to spend money from bank account number 07123 of Provident Savings in Columbia MD. That latter signator needs to be verified as authorized to make such an assertion -- and you end up with a certification chain -- but it is not hierarchical like X.509 and it is not web-of-trust -- it is relational. It is not a chain binding key to person but key's person to attribute or permission. It goes directly to what we need to accomplish without the middleman -- without stopping at a person in the middle. I realize that if you want to revoke a key, then it might help to have bindings be to something other than the key. That way, you can change keys out from under the binding. However, every method I've examined for accomplishing that has security weaknesses. The best method I've found yet has a very long signature key -- used only rarely (e.g., when acquiring an attribute-certificate worth a great deal; and signing more transient keys) -- and never normally revoked (or, if revoked, causing a widespread re-establishment of bindings -- like when you lose your wallet today). ------------------------------ Current certificates are going down a fundamentally wrong path. They are trying to bind keys to people and let Society somehow bind attributes to people -- but the latter binding is too weak to permit keys to be bound to attributes or permissions. The community will discover this, soon, but the farther we play along the X.509 path (especially, but also the PGP path), the more inertia there will be to overcome in trying to fix this problem. I would therefore suggest that the PGP development process address this issue now and continue the established habit of taking the lead into sanity. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +---------------------------------------------- Jean Ellison (aka Mother) -+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHAK8FQXJENzYr45AQFsdAP+JswAq/H4JIDE3+VlMsi87PBPCNBA7jg7 0ftkd8v7vrSSNda5aF+HVB7oKHylA/Lb90bvjMK7CKOJJ7aTzRP9IsAiz1i48FAR LAeD59v5SAKmAhaTMMYSRyKFRRXEaqIdEoJW3XKQBJ57b8R38vWKjR/11eTtCKjV joH4c5hhWmY= =ayYh -----END PGP SIGNATURE-----

10 16

Re: Yet Another "(Fwd) Internet Euro-Clipper"
by Peter Trei 17 Dec '03

17 Dec '03

> At 5:12 PM 9/29/95, Peter Trei wrote: > >Subject: European Governments Agree to Ban Strong Crypto > The biggest problem I have with this is that this is the third, fourth, or > fifth posting of Ross Anderson's piece to this list [...] > I urge people to read what's on the list and not repost things which have > already appeared. If they don't have time to read all of the messages on > the list, which is understandable, then they need to be even more careful > in posting things. Reading the list does not neccesarily help - I experience a several hour lag between when I post something, and when it comes back from the list server. Thus, even if I'm all caught up on my reading the list (as I was when I posted that article), articles may be 'in the pipe' which duplicate ones I'm thinking of posting. For those curious about the latency, I'm posting this at 12:08, on the US east coast. How long did it take to reach you? > > Not to pick on Peter Trei, as this happens all the time, whenever a hot > issue appears. Short of implementing some content-sensitive form of CSMA/CD, I don't see what we can do (but lowering the list latency would help a lot). > --Tim May Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

Re: NetScape's dependence upon RSA down for the count!
by cmcmanis＠scndprsn.Eng.Sun.COM 17 Dec '03

17 Dec '03

Don wrote: >I haven't read the SSL spec for a while but my understanding was that >the server passed it's public key to the client via a certificate >signed by a mutually trusted certificate authority (i.e., Verisign). > >How would the filter be able to forge such a certificate ? Why forge it? Why not simply buy a netsite server with a valid certificate. Let's say you paid full list for it $5000. It is the classic MITM attack but the protection against that attack was generally that the parties communicating "knew" each other. This is a fundamental weakness of putting the security at the SSL level as opposed to a possibly higher level. With the netscape attack since your client never cares "how" (or to whom) the SSL connection is made, it never shows you the information about where the source key came from. Only that it is valid. --Chuck

1 0