December 2003 - cypherpunks-legacy

Re: Certificate proposal & X509 clarifications
by baldwin 17 Dec '03

17 Dec '03

The Distinguished Name of X509 is NOT intended to be the unique identifier of a person or a public key. In the X509 world two different DNs can have the same public key, and a single DN can have multiple certificates with possibly different public keys. The same public key naturally appears in multiple certificates when each certificate is only valid for a certain period of time (e.g., weekly certificates have been proposed for applications that do not want to implement revocation lists). The unique identifier in an X509 certificate is the DN of the issuer and the serial number that the issuer attached to the certificate. Both of these fields appear in the version 1 X509 certificate. Of course, this assumes that issuers are following the rule of not issuing two certificates with the same serial number. The designers of version 1 of the X509 certificate format have realized that they need to allow issuers to attach all kinds of different attributes to a public key. This lead to version 3 of the X509 format, which provides for general extensions. Of course, this means that there is more rope to hang yourself with when it comes to designing an overall system, but with careful design, lots of good things can be done. For example, for the S/MIME secure mail effort, the certificates include the email address of the owner, as certified by the company that is providing the email post office (e.g., the employer or service provider). Note that Netscape Navigator 2.x will support Version 3 X509 certificates and S/MIME. Question: what's a good way to have the existing PGP public key infrastructure interoperate with the X509 infrastructure? --Bob

2 1

Crypto APIs
by Matt Blaze 17 Dec '03

17 Dec '03

A couple of weeks ago I attended a meeting at the NATO SHAPE Technical Center in the Hague to discuss international cryptographic APIs. Several high-ranking NSA types were there, as well as their counterparts from various NATO countries plus a handful of industry crypto people (like me). The idea of the meeting was to find a way to separate cryptographic function from cryptographic interfaces, in a way that allows the applications that call the cryptographic functions to be more freely exported. That is, I can write and export an application that calls the crypto API but that doesn't actually implement the cryptography, and then, when it reaches its destination, the locally-preferred cryptosystem can be plugged right in. Crypto might be implemented in hardware (e.g., Fortezza) or software (e.g., with a shared library or pseudo-device driver). Obviously, this idea is somewhat (completely?) at odds with the criteria presented at last month's NIST workshops for exportable software key escrow systems. One of the requirements given for such systems is that it be difficult to replace the crypto with something that doesn't implement key escrow. But who ever said the government was consistent? Interestingly, it was clear that many people in NSA believe that applications that call an API are controlled under ITAR, but there is some recognition that this may be wishful thinking or may change soon. So while some (maybe most) of NSA wants to prevent development of standard APIs and prevent the export of applications that use them, others recognize that these will evolve by themselves anyway and will be very hard to control once they do. Anyway, the situation is far from clear. It seems best to encourage the realistic side of NSA as much as possible... I learned a few interesting things at the meeting. First of all, overwhelmingly, there is recognition, especially on the part of the non-US government security agencies, that there is enormous value in being able to buy off-the-shelf applications like Microsoft Word or Netscape Navigator and just plugging in the local military cryptosystem and using it for classified traffic. Everyone seemed to agree that there is a growing need for this and that it's too expensive to rely on custom software. There is also movement away from the traditional military ``link encryption'' approach that involves centrally- controlled secure networks in favor of a ``risk management'' approach that favors end-to-end security with off-the-shelf products. In other words, the parts of the military that are concerned with actually securing communications want exactly what we want, and are just starting to realize it. While lots of us have always known this, I had never heard it articulated as quite clearly (or as loudly) by actual comsec/infosec people before. Second, the senior NSA guy mentioned a few things I hadn't heard before. Fortezza is now approved for classified traffic through the SECRET level. Also, the ``type 1'' (classified) through ``type 4'' (unevaluated) cryptography standard is being scrapped in favor of a three ``tier'' system, as follows (these are approximate quotes, from my rough notes): Tier 1 traffic is stuff related to ``national command authority''. (Seems to be secret and top secret and up). It will require NSA cryptosystems, hardware implementation, and will NOT employ key escrow (because of the ``obvious risks''!). Tier 2 traffic is information that, if disclosed, would have ``national implications'' if revealed. Examples given include things like the national power grid, the banking system, etc. It was unclear whether any classified traffic would be included in tier 2. Clearly, some of what is now called ``sensitive but unclassified'' (SBU) will be in tier 2. Anyway, tier 2 systems will be approved by NIST (not NSA, although there will obviously be NSA input into the standards) and will require hardware implementation. Tier 2 traffic will be escrowed, and the government will escrow its own keys. Fortezza is an example tier 2 device (but read on...) Tier 3 traffic will be that which would have ``private implications'' if disclosed. Examples given included personal financial and medical records, etc. Current SBU traffic not in tier 2. Tier 3 would also be handled by NIST, employ commercial or government key escrow (like tier 2) and would be permitted to be implemented in software. Here's the surprise: Tiers 2 and 3 will be interoperable. So there will be published algorithms for tier 3. It is possible that tiers 2 and 3 will have the same algorithms, and that the government will suggest them. It was unclear with interoperability will require that all tier 2 algorithms will be published and implementable in tier 3 software or whether this means that tier 2 devices will also have to implement the tier 3 algorithms. There is an obvious choice of a tier 2/3 algorithm: Skipjack (although there were concerns that this is ``too slow''). So we may eventually find out whether ``S1'' was really Skipjack after all.... -matt

2 2

Re: worldwide announce: New OTP Mail/FTP apps
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >From: Doug Hughes <Doug.Hughes(a)eng.auburn.edu> >Date: Thu, 28 Sep 1995 19:31:00 -0500 >A company in Israel named Elementrix has just announce at Interop an >entirely new paradigm in secure transactions. They have a secure >one time pad that allows people to exchange mail and ftp files back >in forth in complete security without the worries of key management >or storage or secure random number generation or synchronization. As far as I could tell from your description, this is an autokey cipher -- not a OTP. An autokey cipher starts with a shared secret key and uses previous plaintext or ciphertext as part of the key. DES CBC is an autokey cipher. The original autokey used previous plaintext or ciphertext as the only key. More modern ones mix in the previous text. I had a design for one, several years ago, which kept a mapping in memory and changed the mapping based on incoming plaintext. Therefore, there is state information kept at both sides which keeps changing. One might think that if the attacker never gets in, today's randomness is just as good as yesterday's. That might even be true. However, there are many openings for finding relationships between yesterday's and today's ciphertexts. I look forward to seeing the actual algorithm. - 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 iQCVAwUBMHBTU1QXJENzYr45AQHRigP/Yqw0T3n2SDubgRZIrKx8WpUSJtmBwcuf nIBxxwsOwu10sQti7hw3Zcj9tRM6JAcqFNh1U2LbYT3u7ELgh2Hicq0jLcr+3r4h B0H3LlbU9iv7WlETQF8Tw2KQcfDKLkYkeMRnS27cKnJIFHK9w0g4UTwabfB+m5SV sjnUZbv6Q1A= =P9X7 -----END PGP SIGNATURE-----

1 0

Re: The Free Speech Implications of Remailers
by James Caldwell 17 Dec '03

17 Dec '03

On 1 Oct 95 at 22:32, Timothy C. May wrote: > Crypto anarchy means the racists, sexists, speciesists, and other > "ists" cannot be muzzled. I call this a good thing. It's why I'm > here. I don't mind the mail, it's in a bit bucket, just the cowardly nature of it. It was not sent anonymously which can be filtered. I appologize for spamming the list in response to hi message, it upset me.

1 0

Re: The Free Speech Implications of Remailers
by Lynne L. Harrison 17 Dec '03

17 Dec '03

At 10:32 PM 10/1/95 -0700, Tim May wrote: <snip> >Well, guess what? The very technologies we have been so central in >deploying are the technologies that make _conventional_ means of >controlling distasteful material so hard. >system of the various mail delivery systems.) <snip> >Crypto anarchy means the racists, sexists, speciesists, and other "ists" >cannot be muzzled. I call this a good thing. It's why I'm here. Excellent analysis. One can't argue with logic, nor should one forget the purpose and spirit of this list. The fact that spamming is in poor taste is irrefutable. However, some of the "where did this come from"? responses are starting to sound like some people are suddenly against the use of anonymous remailers. I, for one, would hope that people are simply rising to the challenge of tracing the routers. Kill the message if you are so moved -- not the technological messenger. ******************************************************************** Lynne L. Harrison, Esq. Poughkeepsie, New York lharrison(a)mhv.net "Say not, 'I have found the truth', but rather, 'I have found a truth.'" - Kahlil Gibran from "The Prophet" ********************************************************************

1 0

Re: NetScape's dependence upon RSA down for the count!
by David_A Wagner 17 Dec '03

17 Dec '03

In article <9509301910.AA10970(a)dmsd.com> you write: > > The "messenger attack" as described in my earlier posts regarding > public key encryption and key management seems to apply to NetScape's SSL. > I have a Fifty dollar bill for the first person to submit to the mail box > nethack(a)dmsd.com a working Unix server (with cleartext session logs) which > accepts all connections on a unix based host to the www port and redirects > them to netscape.com leaving a clear text log of each session's SSL packets > in /tmp by session. All entries become the property of DMS Design. The winner > and I will submit a claim for one of Community COnneXion's "I HACKED NETSCAPE" > tee shirts as a server hack. (Have Fun!!) > This is a trivial program! I can't believe anyone considers this technically difficult. But hey, who am I to question, if you'll pay $50! Ok, let me back that up with real code. Here's a proxy I've been using for experimenting, in lieu of root access & tcpdump. Usage: proxy localport remotehost remoteport > capturefile Try: $ ./proxy 2999 www.netscape.com 80 > capturefile & $ netscape http://localhost:2999/home/welcome.html & or $ ./proxy 3999 alpha.mkn.co.uk 443 > capturefile & $ netscape https://localhost:3999/ & Here's the source. It's a bit unstable, and could be a improved a little, but was fine for a quick kludge. So feel free send the $50 to the following address at your convenience!! :-) David Wagner UC Berkeley 330 Soda Hall Berkeley, CA 94720 #include <stdio.h> #include <sys/types.h> #include <sys/param.h> #include <sys/socket.h> #include <sys/time.h> #include <netinet/in.h> #include <netdb.h> #include <ctype.h> /* dump bytes, sorta similar to tcpdump's style */ dump(char *p, int len) { int i, j; while (len > 0) { for (i=0; i<16 && i < len; i++) { printf("%2.2x", (unsigned char) p[i]); if (i & 1) printf(" "); } j = i; for (; i<16; i++) { printf(" "); if (i & 1) printf(" "); } printf(" # "); for (i=0; i<j; i++) printf("%c", (isprint(p[i])) ? p[i] : '.'); printf("\n"); len -= j; p += j; } printf("\n"); } /* copy one message; guaranteed not to block */ int fromto(int from, int to) { static char buf[2048]; int len; len = read(from, buf, sizeof(buf)); switch(len) { case 0: return(0); /* EOF */ case -1: perror("read"); exit(1); } dump(buf, len); return(write(to, buf, len)); } /* kludge to deal with select fd_set * parameters weirdness */ /* #define FSC(x) ((fd_set *) x) */ #define FSC(x) ((int *) x) /* repeatedly copy both ways */ proxy(int xfd, int yfd) { fd_set fs; char buffer[2048]; int done = 0; while (!done) { FD_ZERO(&fs); FD_SET(xfd, &fs); FD_SET(yfd, &fs); if (select(64, FSC(&fs), FSC(0), FSC(0), (struct timeval *) 0) == -1) { perror("select"); exit(1); } if (FD_ISSET(xfd, &fs)) if (fromto(xfd, yfd) <= 0) done = 1; if (FD_ISSET(yfd, &fs)) if (fromto(yfd, xfd) <= 0) done = 1; } } int remoteinit(char *addr, int port) { struct sockaddr_in si; int fd; struct hostent *hp; char hostname[MAXHOSTNAMELEN]; memset(&si, 0, sizeof(struct sockaddr_in)); si.sin_family = AF_INET; si.sin_addr.s_addr = inet_addr(addr); si.sin_port = port; if (si.sin_addr.s_addr == -1) hp = gethostbyname(addr); else hp = gethostbyaddr((char *)&si.sin_addr.s_addr, sizeof(struct sockaddr_in), AF_INET); if (hp == NULL) { fprintf(stderr, "unknown host %s\n", addr); exit(1); } si.sin_family = hp->h_addrtype; memcpy(&(si.sin_addr), hp->h_addr, hp->h_length); strncpy(hostname, hp->h_name, MAXHOSTNAMELEN-1); if (si.sin_family == AF_INET) printf("Connecting to %s (%s)\n", hostname, inet_ntoa(*(struct in_addr *)&si.sin_addr.s_addr)); else printf("Connecting to %s\n", hostname); if ((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(1); } if (connect(fd, &si, sizeof(si)) < 0) { perror("connect"); exit(1); } return(fd); } int localinit(int port) { struct sockaddr_in thissock; int s, i; if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(1); } memset((char *)&thissock, 0, sizeof(struct sockaddr_in)); thissock.sin_family = AF_INET; thissock.sin_port = port; thissock.sin_addr.s_addr = htonl(INADDR_ANY); i = 1; setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char *)&i, sizeof(int)); if (bind(s, (struct sockaddr *)&thissock, sizeof(struct sockaddr_in)) < 0) { perror("bind"); exit(1); } if (listen(s, 5) < 0) { perror("listen"); exit(1); } return(s); } usage() { fprintf(stderr, "Usage: proxy localport remotehost remoteport\n"); exit(1); } int main(int argc, char **argv) { int partialxfd, xfd, yfd, i, localport, remoteport; struct sockaddr_in thatsock; char *remotehost; if (argc != 4) usage(); localport = atoi(argv[1]); remotehost = argv[2]; remoteport = atoi(argv[3]); if (localport < 1024 || remoteport <= 0) usage(); partialxfd = localinit(localport); for (;;) { i = sizeof(struct sockaddr_in); if ((xfd = accept(partialxfd, (struct sockaddr *)&thatsock, &i)) < 0) { perror("accept"); exit(1); } yfd = remoteinit(remotehost, remoteport); proxy(xfd, yfd); } }

1 0

Re: Certificate proposal
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:53 AM 10/2/95 EDT, Carl Ellison <cme(a)TIS.COM> wrote: >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.] I agree with you about hierarchies, and even RFC1422 doesn't really force you to use hierarchy, much less a government-enforced one, though it clearly prefers it, and it definitely does support the concept of having a key signed by more than one CA, at least for CA's keys. The most important differences, from my perspective, are 1) X.509 explicitly addresses Certificate Revocation Lists, though it isn't real precise about how they should be distributed, and the hierarchical approach isn't necessarily the best. (Maybe put the location of the preferred CRL for a key certificate in the cert itself?) 2) X.509 certificates, unlike PGP, only support once signer per certificate; this is a slight hierarchical bias, which forces you to haul around a pile of certificates to have multiply signed keys, without specifying a syntax, so simple key-cert programs may not know what to do with multiples, and hence force hierarchy; the rest of us will just have to deal with multiply syntaxes. But that's mainly a verbosity problem, duplicating Distinguished Names and key info. 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? >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. [.... use the public key instead ....] >What remains is a need for attributes to be bound to a key. ... >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. Eventually, there may be a way to represent most of the attributes you want to describe in some format, which I dare say will look _far_ uglier than ASN.1 :-) Binding a key to a text-string usually representing a person does give you the slack to use other mechanisms rather than wait for the release of /standard-name="Attribute Semantics Notation"/version=32769/ORG="International Slowness Organization"/Country=none/reliability=ExtremelyHighTrustUsThisTime/versionh istory= For now, there do seem to be some kinds of attributes that would benefit from better representations than a human-name plus free-form text, such as "which application does the user want you to use this key for?" "how much should I trust the user's desire to have me use that key for that application?" "how do I get this key's owner to give me money?" "does the key-holder have the authority to speak for a given organization/human/bank account?" If you look at Verisign's DNs, or the text in my PGP keys, you'll see various ugly attempts at this. And then there's "WHICH person named Bill Stewart does this key belong to?" For the latter, I'm interested in solutions other than "Social Security Number", "Citizen-Unit Nationalized ID Card Number", etc. #--- # 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

Re: Netscape finally issuing md5sums/pgp signed binaries ? (was Re: NetScape's dependence upon RSA down for the count!)
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > I've been thinking about this recently for obvious reasons. My concern > is that if someone can attack your download of netscape, they could also > attack your download of the program that validates netscape. Is there > really any way out of this one? > > --Jeff I remember sometime in the last couple of years seeing a cert advisory that said that people's checksumming programs were being replaced by ones that did the normal checksumming except on compromised programs. This was part of one particular attack as I remember. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: `Hack Microsoft' challenge is NYT Computer News Daily's top story
by MIGUELDIAZ＠megaweb.com 17 Dec '03

17 Dec '03

>Date: Mon, 02 Oct 1995 10:34:32 -0400 >From: Rick Busdiecker <rfb(a)lehman.com> >Sender: owner-cypherpunks(a)toad.com >To: cypherpunks(a)toad.com >bcc: Lehman Brothers Inc. >Subject: `Hack Microsoft' challenge is NYT Computer News > Daily's top story > >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. > > . . . > I don't know about everyone else, but a T-shirt seems a very small reward for uncovering a "hole" in the encryption algorithm of Microsoft products. Does that apply to any and all bugs?? i.e. not necessarily security problems??

3 2

Re: NetScape's dependence upon RSA down for the count!
by jbass＠dmsd.com 17 Dec '03

17 Dec '03

> The point to attacking SSL is to be able to decode a message from any > browser, without having to do anything extraordinary to the victim's host. > No cryptosystem is proof against an attacker who can see and > control everything you do on the client side (i.e. has root in UNIX > parlance). > > So, while your idea #1 might be interesting or fun to do as far as computer > security goes, it's not an attack on SSL. Agreed, within limits. Security as "Marketed" by NetScape goes far past just claiming SSL to be secure, including the use of NetScape client and servers as secure. With this expanded model, attacking NetScapes claim of security includes attacking the process and enviornment that they provide to endusers and info mall businesses. In this case electronicaly distributing clients in a hostile environment is a gross disregard for endusers security needs, traded off for ease of distribution. I probably should not have included virus attacks, and just focused upon the main problem ... unsecured network transmission of clients. As it stands, a third party with minimal trouble can compromise a very large number of NetScape clients and capture the dredit card data for those users who would otherwise expect their transactions to be secure. To take the ground that their product is secure in a secure environment is meaningless ... the product value they seem to offer is security in a non-secure environment - which I don't think is true, and I gather you might agree? > That points out the flaw in Netscape's authentication model that > others have already pointed out on this list. Admittedly, like Don > Stephenson just posted, there's not really a good way to distribute > and authenticate certificates until there's a ubiquitous global > CA chain. Again, we agree that this reflect negatively on NetScapes claims of security in an unsecure environment? As an aside, readers in private have suggested that a signature by Verilog as the CA my not be required, quoting that until receintly, NetScape signed their own certificates. This seems that the MITM can choose his own CA, possibly of his own design to sign false certificates. > Assume that the attacker Mallet is in the middle and has control of the http > stream. Alice clicks on 'open Widget order form' to order a Widget > and Mallet sends her browser a redirect pointing to his evil web server. > Alice doesn't notice that the hostname in the url has changed, or > if she does, she figures that the catalog people have arranged to > have Mallet's server host their 'secure' transactions (not an unreasonable > assumption). Mallet takes the order and pockets the money. > The hostname in the certificate (Mallet's) matches the hostname > in the URL (also Mallet's). Or Mallet places the order in Alice's name defering the chances of detection until enough cards numbers are aquired to make a run on the bank. There is tremendous value in forstalling the point of detection and the location of the MITM becoming known. If Alice get's her goods promptly she is much less likely to question the transaction. > Of course this isn't really an attack on SSL per se. It's an attack on > the certificate-granting policy- the CA gave a certificate to > an unscrupulous person (Mallet). But it is a clear attack on NetScape's advertised "security" for end users. Almost all sucessfull crooks/thieves have a front business to launder their money thru. In this case you can steal customers just by redirecting your competitor's DNS records to your server ... With a similar home page and ordering/catalog screens they might never notice the switch, certainly not first time customers. Gee nobody would probably own up to the occasional named failures that could also cause this. Somehow I don't think this is what endusers of info mall owners consider security. > > > Well of course, if the secret key of the server (or worse yet, certificate > > > authority) is compromised, all bets are off. That's true of just about any > > > protocol you can dream up. > > > > I'm not referring to the secret key of _the_ server; I'm referring to the > > secret key of _ANY_ server. In the limiting case, such a key can be > > obtained by buying one from the CA. > > Right. That's what I pointed out in an earlier message, although I > didn't elaborate on it. The security of Netscape browsers depends > on Verisign's policy in handing out server certificates. and on the physical security of the site plus it's network connections, the trustworthyness of it's internal staff and contractors, and it's ability to deliver service in the face of failures and disasters, both man made and natural. Security includes more than just crypto correctness, in this case it include denial of service attacks as well has physical site attacks. In this case I strongly suspect that bombing Verilog would shutdown net commerce for a while. Certainly it's employees are in a position to earn high six figures for the key algorithm or a copy of the key database. As for the policy, it has to include mom & pops and young business owners setting out to make their honest fortune on the net ... unfortunately this profile includes the evil side as well. I don't think restricting info mall business to the fortune 500 is that we have in mind here. As such, I don't think screening by the CA takes us very far at all. > Backing up for a minute, the same problem holds for those neeto > credit-card readers that Visa and MasterCharge give out to merchants. > The merchant can be a crook setting up a 'store-front' operation to charge > to bogus/stolen card numbers, or the employees can steal using the numbers > they get in the corse of doing business, etc. There are already > procedures in place for dealing with this sort of crime. I'm not > sure that tricking Verisign into giving out a certificate to a group > of crackers is really any different than tricking Visa into giving > a card reader to a group of theives. Volume greatly affect the risk factor. Giving a merchant number to a business means that only the number of people that can walk-in or phone in to that merchants store are at risk. Stolen cards are handled differently than stolen numbers. Stolen numbers are cross correlated by past purchase locations by store, and if possible by register location and employee. There is a strong pointer to the person(s) involved. Skimming card numbers off the net has the potential to cross vendors, geographic areas, and other determinates that would aid in locating the source of the tap. The number of card numbers exposed has the potential to be several orders of magnitude higher, and remain undetected for quite some time. The net offers the ability to place a large number of orders in a short period of time for very high valued merchandice for delivery to what would appear proper customers ... and using the UPS/FedX example picking off the proceeds in a centralized low security location. With another computer store front on the net, you turn the same hijacked goods into full value shipments in a few days ... and maybe coordinate the bogus orders and hijackings to meet your customers demands. Or for an economic terrorist create $100 million in bogus orders and deliveries to drive the system into failure. Gone are the days when sheer man-power limited your exposure. Gone are the days when a sturdy building, good doors and locks, and a security system backed by Well Fargo staff would protect your business. Security in our network context includes not only the protection of the individual consumer, but the info mall vendors and the future of the medium as a viable way to do business. NetScape I believe is working toward all three of these goals, I strongly disagree with the short cuts and risks they are taking to get there. John Bass

8 8