- cypherpunks-legacy - lists.cpunks.org

PolicyMaker & GAK compliance
by Adam Back 17 Dec '03

17 Dec '03

Hal Finney <hal(a)rain.org> writes: > Adam Back writes: > > I would be nice to see the topic of the recipient refusing email based > > on policies relating to third party access to messages in transit > > being addressed in the standard when and if PGP gets to that stage. > > > > [ecash processing] > > This is a good example of a possible future kind of key assertion. > Are you confident that you can decide which kinds of recipient refusal > are morally correct and which kinds are not? Not automatically, no, I doubt it would work. > Is it the role of the IETF and the Open-PGP process to make this > determination? I would say not. Rather, we should standardize data > structures and conventions which allow people to express those > conditions and assertions which are useful to them. Yes. I agree. > There are a whole range of possible assertions which you might object to: > > [examples of PolicyMaker style policies] > > You can take these case by case and decide for yourself whether each > one is acceptable or not by your own standards. But I don't think it's > going to be possible to come up with a set of objective rules which will > decide whether any given assertion is allowed. > > Fundamentally, you are asking to make it illegal for a key to request > encryption to an additional recipient. That's what it comes down to. > You want to forbid this class of assertions. Yes. I was getting carried away. It would be too complex, most likely. The thrust of your argument seems to be that there would be little use making pgp 5.5 non-GAK compliant, because PolicyMaker style statements will be so flexible that they will be GAK compliant anyway. So, when are PGP starting work on PolicyMaker? Is it intended to introduce this functionality in this first round standardisation? It seems to me that adding PolicyMaker functionality could take some considerable time due to the huge complexity of the task. Also, just because GAK compliance will become possible if and when PolicyMaker style extensions are implemented, doesn't mean that PGP can expect popular support for actually going ahead and implementing GAK compliancy in pgp5.5; nor can it expect to gain popular support for the uncharacteristic big brotherish mentality displayed by those working at PGP in implementing the SMTP policy enforcer behind closed doors to enforce other people to modify their behaviour to honour third parties GAK or CAK requests. I think the whole thing is a huge PR fluff up. I'm suprised that those at PGP were all able to agree to do it without arguments being expressed by employees, and without those arguments leaking out of the company (given the picture Jon Callas painted of strong privacy and freedom biases at PGP). If there had been open discussion of the product's design prior to development, this feed back could have been obtained earlier. I presume the PGP PR person (who ought to get the sack in my opinion) thought that a sudden press release of such marvelous new feature as PGP snoopware and a snoopware enforcer for third parties would go down well. It doesn't. The enforcer is rudely enforcing the companise opinions on people who have no connection with the companies snoopware policies. You should keep such matters within the company by using escrowed storage keys to acheive snoopware. For these reasons I still argue that we should: - add storage keys to the standard It's more secure to do this. That should be argument enough in itself. It also is much cleaner separating key functionality out into separate keys where those keys have vastly different recovery, life time, and security requirements. - use storage key escrow to implement PGP snoopware instead of burdening the OpenPGP standard with the stigma of GAK compliancy This method ties in with the use of storage keys. It is nearly as effective a snoopware design. It also isn't GAK compliant. It also doesn't result in cypherpunks shouting at you. - don't use the special sub-packet type to flag GAK compliancy I think the above shows that the neither the standard, nor PGP Inc needs the GAK compliant sub-packet, so scrap it, and save the argument up for the much more defensible position of a generalised PolicyMaker style key usage restriction assertions - scrap the controversial SMTP snoopware policy enforcement app Use storage key escrow to implement PGP snoopware instead of burdening the OpenPGP standard with the stigma of GAK compliancy It's difficult to get standards which don't reflect big brotherish aims when the good reputation of PGP Inc and Phil Zimmermann is apparently behind it. Something weird is going on at PGP headquarters. PRZ is also silent. Are all the people at PGP Inc in accord in thinking that the snoopware policy enforcer is a really cool pro-privacy app? Some of the usually more vocal PGPers have remained silent throughout the entire episode. Also as Tim note's the lack of a Zimmermann Telegram (tm) getting suspiciously overdue. Is he dragging his feet of snoopware and GAK compliancy? Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 0

new "communication key" semantics & PFS
by Adam Back 17 Dec '03

17 Dec '03

Now that we're considering (within the IETF OpenPGP standardisation framework) the prospect of having a separate communications key, and storage key, there are some aspects of communications keys which are currently less than ideal because of their current misuse to also function as storage keys. This argues for a new functionality to be given to communication only keys. This is all tied up with the idea of Perfect Forward Secrecy (PFS), which is basically the statement of the fact that communications keys are more sensitive than storage keys, because your attacker by definition has a copy of the encrypted communication. (You're sending over an open network where copying all traffic is a low cost exercise for a savvy system cracker, or spook, or industrial espionage). In contrast an attacker often will have to break into your premises to obtain the data protected by your storage keys. Another aditional vulnerability of communication keys is that the US government is very interested in obtaining copies of them via their "key escrow"/"key recovery"/GAK initiative. The strongest anti-GAK statement you can make is to use forward secrecy. I've raised this point before, but the meme doesn't seem to have penetrated yet. Hal Finney <hal(a)rain.org> wrote: > Adam mentioned the idea of forward secrecy in email communications. > I'm not sure how that would work technically, but it sounds like > an interesting possibility. It ties in quite well with what is in my view proper handling of communication keys. If we can break the tie with one key being used for both storage and communication, we can start to reflect in the protocol better security practice in the handling of communication keys. Forward secrecy is one way of looking at it. It doesn't have to be real interactive forward secrecy as you might get in an SSH session, or an SSL session, or some of the IPSEC standards, though these are other examples which could server as examples showing that forward secrecy is a good idea, for anyone who would like to argue against it. The basic principle is that you want to have communication keys which don't live for a long time. So one form of weak forward secrecy you could have would be to mark your El Gamal or RSA communications for much more frequent update, by giving it a short expiry date. Say once per week. Some people currently do this manually anyway. For example see Dave Wagner's web page (www.cs.berkeley.edu/~daw/) where he describes what he does with keys. (He has a long term signature only key which he uses to sign short lived "communication only" keys which he discards after expiry). What I am arguing for essentially is building this kind of improved communication key handling into the OpenPGP spec for keys marked as "communication only". In addition I think it would be nice to enable a new kind of communications key which is based on discrete log so that people who choose to use PGP protocols for more interactive email transfer protocols than SMTP can generate keys very quickly. I was originally thinking that this would have to be DH, but perhaps you can simulate DH PFS with El Gamal by securely wiping the private parameters of expired communications keys, and keeping the public modulus and g value. (This has similarities with the quick method in PGP5.x of generating El Gamal keys with precomputed shipped primes that you already have). The advantage being that you may be trying to generate keys frequently, so you may not want to wait for a full new 4096 bit El Gamal or 2048 bit RSA key generation, when you are not anticipating the sudden delay in sending messages. I was originally thinking it would be done by having a new DH key type (in addition to RSA, El Gamal, DSA). (Incidentally Hal, you may recognise in this the reason for some of my annoyance that PGP Inc is mislabelling El Gamal as "DH" -- with my earlier ideas on this proposal there would have been a _real_ DH. It also gets around objections to do with not being able to decide what DH keys are (as they are negotiated not randomly generated directly) which Hal raised as a reason why PFS (at least with DH) would disallow functionality where key capabilities are included in the public communications key encrypted packet, the last time this was discussed. Clearly you could work around this restriction if you had to -- just include the information in an extra packet encrypted with the contained key and some symmetric algoirthm for example, though this may limit algorithm choice at least for that packet). You can use PFS in an asynchronous "where possible" mode for non-interactive email transport situations. That is you would perhaps send new communications keys parameters with each message that defines in it's key sub-packet preferrences that it is capable of using communications only keys, and will be able to handle "recipients comms key as part of message". This might make sense where comms keys are being updated too quickly to burden a key server with, or where comms keys are not public (an aditional use for Hal's described no-export flag for signatures, but here applied to communications keys), but are specific to that communicating pair. (For paranoid people who are changing comms keys on each receipt, you would need to do this). As soon as one party has replied to a mail from the other, you can switch to forward secrecy. This would lead to emails such as "hi, can you reply to this message please". These are kind of similar to the "hi can you send me your public key" you get back from people when you haven't included your public key in your mail to them, and they don't have access to a keyserver. You can also then use this new "communications only" key setup to cope with fully interactive email delivery for systems using email transports other than standard SMTP. You should probably overlap sending communications keys if you aren't relying on keyservers due to frequency of key update, or for convenience for people without access to keyservers, so that the person sending you email is less likely to have no current communications key for you if you are using keys sent in the message. So towards the end of the month (if you had a policy of using communications only keys with monthly updates) replacing keys monthly start sending the next months communications key also, marked as not for use until it's starting date. (The use of very transient communications keys I think would imply a need for two communications keys: you'll need a long term communications key which is used for initial non-PFS mail in order to set up PFS.) With the separation of storage and communications keys all the architecture has much better security decisions: - We are able to treat communications with variable amounts of sensitivity, by giving different key expiry time periods to comms only keys. - We are also able to secure and escrow our long term data storage in mail box folders, or PGP encrypted files without having to live with a GAKware compliant implementation of snoopware. We can storage escrow keys appropriately without all the name calling and bad PR caused by enraged crypto anarchists, and crypto consultants. You _know_ it makes sense :-) Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 0

Re: FCPUNX:'Telco Terrorism' -- Wired on Baby Bells v. the Net
by James A. Donald 17 Dec '03

17 Dec '03

At 10:18 PM 8/1/97 +1000, Apache wrote: > I note with great interest an independent provider in New Zealand which > has a better competitive market situation in this area than Australia > (and a lot of other things I might add) offers a user account with up to > 500kbs satellite feed for $79 (NZ) /mnth flat plus installation of $79 > plus you must by the satellite dish ($699). I would assume you can't > resell bandwidth on this set up so the two are not directly comparable. The (comparatively) free market telecom system in New Zealand is due to a LEFT WING, pro liberty, government, that adopted a strategy "let us privatize first and let the free market sort out the chaos later" The equivalent in America is almost unimaginable. Here in America left means statist, left means big brother is in charge. The same is true, or used to be true when I was there, in Australia, though not to the extreme that it is true in America. --------------------------------------------------------------------- | 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

1 0

reuters crypto story (fwd)
by Lauren Amy Gelman 17 Dec '03

17 Dec '03

---------------------------------------------------------------------------- ---------------------------------------------------------------------------- Lauren Amy Gelman, USACM gelman(a)acm.org U.S. Public Policy Committee for the Association for Computing ---------- Forwarded message ---------- Date: Fri, 01 Aug 1997 16:24:40 -0400 From: Aaron Pressman <aaron.pressman(a)reuters.com> Subject: reuters crypto story Human rights groups favor strong encryption abroad WASHINGTON, Aug 1 (Reuter) - Human rights activists came to Capitol Hill on Friday to tell lawmakers of their need to use strong computer encoding programs, subject to strict U.S. export limits, in their work outside the country. The debate over exports of encryption technology, which scrambles information and renders it unreadable without a password or software "key," has largely pitted the interests of commercial companies and civil libertarians against those of law enforcement and intelligence agencies. But human rights advocates said Friday they also had a critical interest at stake. Swift and inexpensive communications over the Internet "promise to destroy the ability of abusive regimes to silence their people, hide their atrocities and blockade the truth," said Dinah PoKempner, deputy general counsel for Human Rights Watch. "Encryption offers the most fundamental protection to those who seek to bring abuses to light in these circumstances," she added at a briefing for congressional staff. Those who report human rights abuses can become victims of abuse if discovered, so the availability of encryption to hide electronic mail messages or faxes can be a matter of "life or death," said Patrick Ball, who trains human rights activists to use the technology. The Clinton administration generally prohibits the export of strong encryption unless the products allow the government to decode any message by gaining access to the software keys. A variety of encryption-related legislation is pending in Congress, including bills that would overturn the Clinton policy and relax the export limits. Ball, senior program associate with the American Association for the Advancement of Science (AAAS), warned that the use of so-called key recovery features to give governments access to coded messages could compromise the work of human rights groups. "How can we ensure that intelligence and law enforcement groups in repressive countries will not directly or indirectly obtain human rights groups keys from the U.S. government," Ball asked. "Human rights monitoring is always defined by repressive regimes as a threat to national security." Congressional staffers attending the briefing also heard from leading cryptography scientists who said U.S. export controls stifled research on encryption, thereby slowing the development of more secure computer networks. Alex Fowler, project coordinator with the AAAS, said the presentations were intended to counter the portrait of encryption users painted by law enforcement agencies. "We want to reaffirm that cryptography is a science, not just a pastime of anarchists, terrorists and hackers," Fowler said. The export rules prohibit U.S. researchers from collaborating with foreign scientists on coding technology, according to Ian Goldberg, a graduate student at the University of California. In January, Goldberg sucessfully cracked a message in a few hours that had been encoded with the most powerful encryption allowed to be freely exported from the United States. A Canadian citizen, Goldberg said that he could collaborate with others or publish research on the Internet while home from school. "But I can't go home every time I have an idea --the plane fare alone..." he joked. --Aaron Pressman((202-898-8312)) For related news, double click on one of the following codes: [E] [U] [MNI] [NAT] [CAN] [US] [WASH] [BUS] [TEL] [DPR] [TRD] [ENT] [MUNI] [GVD] [DBT] [INT] [FRX] [CA] [LEN] [RTRS] Friday, 1 August 1997 16:04:06 RTRS [nN01204006] ------------------------------------------------------------------------ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

2 1

Re: Spam
by jim＠mentat.com 17 Dec '03

17 Dec '03

Stan the Sequencer sez: > Apparently only as far back as 1993, the definition of the word "spam" from > the on-line jargon file was this (according to the New Hackers Dictionary) - > > spam [from the MUD community] vt. To crash a program by over-running a fixed- > size buffer with excessively large input data. See also Buffer Overflow, > Overrun Screw, Smash the Stack. This isn't quite accurate. The term "spamming" in Mudding has always meant inundating the players with repetitive material, whether intentionally or accidentally, and has been used in that sense since sometime around 1990 at least. The "overflow" is of user screens, not stacks or buffers... although of course any high usage like that can test a program's limits. I just wrote and snipped a long disquisition on the history of spam starting with Clarence Thomas IV in 1993, having realized it's probably not relevant to your interests and old hat to everybody else. Suffice it to say that spam does require extra resources to process, both in hardware and time. We resent it because the end user is paying for it rather than the advertiser, so there is no natural limit to the amount of crap they can pour on us. Jim Gillogly

1 0

JYA Axed
by John Young 17 Dec '03

17 Dec '03

The ISP for jya.com, PrimeHost, an AOL subisidiary, has axed the site. We learned of this today after trying for a week to get an answer to why the site vanished. Tech said call Sales, Sales said it's not us, it's got to be Tech. Tech said it's definitely not us, and if it's not Sales or us it must be Bosses. Finally, a Boss was reached who said the site was "intentionally pulled." He claimed that it was "not a serious problem, so don't be alarmed," and sang cheerily about "some files" without elaboration. Maybe more next week, and we pray it turns out to be hysterically alarming and not merely a pissed Intel Prop owner seeking pay. JYX.com is still up, thanks to PrimeHost's autosub. Ten files there -- so far. We're humping to get the latest 60-page package of the RSA v. PGP suit there this weekend, thanks to Nobody.

3 2

Sexy Images...
by 34355680＠rocketmail.com 17 Dec '03

17 Dec '03

* Sexy * Erotic * Lewd and Desirable... LIVE NUDE DANCERS - 24 hours a day >>>The Hottest Adult Web Site on the Net<<< Check it out for FREE!!! Right Now! > Go to... http://209.14.30.103/115/ or AOL users can click below... Sexy Adult Web Site You must be of legal age in your jurisdiction to enter this Web Site! Thank You.

1 0

Sexy Images...
by 34355680＠rocketmail.com 17 Dec '03

17 Dec '03

* Sexy * Erotic * Lewd and Desirable... LIVE NUDE DANCERS - 24 hours a day >>>The Hottest Adult Web Site on the Net<<< Check it out for FREE!!! Right Now! > Go to... http://209.14.30.103/115/ or AOL users can click below... Sexy Adult Web Site You must be of legal age in your jurisdiction to enter this Web Site! Thank You.

1 0

thanks...
by Joichi Ito 17 Dec '03

17 Dec '03

Thanks to everyone who sent me information about Key Recovery. FYI, I gave a fairly objective update on the current status of the bills being debated in the US, distributed the Walsh Report (missing some paragraphs) and reviewed John Davidson's comments on the report, distributed and reviewed "The Risks of Key Recover, Key Escrow and Trusted Third-Party Encryption", distributed and reviewed most of the material written by Carl Ellison, reviewed the recent letter from Janet Reno to Congress, distributed Whit Diffie's May '93 testimony on Clipper, and finished by distributing materials from the TIS site, in particular going over RecoverKey. I can't tell you about any of the other stuff that is currently being presented in the study group, but once the report becomes public, I will try to get an English version up on the Net. It should end up being the Japanese National Poice Agency's official position on Key Escrow, Certification Authorities, and several other issues. I will be participating in another study group soon to discuss many of these issues with the Self Defense Force from the point of view of Japanese national security as well as another NPA study group on what to do about "crackers"... Anyway, if anyone who can give me some insight into these areas will be at HIP, I'd love to chat. ;-) Thanks again. - Joi P.S. I am not a "policeman" but an outside boardmember of these study groups. The ministries are under quite a bit of scrutiny these days and the study groups tend to be quite frank and balanced. The reports don't always dictate the law, but since most politicians do not have real staffers, therefore most of the expert study is done in the ministries. -- Finger jito(a)nsm.eccosys.com or jito(a)garage.co.jp for PGP Key Fingerprint for RSA PGP Key ID 0x0EE23A2D 0D3A 7AAA 3DA8 E7B3 3AF1 C6FA B7ED D834 Fingerprint for DSS/Diffie-Hellman PGP Key ID 0x2D9461F1 58F3 CA9A EFB8 EB9D DF18 6B16 E48D AF2A 2D94 61F1 Home Page: http://domino.garage.co.jp/jito/joihome.nsf To subscribe to my personal mailing list send mailto:friends-subscribe@ito.com

2 1

Canada's Entrust does end-run around ITAR
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

------- Forwarded Message Date: Fri, 01 Aug 1997 18:13:20 -0700 From: kalliste(a)aci.net (J. Orlin Grabbe) To: snetnews(a)world.std.com Subject: SNET: [Fwd: Another torpedo slams into Clinton crypto policy] - -> SearchNet's SNETNEWS Mailing List Path: news.alt.net!news1.alt.net!news-chi-13.sprintlink.net!news-east.sprintlink.net!news-dc-26.sprintlink.net!news-peer.sprintlink.net!news-pull.sprintlink.net!news-in-east.sprintlink.net!news.sprintlink.net!Sprint!205.185.79.4!zdc!super.zippo.com!lotsanews.com!szdc!newsp.zippo.com!news1 From: jqp(a)globaldialog.com Newsgroups: alt.current-events.clinton.whitewater,alt.politics.clinton Subject: Another torpedo slams into Clinton crypto policy Date: Fri, 01 Aug 1997 00:21:25 -0500 Organization: None Message-ID: <33E17255.18BB(a)globaldialog.com> Reply-To: jqp(a)globaldialog.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (Win95; I) Xref: news.alt.net alt.current-events.clinton.whitewater:189839 alt.politics.clinton:338125 NY Times August 1, 1997 Canadian Product Puts New Spin on Encryption Debate By PETER WAYNER Canadian company's recent release of a new encryption product and subsequent announcement that it had received a license from Canada to export the product has surprised many companies and U.S. officials. The release was startling because the United States and Canada historically regulated the encryption- exporting issue in synchrony. The company, Entrust Technologies Ltd., released a free version of its Entrust/Solo software on Tuesday, and announced that they had received a license from the Canadian government to export it to almost all of the world. - -=- [TABLE] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= THE MOVE BY ENTRUST SEEMS TO EXPLOIT A DIFFERENCE IN THE REGULATIONS BETWEEN THE UNITED STATES AND CANADA. - -=- [TABLE] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This decision by Canada could signal a major rift developing between two allies over an issue that is becoming increasingly important to the computer software industry. In fact, the move seemed to startle the [*]Bureau of Export Affairs at the U.S. Department of Commerce. James Lewis, director of strategic trade at the bureau, would only issue a one-sentence statement through a spokeswoman: "This is under review as a potential enforcement matter." He offered no insight into which American laws were being violated. Shauna White, a spokeswoman for the company, said "We believe we are in full compliance with all the Canadian laws that apply." In the past, the United States and Canada enforced their encryption regulations with such cooperation that most controlled products are shipped in boxes announcing, "For U.S. and Canada only." The U.S. government was certain that Canadian regulations would block anyone from shipping the product out of Canada. Those regulations are still in place and there has been no change in the effect on products built in the United States. Programs written by Canadians, however, are another matter. Entrust was able to qualify for a license because their software contained what John Ryan, the company president and chief executive, said was "100 percent Canadian content." That is, it was developed in Canada by Canadian citizens. Entrust Technologies Inc. was spun off on Jan. 2, 1997, from Nortel (Northern Telecom) after Nortel developed the Entrust product. Entrust Technologies Inc. is based in Dallas, but most of the development work is done in Ottawa, Ontario, where the Canadian subsidiary, Entrust Technologies Ltd. has its offices. Ryan, for instance, is a Canadian citizen. The move by Entrust seems to exploit a difference in the regulations between the United States and Canada. Both countries are members of the Wassenar Arrangement on Arms Export Controls, a set of loosely controlled rules that took the place of Cold War- era regulations designed to reign in conventional arms and dual-use technologies. The arrangement regulates the export of encryption software but provided an exemption for general- use software that was freely available through either the public domain or widespread public channels like stores. Ryan explained: "Many countries have chosen to 'to turn that part off.' Canada has not chosen to turn that part off." The existence of this regulatory difference may have come as a surprise to many people in the United States because the Canadian software industry has not yet produced a top-rank international competitor. The academic computer science departments at colleges like the University of Toronto are first rate, but there are no companies with the same public presence as Microsoft or IBM. But Entrust Technology's emergence shows how quickly the public perception can become obsolete in the swiftly moving world of technology. The company is clearly hoping that its free version of the Entrust/Solo software will build acceptance for the commercial versions, which are also freely exportable. Many other companies follow the same strategy of releasing free versions to the public in order to publicize the commercial versions, which usually come with more features. Entrust allows people to download free copies of Entrust/Solo for personal use from their Web site, but they block requests from seven restricted countries: Libya, Iran, Iraq, Cuba, Angola, Syria and North Korea. France and Singapore are also blocked because they have restrictions on the import of technology. Entrust is already in heavy competition against a U.S. company, [*]Pretty Good Privacy Inc., which is circulating a free version of its encryption package, PGP 5.0. This version is available for home and non-commercial use without charge. The software, however, was developed in the United States and can't be exported without a license. The company has worked closely with the U.S. Commerce Department to smooth licenses for major U.S. companies seeking to use the software with their subsidiaries, but an individual license must still be granted in each case. Kelly Huebner Blough, director of government relations for Pretty Good Privacy, said: "Well, of course we would like the U.S. to license exports more liberally. Most of the other countries in the world license encryption software more freely. They may have strong policies on the books, but when it comes to implementation, the U.S. is the most restrictive." - -=- [TABLE] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ALL OF THE MAJOR SOFTWARE COMPANIES LIKE MICROSOFT, IBM AND SUN CONTINUE TO PRESS THE U.S. GOVERNMENT FOR RELIEF OF THE EXPORT CONTROL LAWS, ARGUING THAT BETTER AND BETTER SOFTWARE IS EMERGING THROUGHOUT THE WORLD. - -=- [TABLE] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Other companies will also be feeling the pressure. Ray Ozzie, the president of Iris, the developer of Lotus Notes, which is now owned by IBM, said: "This is further proof that easy-to-use, high-grade encryption products are available worldwide, and that U.S. companies continue to be at a disadvantage in the world marketplace. U.S. policy needs to change in order to take these realities into account." One of the most vexing parts of the regulatory equation involves unraveling whether the U.S. government can exert any pressure on Entrust Technologies Ltd. through its U.S.-based corporate parent, Entrust Technologies Inc. The current version of the regulations restrict U.S. companies from providing "technical assistance" to their foreign companies--a rule that would seemingly not apply to a product developed completely by Canadians. Earlier drafts were more vague and seemed to target any relationship or aid, but the final version focused on technical assistance. Companies with close relationships with the U.S. government are still circumspect. Steve Walker, president of the Glenwood, Md.-based [*]Trusted Information Systems, works closely with the Commerce Department to seek approval for all of its work done in Europe. They ask for a license for all of the software being developed by their subsidiary in Britain. "We've tried to be very careful about this, perhaps more careful about it than we need to be," Walker said and then pointed out, "We're getting approval." [*]Sun Microsystems is pursuing a strategy with a different corporate structure. The company bought a minority stake in a Russian network software company in 1993 and recently asked them to develop encryption software for the world market. The deal is undergoing scrutiny from the U.S. Department of Commerce, but no announcement has been made about the resolution. Sun announced that they hope to ship the software on August 15. Still, the range of a government is hard to measure. Greg Katsas, a lawyer in the Washington office of Jones, Day, Reavis, and Pogue, said: "Generally, the rules of jurisdiction of the place of incorporation apply, but there are cases where U.S. law reaches outside the boundaries. For instance, anti-trust law can cover acts done outside the U.S. intended to have an impact inside the U.S." All of the major software companies like Microsoft, IBM and Sun continue to press the U.S. government for relief of the export control laws, arguing that better and better software is emerging throughout the world. In the House of Representatives, legislation sponsored by Representative Bob Goodlatte, a Republican from Virginia, to liberalize export laws has found wide support, while similar legislation in the Senate has died. One of the major initiatives offered by the Clinton administration would ease export licenses for software that made it possible for law enforcement officials to obtain the software's keys with a court order. They propose lifting the restrictions for exporting the software using 56-bit keys with DES. A number of businesses have joined together what they call the Key Recovery Alliance to help negotiate with the government about the final implementation of this plan. Most major software vendors, including Entrust and Sun, are part of the alliance. While the companies are committed to producing software that helps recover encryption keys in emergencies, there is a great deal of debate about how this will be carried out. Entrust's product for office groups does offer key recovery, but it is a far cry from what the U.S. government would like to see implemented. Copies of the keys are only stored on the hard disk of the employee responsible for overseeing the network. There is no capability right now for interfacing with trusted third parties who would serve as recovery agents for the police. Still, Entrust also seems to be working to meet U.S. regulations. Their enterprise-wide system for larger companies has been granted a license for U.S. export even though it uses 56-bit keys. This license was recently granted as part of the United States' push for key recovery. It signifies that the U.S. Commerce Department felt that Entrust was moving toward compliance with the policy of smoothing access for the police. In two years, Entrust may integrate their key recovery system with licensed recovery agents or it could face losing its U.S. license. In the long run, this strategy continues to receive heavy resistance. While many businesses welcome key-recovery solutions for internal use, they seem to resist making it too easy for the police to access their documents. Corporations, after all, can be found guilty as well. The same rules apply to countries, which are finding themselves in an increasingly brutal worldwide competition for dominance. Countries with the most liberal export laws may be rewarded with a strong fraction of the market share and this is the crucial time when the decisions about product acceptance are being decided. Many MIS managers may choose Entrust's products simply because they don't need to fill out forms with the U.S. government in order to supply it to all of their foreign subsidiaries. Andrew Csinger is the President of Xcert, a Vancouver- based Canadian software company that manufactures encryption technology used for certification authorities. He expects that any difference between U.S. and Canadian encryption laws will be short-lived. "I think that market pressures are going to force the U.S. administration to respond more quickly, " he said. "In reality, cryptography is widely available throughout the world." Copyright 1997 The New York Times Company - -> Send "subscribe snetnews " to majordomo(a)world.std.com - -> Posted by: kalliste(a)aci.net (J. Orlin Grabbe) ------- End of Forwarded Message

2 1