December 2003 - cypherpunks-legacy

US DoJ Zimmermann Press Release
by Declan B. McCullagh 17 Dec '03

17 Dec '03

>From Mike Godwin and Stanton McCandlish. Transcribed from fax. -Declan ----------- [begin] [logo] United States Attorney Northern District of California _____________________________________________________________________________ San Jose Office (408) 535-5061 280 South First Street, Suite 371 San Jose, California 95113 FAX: (408) 535-5066 PRESS RELEASE FOR IMMEDIATE RELEASE January 11, 1995 Michael J. Yamaguchi, United States Attorney for the Norther District of California, announced today that his office has declined prosectution of any individuals in connection with the posting to USENET in June 1991 of the encryption program known as "Pretty Good Privacy." The investigation has been closed. No further comment will be made by the U.S. Attorney's office on the reasons for declination. Assistant U.S. Attorney William P. Keane of the U.S. Attorney's Office in San Jose at (408) 535-5053 oversaw the government's investigation of the case. [end]

2 1

Novel use of Usenet and remailers to mailbomb from luzskru@cpcnet.com
by abostick＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Somebody, too clever for their own good by half, has come up with a novel way of using Usenet and anonymous remailers to perpetrate mailbombs. The M.O. is to post a message to the naked-lady newsgroups saying "get pics in your mailbox! send this message to this address!), giving the email address of a cypherpunk-style anonymous remailer and including a pgp-encrypted message block. Thousands of horny net geeks will send in the message; some of them will even follow instructions correctly so the remailer forwards the message to its intended target. The result is that the target will be mailbombed -- and the remailer operator can't stop the abuse by blocking the abuser's address, because it's coming from all over the net. There is *no* chance that this is legitimate. The remailer discards the original message header. There is no way for the recipient to know who sent the email message. Cypherpunks: is there any way to respond to, or prevent, this sort of attack short of actually shutting down the remailer? What comes to my mind is the remailer operator grepping for a character string of ASCII-armored cyphertext from the known attack message and throwing messages containing it into the bit-bucket. It is highly unlikely that this would appear in any message except the attack message. The problem with this is that it works only for a known attack message -- it can shut down an ongoing attack, but it can't prevent new ones. I am including the widely-crossposted attack message below, including headers. Alan Bostick | He played the king as if afraid someone else Seeking opportunity to | would play the ace. develop multimedia content. | John Mason Brown, drama critic Finger abostick(a)netcom.com for more info and PGP public key > Xref: netcom.com alt.sex:292849 alt.sex.wizards:44144 alt.sex.magazines:11634 alt.binaries.pictures.erotica:364153 alt.binaries.pictures.erotica.blondes:48686 alt.binaries.pictures.erotica.female:130066 alt.sex.movies:91249 alt.sex.pictures:98757 > Newsgroups: alt.sex,alt.sex.wizards,alt.sex.magazines,alt.binaries.pictures.erotica,alt.binaries.pictures.erotica.blondes,alt.binaries.pictures.erotica.female,alt.sex.movies,alt.sex.pictures > Path: netcom.com!ix.netcom.com!howland.reston.ans.net!news.sprintlink.net!nuclear.microserve.net!luzskru.cpcnet.com!www-39-190 > From: luzskru(a)cpcnet.com (luzskru) > Subject: Get Penthouse and Playboy pics on your mail box!! > Message-ID: <1b7cc$12a26.20(a)luzskru.cpcnet.com> > Date: Thu, 11 Jan 1996 18:10:37 GMT > Organization: http://www.cpcnet.com/~luzskru/home.htm > X-Newsreader: News Xpress Version 1.0 Beta #4 > Lines: 119 > > Follow these instructions. > 1) paste everything between the -------- into the body of your message. Be > sure to leave the first line blank and include everything including the :: > 2) Send the message to homer(a)rahul.net > 3) as the subject, specify playboy or penthouse and the month. > 4) if you don't get the file within a few hours, then send it again and be > sure that you didn't do something wrong. Here is the message: > > --------------------------------------------------------- > > :: > Encrypted: pgp > > -----BEGIN PGP MESSAGE----- > Version: 2.6.2i > > hIwDuhnKCI5qH1EBBACCHVVFVfrX6fQ9QzUFVe8aCb+2g1M71Utg1ZJKGrq1S16v > 0q/H8RvBa4bpg1RCx6IjhScaHqW66uubAUY1GOlzvWiMW4xw+3kEcO7lep8crvH0 > +/YXe6S2jlIUjMW7FncoFSrBIumrPXygkXHtkTjStvJiBdXyXlmgahyl9nlaNKYA > ABGCfXDZs31NP39/YeJmyP7M+edjKsKpTs8A9tW58Fm45Nlr/wStSsRsteTy/lQu > +O5Hft36bsci8B8Y4gsSLlZ71a1GLvBhSOx5qfXIOStAaLZobfbPYd+WWJMiIXcv > dGhl6SOoyUo5xc6ty7/Z4/vvxtOtndJMz7acsEk2pFQX8WNpBZRg+WRBOlTAKPDW > vQhnowKeIna8wq8FfOJFQzdM3uxgYBeoqRc6dRGlB8+V+aOicAtZHdRgTjH4hgAk > QF8W1lXDYc6OJZn3cR4WcoCYQnrGYLyFCEF/eU4umrFaCjs2HAql/ygBoK1AAloi > BE2HSeKI+gh6DXwbR3Ub9FWkMGr8t3S2AHe4FzbJlIrnJEvSQUcihro+aCG/wGr4 > 0KyvfZuuBgKX7XiSEnZeoO+UcF9yBlnvy7FhNT7skmjZ79JH0aCnSgSE0u9Ta/Dw > WGQT8nIz7Ex7T4sObGtKgSk2Ari86a+qM4McTBpelKmXIQLoivyuEW1r0OsRUJdA > 1iwk2ILNL2Sn6/cHQaZKnGCSasWqxlM3cDcfit6M2y/3Jryj4fh29B2rYY+A8fP1 > VU8uwFZ5whOBw7TcoS2dAoqOBOEYKz3pItCAxTMZ8UN1qu0EGXuBxSLLbNQtRShN > oGddR2jlv43Js07rumdMGUazTiAUUY27Pb1w3V9dcvL3YALFjtEB2Keg9A4foyaf > o1Krbxg/dMTVVcXuneP0ayhg3QGRlks5Gr+jGhTYUfrn9WetyI9nXeqzpvcwtXbc > GkxHpQboQNeWiRkhkbmnBvbT/IseehBcC7NsyP9P6K/XxY02ebimFo51xpxM4Bsy > MjMo1N/e9mvPuh1mzpbQwzuba9udM5Np2E9h7PKXO9F0PbMiLW1LMZ7lqfh4FHQO > vhV/FwjkhTtCc/+T4ZNgpYcJ7PwM9s8JKxNWB73AFkTKBx4gQNDnhHNty77YunYU > Rj8vUgiSRb+1hPejecxcfNAr5g3TAM/mJuVLg5njCkr3o2fuL4wGF5lz/GZ2l3sE > sOs+BDQhZcefX4MOq7Ys60rAMvNizzQUo4H5aIdYzT4MYfw+4xPjOLcaHvzAYU7M > WbeFoLdm7nC+//3ah5e1Bkk6POKUb6SnCJnUa/JyLV7+2PLo+YkwnokkSrB61bUf > 7blbc91VSjaQ+wsUwBoVHu2RRg9QCtxTQKDilKG3oYISnnA1LaOhMfFVm1XKm7Oe > 540eeJu7MGT+kLKjLe+UF1TDrZG7r9v/WK2SgTbliTvDzhj0dBhJ1MoDZxhx+h3m > GM/kyqyV8YcTpBC8ePmzYE+j8gMTakihRslWPZn2SxT18leerbyMsyplyXdAowdW > HXhTNuoolLJQPFpu9gK4kbr7U6KVdHPbUDDw+0km6pcJ8qWR4kCUD3Y8aMNfzggh > VxuCqbdJdfYL8YzS3Z0PknzorgdvuWR/BXAkf/Jh9+zTNRgLu5TnueA6Ae68uIqp > VDU0cetrD7ys5Wb+rq6Tg1WRgkpyg2iWdxdFpVb3w9zvdtV4MvfbVG8ckY1qYrAY > wZgJOdWHtCW37UWXXgHWTrifsjNLeKVSSSrOIDzsxbI0wuwTadFRG/4Ci7A0K/C8 > 2lGs+gluHw6iTV0uSwxyZXr3JQR7R1VH4zb3sjDDd5X6YmR2OwThT934G49W4Afa > 3F1gv4M5/9JVKTdRJGYPfYwDTbtfPHMWgj33rtsBbILBZ4HBJKoBDCygJfZzO6Jm > fbUOqzB9+rPQLbD0DcxOoUyVtynWr9xG2M/WbvzjN+y28/YAQLrNvkppxA4psjNQ > j/jS3od7HY1BWRvBGOgybrnovK9+ZbphLHHZzx+WcuG4ngtYriETlr5ZhlznT6Hv > 5+vCJjIZHwp7x+sscxbYsSgyrtzi+nam1kiljLowN+avbaA/Xt3K7zymMAVbFq3T > cM6Q4Gq07wAZkbmu69tCR41sdha7hWF9NM9DHAiOgdDknxljgKyHBcdKDOSsyzsU > Ow9fdjMlna45i0AoZ4YsFfGC8SFhnMrLGAu1f6RVlWIpt/avWtEdJ3VYCe7ZwYw8 > wtKHLMS3pSVrMNx3OuiQFykMs/TpBOGIdtR1AWqSRroE/SlxRtJWQjNt1yX24plZ > +MMASvIbi8wJPrxwCOiNI5EBg+3UFdcxnOvdt6Da0ElO22ucr9qiu2E246QCSyDT > j9jWAyRdxlevI1+O1OPqMO6LOGHL9pLw6FdsEKmpT49kWXYCIrxvSO25sq1ilIaH > 0IiTs0FkWUxMaiwS8owhX0KVNGPJgl0RdAzsTIMf28AjN16Ex1d/Z7tjUy3AKgxq > 7t6yaaot9sCIV2u5JD4DPnhG9pQ0gVPUTHbs/ImNA634Q/QK+mJTcFI+yweIaLCP > Rk5kECvk9UBS1wLUSy//EotQ7XMJOq0/Vadwh9vMGE36yJcgB9kUAAl7HMvxLZsC > ZgOiMqSNr5O8H0ulj1hqqaklR8xj1Dln9AVWsrh3gJP7NUiMrh0jnTWaHKGATDZ1 > 5wWiRTB5YqteRn7TW1R6+v/u9SHVriiQIvoL0ZtnZZzgZAsaJcGThPgWuyciB7ff > HIqsjtul3EFr9Fm2rhTiVAnW7E6HFq2buLrQixImImDyygtCI5/LXsQvsANVjg1m > qMZdBdOkc6Da6w0BXIgb14T1+O0uxnxAAxCDp93xmv/tsthW2mtYhESECTV93ph1 > pk+JegBEN37ivX5054tIVJfD+aVkDXXnN2KM/GhqzOdGJEhZHcWFqQ7RNCiTk9n5 > T/hF1FNcrf1mBIuM8U+tpyslhU4tOuHj4MTrbNA+zVNUHI0yhekLW89WwoIsDGCV > boA6B5qirvM+PZOniXyzFqUaEGGAEkIizt9UFvaJ50sn9OcVxTeirHQPrkjVPGWh > MXk8eBNzDmnO+/kWFLc9oOLmUiOmQDhboOtiHYMEaGNRxWw4i82XJi1fULSuj0s5 > YjdSnH+He5oawpnnR3CzkVOrJkXxJTEaKUhe0i0lrkYi5YTnsCkpz/dHC4n6dEyT > id1//eRfWqianNmyzbzkY89kUJu7XUn0iZPQhJgLCkx7JFLK2W/g4krgMkmQZc/L > C0gxWH5ZCJvutuZrDtFXFk9z3oxSEDyaxqSjVn5lxjHc28jrHLLDC0FZWNklrOWl > dK9Hjhh8aBWwsjcjKs71ibRs05Fmg6dxgR0K6UZm872WGgHUEwR1co4B9ArP1qVd > U64v3Izm8ojVM4tgFx3z4QFyitoaNhkdlf+Q+rdUaIgoQHLl+9orISFZrItLwCKn > gXtPrHwNRVcHs6hM9mxNjONufRhRMZUBpaeHhrNLMV9Coy9LROHFYbr0mT8+oyIh > 7PrAlDQE6nuaC11NVlkh22bCRyR1ExsJSQrbrsvsFePm3JMxMEcVSXSyxNZqLTkA > ueJtoW++RybT8VFe5w7DrPvKRVK5c23Ko081pBFfK2pWW5gYmnO61I1K+UOdZDET > uvoXfPQ66aB4LsEo7iTwc7tcko2SMbjBgIp1rXKSCHpJkH1WBdKcALZnDTnvPwp2 > mjpQlfy/OvHssjE+dNiWobHE8ymSzw1sOMAWNlEUCWNw0mGicO2XsnuG9AcN35oX > b5qpmqCNn83r9B5a+d5jKlJzHcIFSjHryrudHRgUY+VilxsoIzPKKpkhcqKrNA+N > GAl/tWA+oYBp/vhRQv0bqxMIYBSdrUKN52SNPIXmnDzAociBobnpcnr8zXEk7ITo > rQJObrYbMOh1meqDcNLt0+6gKhFwiGGQmuxAakR6NgfE9SKFciQXE1bDCF3/YaAA > 5V8YKA4Oe1z4AA5eRQiWJ7A1FbfJtxcl2ABcseyx2zHCPZv0a2zulqgyThhdMLNa > 6gbxg1nr2W6QlbYH43gU3eJrvunDBDTGpWBKwSBAnO15Pscia0CLWJ2P/j4hLyyU > 1nnswmdGaxluv/sSwwAR8OEWfj/lkQXrm1RPKyoFTifeFitmIOGtal2T3pf/NuR3 > lXE1u+z3T0LZPrZ7n3/k4xyKaD2H5vhtV8Dj+UhHbyqlxYE+E0s1JGhhSE8rbydx > +uFCk7MiQ4Y4QzUB+IomQDjK1U1FLKyTkFF6LihKXWbufvvDiGo8k61KsO5ebUAW > gAV9t0wGBD5oQHBa+92qyrkmK/5QIzXbUSRUpHpmM4geP6wiS/wRock4DT5Y8RFE > e8tlU365TbaYD+n1B87IZvggd6+i+tgszK6U7EslePOVOq+eJkgHtEHwqXMsC9BY > +mMjGK9IgDSl8o3eYR2aCC2ZPRc7FXCvkQyGoBvmbjKZC30JwrfRSnbhz8JeLO/2 > 9yBHGS+YDmLkzV2yr8d8u5AD0NI3bhDYvH6T0P3PK6rV27ITi7Pp6rzWRJDag2MO > cObv4YfGbopQ4j02NNy7KBq2xlcApPFvudCdHcVBdeKjaRBWvPei94Oy7/B8xazN > jZDcMuOogNEaE+zGbjSlnhp4P1lHILY7NcgoFzgF9bhb46k6RZRXnt/mlzYpNMAw > o3Ch6yJJNIQQx8c0Kka11ZPD4qVUCw8M85cFPVqhTOHQyao6q12exbT7WsZExzQn > AnOjHffkChpECDyhGcFlRkS20t9kgTxoaD/1z22i8jFZOX3BoHaRSJM0FxC620JE > cYxm7w3V1z9k1e4SfriI1rbLFZywYHyCglnV45pe4wkzRvw7OGdwtHYx56351m5j > GX5Ls+J1KHrZQPH3Gb6iiZEXT/Hndhm/JRsQqxi6mgf3/zBwZyqnC8nenRjIwKhN > x8eDG3jldBEFAjg1je4BQ1KoSKtqrRNPwg2FRW9D9ozGIxLn9cgjLyRWBwH3+J/P > v6OLiqpcufeTr3nABb58y51qpiXT65lpFLnsw5Wj9vX2nkneDB88l54ZmrH6e6Z1 > pSloilRAhzdWoXksUCSdxNXL7cH0ps0yGF9GWmUP3BaFv0q2YuV4Cfq3RF6zXO4e > /ANPVO3j/pl4rk8cmKOJHWPBMgV5pkdUt29I/dcCSI/z9yZlYJZ7PSac0Tn3kyg7 > 23/IYhTSPx4JIq+VqT4sgOIdPjxBpJqKX7BMGQqecynonS+isIwgbSP/J2cNUhp0 > 0N7VDfei4kVjU4sJaOdNi1zO4/nLk+rfZiyR1WP3o59b35JoKq3Vdln2Jubt7PMW > B6Ilmu6xVZj2QfhL1zGvY2C55uBcuqiIpKvmdgR8WAsvmtSPxSLE2ScanXUD1At0 > 2ej4+gr7K16pWLwLIcQ40B4BurxsZI+80kfUnx/LZjRLzc9Cdtw6b1VVhPp3qn9g > yv352SccnDbP3yzcprJuSWQbHd9BeGcoHJsy5rKtdS5LiAuRGZ02EJ3RAJAwUMwK > k430fYjY3ZX6giwKkpHunB9z59PQiGtI8s4OA0sEK+MuHWp8htbBP5kJddsP4k1G > VFUQDcvsvjWQoJnCVEbvE7kPYf00AeRLGm7vM7TQTdDkoRfCii35G5wYS1dVY3nc > luEu3b8aNwjXwH9Bh0aLXQIQVjvdpvr0/zUJ5hAi/YyZnYVqIsWkbWo8/i8Pw9jb > BdElQ9yU9RIYDPrqBSKi5gLoOts7YYnZbWLAKWylm5Hbn6imJ/qbhPi7Buy0h5dA > S/68ux55oW7FXc+rEfpjf0zBsrvxmT0SDu40S3l25SMUEO4A8oCB2sJgXafWE2Ea > RssohLtRar4x8VCFpcGPbNio2muTT9VwaQG9KHygOfH3i69VcuC6db18uah0b80O > WrXMeqK5M88JwjfJKe36kqPvLZD5llPeM7Sqj0wxUaKmnPW6ClXHm+mYeP+21BIY > AOtDh1Lxg3R+rob8J/OtA3U9TtHT4aSnafRNrxDT5sm3PKx8ajnR3fe0jLo4mgdi > Z1sLLK1wh9j21R4hy6XvrIOFCDqpbSR6KDCerYJyo371kd1mkpJKwdlsBIl5G4bN > Q6nbNKsVWpHTdF24zHNh+GZgiY4Q98HcSp2PeFa4vetVlYmV48Uf8tncEukox0pK > XIpWrirDXI+90zyVAwhKtjbNlC2a > =TKgw > -----END PGP MESSAGE----- > > ------------------------------------------------------------------------------ > Include everthing between the ------------------------------- and you will get > the pictures in your mail box. > > -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMPayLeVevBgtmhnpAQGKxgL9H4WsKLnIJAXGm5s1XPwWkRKsTHj2Ewhm sPVDYt697wflpqXy69oL4k8Jk/GUswuPcbO6/3zyeUGetm1hkVxrVCJSlW5sapQV tIT2MSZi1uz3Wwfn52uajm0d7ebF9bx3 =yoZx -----END PGP SIGNATURE-----

8 11

The cost of victory?
by Marc J. Wohler 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Anyone care to estimate the *true cost* to PRZ for this victory? Haven't the bad guys made their point? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMPWtdGeikzgqLB7pAQHGfAQAifBSfY7fSLccdhpdWnNSW/prMdKyPaRF XqEHfc9L+g2rYggYxWFXAZYBef2UjX8sQV6IZG7YN4wIT2IlifYa9GO0xVXC5LiC Diu0GPgXD6mg2WInfhzedCQNOfby+LF+oEo04whvz1dkMjo8ntEsczjY82VRYBh1 wUmdZyBsVNE= =RHPc -----END PGP SIGNATURE----- ***Preserve, Protect and Defend the private use of Strong Crypto*** * * * PGP for the masses * * * Finger mjwohler(a)netcom.com for Marc Wohler's public key fingerprint= F1 70 23 13 91 B5 10 63 0F CF 33 AD BE E6 7B B6

1 0

Re: BIG NEWS: PRZ investigation dropped!
by James A. Donald 17 Dec '03

17 Dec '03

>From: Stanton McCandlish <mech(a)eff.org> >Date: Thu, 11 Jan 1996 11:53:46 -0800 (PST) > >Justice Dept. dropped investigation of Phil Zimmermann, declines to >prosecute. I never expected them to prosecute, unless he forced them to by toilet bombing the court, but I did expect them to keep on "investigating" him forever and a day. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

2 1

No Subject
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

The other day I was poking around lists of open NNTP servers, and came across something odd at llyene.jpl.nasa.gov . It appears that nothing has ever been expired there. Some groups had hundreds of thousands of messages. This might be interesting and useful for some purposes. Anyone know if that's where Dave Hayes does his amazing administrative thing?

1 0

Re: Zimmermann case is dropped.
by Frank Stuart 17 Dec '03

17 Dec '03

Since there is no longer an ongoing investigation, perhaps now would be a good time to file FOIA requests to see if there is evidence of the Justice Department acting improperly. | (Douglas) Hofstadter's Law: Frank Stuart | It always takes longer than you expect, even fstuart(a)vetmed.auburn.edu | when you take into account Hofstadter's Law.

1 0

Re: E-cash and Interest
by loki＠obscura.com 17 Dec '03

17 Dec '03

At 2:52 PM 1/11/96, Ryan Lackey wrote: <SNIP> >By integrating all of these services under Mark Twain Bank Ecash Mint, I >would get all of the advantages of a rather pricey bank, 4-5% loss on all >my deposits, minimal privacy protection, no FDIC protection, $2500 ^^^^^ >initial deposit (not a problem for me, but it does keep many of the >people I'd like to send money to out of the system..always a feature), >and _tens_ of places to spend my ecash, only 4 or 5 of which that really >sell things. > Where do people keep getting this number. I have an account, my initial deposit was $36 ($11 for startup and $25 to play with). >-- >Ryan Lackey -*- ryan(a)pobox.com -*- http://www.netaxs.com/people/ryan/ -Lance ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

2 1

Re:NSA
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMPVGgyoZzwIn1bdtAQG/1wGAwFELRklL0jv58QWSXMg8Z+OUNPX1OtXJ UaI51iIBh2IjH1hggHtyMUi1B6xrlbmo =h/+n -----END PGP SIGNATURE-----

1 0

Re: Domains, InterNIC, and PGP (and physical locations of hosts, to boot)
by tim＠dierks.org 17 Dec '03

17 Dec '03

At 3:00 AM 1/10/96, Bill Stewart wrote: >At 11:15 PM 1/6/96 -0500, Michael Handler <grendel(a)netaxs.com> wrote: >> ftp://ds.internic.net/rfc/rfc1876.txt >>Again, I'm not too sure of the viability of this proposal. Not on >>effectiveness of proving true location -- it is more geared toward >>"visual 3-D packet tracing" -- but simply because I have _no_ fricking >>idea where our machines are (in terms of lat and long) to any degree >>of accuracy. > >There are several geography servers on the net, which can tell you >the lat/long for a city (more useful if your city is, say, >Holmdel NJ than if it's Los Angeles.) For what it's worth, you can use the mapping software at <http://tiger.census.gov> to find your location fairly accurately; you may need another map to locate yourself, since the streets are unlabeled. I managed to figure out that I'm currently at latitude 37.3435 degrees, longitude -121.8925 degrees. I think that's correct to within about 100 feet or so. - Tim Anyone with a GPS device, feel free to stop by; I'm in unit A2, and I've got homebrew in the fridge. Tim Dierks - Software Haruspex - tim(a)dierks.org If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

1 0

Reliance Limits Considered Harmful
by Jueneman＠gte.com 17 Dec '03

17 Dec '03

>Suppose I am a CA. I am worried that by issuing a certificate with a >lifespan of more than 2 milliseconds I am opening myself up to unlimited >liability if for some reason, despite my best efforts, I issue an >erroneous certificate. > >I know I can write disclaimers, but that's not reliable since courts >often ignore them, and anyway it scares off customers. > >I know I can put an expiration date on the certificate, but that's not >enough. I can accumulate a lot of exposure in a few seconds, much less >weeks. > >I know I can put a reliance limit in the X.509 ver 3 certificate, but >that's not enough. Even a $1 limit could be used many millions of times. > >Is it feasabile to say: Can only be relied on once per day/week/month? >Is this something the relying parties can reasonably be expected to monitor? > >It seems to me that this sort of a limit is essential if a CA is to feel >comfortable outside Utah.... > >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 | It's warm here. > I have been troubled from the first with the concept of a reliance limit, in particular because of the problem Prof. Froomkin cites. In the "normal" paradigm for digital signatures, neither the CA nor the relying party(ies) have any knowledge of how many times that particular certificate/key has been used. As a result, there are few if any controls that would operate to enforce the notion of a reliance limit. Even in the electronic credit card environment where there is some sort of a closed loop system (the purchases are reported back to the Issuing Bank, and presumably would be or could be known by the CA, which is probably acting as an agent of the bank), there are some substantial problems. The first problem is one of privacy. If I have a very high credit limit, I certainly don't want to advertise that fact in a public certificate. On the other hand, if I have a low limit, I don't want to advertise that either. And in any case, the reliance limit is not intended to be a "floor limit", i.e., an amount below which it is not required to contact the credit card company for authrotization. (Floor limits used to be popular, especially in Europe where the cost of telecommuncations was high. But now almost all transactions are authorized against the customer's current balance and credit limit, and if the merchant doesn't check he can be stuck with the charge if the customer doesn't pay.) I have argued (quite unsuccessfully in the credit card community) that the reliance limit can provide a useful means of limiting the subscriber's exposure (as well as the CA's) in the event of a security compromise affecting the subscriber's private key. Since there are no perfect computer security solutions available at any price, much less an affordable price, both the subscriber and the CA have to make a tradeoff between their risks and the rewards of greater convenience, etc. I tried to get around the privacy issue in the credit card environment by treating a negative reliance limit as a percentage of the customer credit limit. But no one in the credit card industry was convinced, and maybe I'm not either. The concept of a reliance limit is enshrined in the Utah Digital Signature statute (and the ABA draft Digital Signature Guidelines), where it is wrapped up with a draconian requirement that registered CAs have to put up a surety bond or irrevocable letter or credit in the amount of 30% of the aggregate of all outstanding reliance limits. This is not just an insurance policy -- a CA's corporate assets are pledged to back up the certificates issued, not withstanding the fact that the identification system we have in this country is not sufficiently reliable to warrant such representations. And surely no CA is going to hire private investigators to check out who someone claims to be with sufficient credibility as to be able to issue certificates to individuals -- at least if they intend to charge any kind of a reasonable price for the certificates. In my personal opinion, that requirement in the Utah law makes it highly unlikely that anyone will ever become a registered CA in Utah, unless the reliance limit is set to $1 and/or the expiration period to about 1 millisecond. (Maybe the Utah statute was really trying to set up a lottery, rather than a system for registering CAs. Everyone gets to play, and if you can find a person who has invalid credentials, even if issued through an innocuous clerical error (someone misspelled the street name in someone's address), you can claim you were harmed in some way, sue them big time and collect millions. That's the American way, isn't it? :-) Although X.509 v3 provides a simple mechanism to allow additional attributes, potentially including a reliance limit, to be included in the certificate, there are at present no plans that I know of for any existing CA to actually do so, or more importantly, for anyone else's software to be able to read and comprehend those reliance limits or perform any checking. As a purely technical matter, the problem could be solved by requiring the relying party to validate the transaction (not just the certificate) with the CA in real time. (Checking a CRL database isn't good enough.) By providing a transaction amount, the CA could keep track of the extent of its liability, and could detect misuse. Alternatively, the subscriber could request a new certificate for each one time use. However, both of these "solutions" would require a significant extension to the current mechanisms, and also give rise to a number of privacy issues. In addition, there are other practical problems. If I am the relying party (or the CA), and the subscriber is using his digital signature to confirm an order to sell futures on the commodities market, how can I evaluate the potential risk? If the subscriber is selling futures for orange juice and a storm wipes out all of the orange trees, his losses could be unbounded. Similar situations could exist in the case of a signature on a patent claim, and creative people can probably think of many more cases. Although the notion of a reliance limit usually arises in conjunction with digital signatures, it would presumably apply to certificates used for message encryption, to set up encrypted sessions, etc., as well. This puts the CA in an even more difficult position, for now we are not talking about a (single) financial transaction. If I send an encrypted message to someone, and it turns out that the person who received it was not who he claimed be, I may in fact be greatly harmed. (If the message wasn't important, why would I have encrypted it in the first place. Suits for violation of privacy have resulted in millions of dollars in damages -- does that mean that the CA ought to provide a million dollar reliance limit? My conclusion after having thought about this a lot is that reliance limits are at best ineffective and at worst positively harmful. They are difficult or impossible to enforce in any meaningful way, they raise substantial privacy issues, and at least as codified in the Utah Act and the draft Digital Signature Guidelines they will almost surely act to dissuade any prudent business from setting up a licensed CA. Does this mean that the subscriber, relying party, and CA all have effectively unbounded liability, absent a stated reliance limit? No, I don't think so, but we may have to change our paradigm a little bit. Most people accept a driver's license as providing a degree of proof of someone's identity, but very few would consider it proof positive. Since the state-issued driver's license is the only practical means of identication available to a CA in the case of private individuals, that consitutes the weakest link in the system and is quite likely to remain so. The only other identification document I am aware of that is available to private individuals that provides substantially better identification than a driver's license is a permit to carry a concealed weapon. Here in Massachusetts, obtaining a pistol permit requires a trip to the local police station, where you are photographed, fingerprinted, and two or more affidavits concerning your character are reviewed prior to submitting your fingerprints and picture to the FBI, where a search of the NCIC database is used to determine if you have any prior arrests, etc. The permit card that is issued carries your residence or business address, your picture, fingerprint, date and place of birth, height, weight, complexion, hair color, eye color, and occupation. Since the Brady Bill was passed, I believe that many states have set up similar systems. (Of course many jurisdictions sharply limit who can actually receive a weapons permit. I'm only describing the process, not debating the reasonableness or unreasonableness of gun controls.) Even if state laws were amended to make this degree of identification assurance available for purposes other than weapons permits, many if not most people would have strong reservations about the privacy implications. And to the best of my knowledge, private companies are not allowed to access the NCIC, also for privacy reasons. Does all this mean that digital signatures are worthless? No, not at all. But it does mean that they are unlikely to convey a degree of surety as to someone's identity that is very much stronger than a driver's license identification. In my personal opinion, I think we need to establish a stronger degree of "no fault" protection for CAs that follow the rules. Whose rules are to be followed, and who audits them for conformance are valid issues. We clearly don't want irresponsible CAs issuing certificates to all and sundry, but we can't make the cost of entry into the business so high that no one takes on the burden of being a CA at all. The issue is how to balance risks, the costs, and the rewards equitably between the subscriber, the relying party, and the CA. In the case of the credit/debit card industry, the credit card companies charge a fee that covers both the risk and their administrative costs. If digital signatures can be used to reduce their risks, presumably the fees charged to the merchants can be reduced somewhat. But in any case, the fee that is charged is proportional to the amount of the transaction, and therefore statistically covers the risk. The real question is what to do outside of the credit card industry, where certificates may be used for transactions are much more complex, and where there may not be the infrastructure to collect a percentage fee for each use. Please copy me directly on any replies, as (to the best of my knowledge) I am not a subscriber to cypherpunks. Bob ---------------------------- Robert R. Jueneman GTE Laboratories 1-617-466-2820 "The opinions expressed are my own, and may or may not reflect the official position of GTE, if any."

1 0