Verisign gets export approval

Forwarded from PGP-USERS list:
> First PGPInc and now VeriSign? Hmmm. Is this telling us something?

     "VeriSign on Monday said it received permission from 
       the U.S. Department of Commerce to export 128-bit 
       strong encryption software and issue digital 
       identifications to approved organizations based on 
       that software. "

     "Under the 128-bit scheme approved by the U.S. 
      government Monday, companies will not need to 
      place their encryption keys in escrow, or submit 
      to U.S. government key-recovery requirements in 
     order to use VeriSign's software, company officials said."



#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
#   (If this is a mailing list or news, please Cc: me on replies.  Thanks.)

I think it tells us that Verisign managed to convince the government that
their product is only used for authentication, not encrypting content. 
Which appears currently to be true, no?  And since AFIK (Please, someone,
correct this if I'm wrong!) you can't with netscape anyway download
another party's key that you verify with a Verisign certificate, it would
take a fair amount of work for the ordinary user to set up a secure
channel using the current Verisign infrastructure.   

The ITAR exception for authentication-only products is of long standing.

On Wed, 16 Jul 1997, Bill Stewart wrote:

> Forwarded from PGP-USERS list:
> > First PGPInc and now VeriSign? Hmmm. Is this telling us something?
> 
>      "VeriSign on Monday said it received permission from 
>        the U.S. Department of Commerce to export 128-bit 
>        strong encryption software and issue digital 
>        identifications to approved organizations based on 
>        that software. "
> 
>      "Under the 128-bit scheme approved by the U.S. 
>       government Monday, companies will not need to 
>       place their encryption keys in escrow, or submit 
>       to U.S. government key-recovery requirements in 
>      order to use VeriSign's software, company officials said."
> 
> 
> 
> #			Thanks;  Bill
> # Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
> # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
> #   (If this is a mailing list or news, please Cc: me on replies.  Thanks.)
> 

A. Michael Froomkin        | +1 (305) 284-4285; +1 (305) 284-6506 (fax)
Associate Professor of Law | "Cyberspace" is not a place.
U. Miami School of Law     | froomkin@law.miami.edu
P.O. Box 248087            | http://www.law.miami.edu/~froomkin
Coral Gables, FL 33124 USA | It's @%#$%$# hot here.

On Thu, 17 Jul 1997, Michael Froomkin - U.Miami School of Law wrote:

> 
> I think it tells us that Verisign managed to convince the government that
> their product is only used for authentication, not encrypting content. 
> Which appears currently to be true, no?  And since AFIK (Please, someone,
> correct this if I'm wrong!) you can't with netscape anyway download
> another party's key that you verify with a Verisign certificate, it would
> take a fair amount of work for the ordinary user to set up a secure
> channel using the current Verisign infrastructure.   

True, the certs themselves are not covered by the export controls. But we
aren't talking about export law. We are talking about a four way
contract between Netscape, Microsoft, VeriSign, and the US government. 

Under that contract:

o VeriSign will only issue Global ID certs to US
companies with all their servers located in the US and overseas banks with
servers abroad that play by the USG's rules. Once the USG no longer approves
of the participants using strong crypto with their customers, VeriSign
will revoke the cert, disabling secure communications, and thereby severely
damaging, if not destroying, the business of the party unfortunate enough
to have relied on such a cert for their livelyhood. 

o Netscape and Microsoft get a blanket approval to ship their servers to 
non-US banks that meet the USG's criteria.

o Netscape and Microsoft also receive approval to export browsers that can 
use strong crypto *exclusively* with sites the USG and VeriSign approve of.

o The USG no longer has to waste time handling export applications it
doesn't mind approving anyway, such as those for US-friendly foreign banks.
And the USG no longer has to listen to US companies complain because they
are unable to provide their non-US customers with secure access to the 
sever located in the US.

Lastly, and most importantly, every purchaser of a VeriSign Global ID cert
allows the USG and VeriSign to install a MASTER-OFF switch in the heart of
their business. I feel sorry for the poor suckers that will lose home and 
hearth after subscribing to this fatally flawed solution.

--Lucky

Bill Stewart wrote:
> 
> Forwarded from PGP-USERS list:
> > First PGPInc and now VeriSign? Hmmm. Is this telling us something?
> 
>      "VeriSign on Monday said it received permission from
>        the U.S. Department of Commerce to export 128-bit
>        strong encryption software and issue digital
>        identifications to approved organizations based on
>        that software. "
> 
>      "Under the 128-bit scheme approved by the U.S.
>       government Monday, companies will not need to
>       place their encryption keys in escrow, or submit
>       to U.S. government key-recovery requirements in
>      order to use VeriSign's software, company officials said."

What this means is that VeriSign is now allowed to issue the "magic
banking certs" for servers that allow them to communicate with the
export version of Communicator using 128-bit SSL.

On the other hand, it's also meaningless until "approved organizations"
start getting approved.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@netscape.com
transcending structure.  -- The Tao of Programming   |

At 09:57 PM 7/16/97 -0700, Bill Stewart wrote:
>Forwarded from PGP-USERS list:
>> First PGPInc and now VeriSign? Hmmm. Is this telling us something?
>
>     "VeriSign on Monday said it received permission from 
>       the U.S. Department of Commerce to export 128-bit 
>       strong encryption software and issue digital 
>       identifications to approved organizations based on 
>       that software. "

It tells us that the US government has found yet another sucker to support
their failed policy of bait and switch. VeriSign, just as AT&T and National
Semiconductor have discovered in the past, will discover soon that the
revenue generated by "playing ball" isn't nearly as large as promised. [How
many Clipper phones and Fortezza iPower cards were sold? Total?] In fact,
it the revenue may well prove to be in the negative digits.

Here is the straight dope on the VeriSign/MSFT/NSCP/USG deal:

If you are

1. A non US-bank (the feds decide what constitutes a bank) and promise to
be nice or
2. A US corporation with a server inside the US and thereby subject to
subpoena of all records

then VeriSign will issue you a special cert, subject to veto by the feds,
that will enable exportable Netscape and Microsoft browsers to connect to
your site with 128 bit SSL.

The cert is typically valid for a year, but is subject to revocation at any
time by VeriSign upon the USG's request. Such revocation or refusal to
issue a new cert after the first year of operation will leave the webserver
operator with a server that is no longer able to encrypt communications to
their customers in any meaningful way, thereby effectively shutting down
Internet based operations of the company unfortunate enough to invest in
such a flawed solution.

In other words, the USG now permits you to use strong crypto in web based
communications with your international customers if you agree to play by
the USG's rules and allow the feds to install a MASTER-OFF switch in the
heart of your business. What is most amusing from the government's
perspective is that once the USG flips the switch, it will be VeriSign,
Microsoft, and Netscape that take the heat for selling their customers such
a flawed solution.




--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

It seems to me that someone who has a one year export approved Verisign
cert should use it to authenticate a new top-level CA cert which they pass
to their customers.  Cut Verisign and their nosy/noisy partner out of the
loop.


-------------------------------------------------------------------------
Bill Frantz       | The Internet was designed  | Periwinkle -- Consulting
(408)356-8506     | to protect the free world  | 16345 Englewood Ave.
frantz@netcom.com | from hostile governments.  | Los Gatos, CA 95032, USA

Bill Frantz writes:
> 
> It seems to me that someone who has a one year export approved Verisign
> cert should use it to authenticate a new top-level CA cert which they pass
> to their customers.  Cut Verisign and their nosy/noisy partner out of the
> loop.

My understanding is that Verisign's licensing agreement
explicitly forbids using any certs they issue as CA certificates.
Maybe if the 'someone' paid Verisign an appropriate fee they
might allow it, but I'd bet that fee would be very high.
Verisign's no dummy, they don't want to enable new competition
to ride on their backs.

In the case of this special strong-crypto-allowing cert, Verisign
would probably be encouraged to discourage cert holders from
using the special Verisign certs as CA certs, for the very
reason you suggest. :-)

The format of the X.509 extensions that will enable strong crypto
operation will be known soon.  Even if Netscape et. al. tried to keep
them secret, since they're public certificates they'll be available to
anyone with an ASN.1 parser.


-- 
Eric Murray  ericm@lne.com  Security and cryptography applications consulting.
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

At 10:00 AM -0700 7/17/97, Lucky Green wrote:
>At 09:16 AM 7/17/97 -0700, Bill Frantz wrote:
>>It seems to me that someone who has a one year export approved Verisign
>>cert should use it to authenticate a new top-level CA cert which they pass
>>to their customers.  Cut Verisign and their nosy/noisy partner out of the
>>loop.
>
>Only a valid VeriSign Global ID cert (an X.509 v3 cert with a special
>extension) will activate the strong encryption in exportable browsers. This
>is hardcoded into Navigator and Internet Explorer.

That's what patch installers are for ;-)

--Steve

Lucky Green wrote:
> 
> The cert is typically valid for a year, but is subject to revocation
> at any time by VeriSign upon the USG's request. Such revocation or
> refusal to issue a new cert after the first year of operation will
> leave the webserver operator with a server that is no longer able to
> encrypt communications to their customers in any meaningful way,
> thereby effectively shutting down Internet based operations of the
> company unfortunate enough to invest in such a flawed solution.

I don't know the details of the agreement between VeriSign and the
USG.  I'm curious: how will the CRL for this revocation get distributed?
Since Communicator doesn't automatically pull CRLs, how can any action
on VeriSign's part disable crypto for that server?  Or are you
suggesting that as part of the revocation process, the USG will bust
down their doors and grab all copies of their private keys?

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@netscape.com
transcending structure.  -- The Tao of Programming   |

On Thu, 17 Jul 1997, Tom Weinstein wrote:

> I don't know the details of the agreement between VeriSign and the
> USG.  I'm curious: how will the CRL for this revocation get distributed?
> Since Communicator doesn't automatically pull CRLs, how can any action
> on VeriSign's part disable crypto for that server?  Or are you
> suggesting that as part of the revocation process, the USG will bust
> down their doors and grab all copies of their private keys?

[Tom, I am glad that your are adding your voice to this tread].

It is true that Communicator does not presently pull CRL's. However, an 
X.509 based application probably should pull the CRL, or at least verify 
that a cert about to be relied upon has not in fact been revoked by 
looking for a match in the CRL. It stands to reason that Communicator 
will at one point add this, IMHO proper, feature.

I also would like to mention the reader that yesterday's release of MSIE 
4.0b2 *does* have the ability to check CRL's.

Even if Communicator would never check CRL's, not even in the future, the
mere fact that the Global ID cert have only a one year lifetime means 
anyone relying on Global ID can be held hostage by threatening to 
refuse to renew their cert. The reader may not be aware that unlike other 
certs, the Global ID certs are *only* issued by VeriSign. You can 
not go to a non-US CA and obtain such a cert. [Which of course would defy 
the whole purpose of this rather slick deal :-]

Unless VeriSign includes in the price of the Global ID cert a bond that will 
compensate the buyer of a Global ID based commerce system for any and all 
future losses caused by VeriSign either revoking or refusing to renew a 
cert (fat chance), anyone basing their strategy on having such a cert is 
at risk of losing their business.

--Lucky

Lucky Green wrote:
> 
> On Thu, 17 Jul 1997, Tom Weinstein wrote:
> 
>> I don't know the details of the agreement between VeriSign and the
>> USG.  I'm curious: how will the CRL for this revocation get
>> distributed?  Since Communicator doesn't automatically pull CRLs, how
>> can any action on VeriSign's part disable crypto for that server?  Or
>> are you suggesting that as part of the revocation process, the USG
>> will bust down their doors and grab all copies of their private keys?
> 
> [Tom, I am glad that your are adding your voice to this tread].
> 
> It is true that Communicator does not presently pull CRL's. However,
> an X.509 based application probably should pull the CRL, or at least
> verify that a cert about to be relied upon has not in fact been
> revoked by looking for a match in the CRL. It stands to reason that
> Communicator will at one point add this, IMHO proper, feature.
> 
> I also would like to mention the reader that yesterday's release of
> MSIE 4.0b2 *does* have the ability to check CRL's.

Yes, we will add this feature in some future release.  It will be
configurable, so if the user doesn't want to check CRLs he doesn't
have to.

> Even if Communicator would never check CRL's, not even in the future,
> the mere fact that the Global ID cert have only a one year lifetime
> means anyone relying on Global ID can be held hostage by threatening
> to refuse to renew their cert. The reader may not be aware that unlike
> other certs, the Global ID certs are *only* issued by VeriSign. You
> can not go to a non-US CA and obtain such a cert. [Which of course
> would defy the whole purpose of this rather slick deal :-]

Aren't all certs VeriSign issues only valid for one year?  This isn't
any different.

There's nothing preventing another CA from getting permission from the
USG to issue these magic certs.  We would have to distribute a patch,
but I don't see any problem with that.

> Unless VeriSign includes in the price of the Global ID cert a bond
> that will compensate the buyer of a Global ID based commerce system
> for any and all future losses caused by VeriSign either revoking or
> refusing to renew a cert (fat chance), anyone basing their strategy on
> having such a cert is at risk of losing their business.

I fail to see the problem.  Right now, if you want to communicate
securely with exportable web browsers, this is the only way to do it. 
Either you do it, or you don't.  If VeriSign doesn't renew your cert,
then you're right back where you were the previous year.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@netscape.com
transcending structure.  -- The Tao of Programming   |

Tom Weinstein wrote:

| > Unless VeriSign includes in the price of the Global ID cert a bond
| > that will compensate the buyer of a Global ID based commerce system
| > for any and all future losses caused by VeriSign either revoking or
| > refusing to renew a cert (fat chance), anyone basing their strategy on
| > having such a cert is at risk of losing their business.
| 
| I fail to see the problem.  Right now, if you want to communicate
| securely with exportable web browsers, this is the only way to do it. 
| Either you do it, or you don't.  If VeriSign doesn't renew your cert,
| then you're right back where you were the previous year.

	Nope, you've now got thousands of upset customers who were
using secure communications, and are now using cheesy exportable
ciphers.  (Hopefully, you wrote CGI so you can quickly switch to using
Stronghold. :)

Adam


-- 
He has erected a multitude of new offices, and sent hither swarms of
officers to harrass our people, and eat out their substance.

Adam Shostack wrote:
> 
>         Nope, you've now got thousands of upset customers who were
> using secure communications, and are now using cheesy exportable
> ciphers.  (Hopefully, you wrote CGI so you can quickly switch to using
> Stronghold. :)

It wouldn't help.  The problem is that your customers (using the export
client) who used to be able to connect using strong crypto now have to
use weak crypto.  It doesn't affect people using non-exportable clients.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@netscape.com
transcending structure.  -- The Tao of Programming   |

> On Thu, 17 Jul 1997, Tom Weinstein wrote:
>>Lucky Green wrote:
>> Even if Communicator would never check CRL's, not even in the future,
>> the mere fact that the Global ID cert have only a one year lifetime
>> means anyone relying on Global ID can be held hostage by threatening
>> to refuse to renew their cert. The reader may not be aware that unlike
>> other certs, the Global ID certs are *only* issued by VeriSign. You
>> can not go to a non-US CA and obtain such a cert. [Which of course
>> would defy the whole purpose of this rather slick deal :-]
>
>Aren't all certs VeriSign issues only valid for one year?  This isn't
>any different.
>
>There's nothing preventing another CA from getting permission from the
>USG to issue these magic certs.  We would have to distribute a patch,
>but I don't see any problem with that.

There's probably no technical reason these patches must originate with
Netscape.  Seems like a healthy cottage industry could spring up to supply
patch software to offshore companies which want magic certs w/o USG
approval.

--Steve

=snip=

> > I also would like to mention the reader that yesterday's release of
> > MSIE 4.0b2 *does* have the ability to check CRL's.
> 
> Yes, we will add this feature in some future release.  It will be
> configurable, so if the user doesn't want to check CRLs he doesn't
> have to.

An excellent way of implementing it. 

 
> Aren't all certs VeriSign issues only valid for one year?  This isn't
> any different.
> 
> There's nothing preventing another CA from getting permission from the
> USG to issue these magic certs.  We would have to distribute a patch,
> but I don't see any problem with that.

uh, why does one need permission of the usg to issue "magic certs"?


------------------------
Name: amp
E-mail: amp@pobox.com
Date: 07/18/97
Time: 04:06:36
Visit me at http://www.pobox.com/~amp

'Drug Trafficking Offense' is the root passphrase to the Constitution.

Have you seen 
http://www.public-action.com/SkyWriter/WacoMuseum
------------------------

amp@pobox.com wrote:
> 
>> There's nothing preventing another CA from getting permission from
>> the USG to issue these magic certs.  We would have to distribute a
>> patch, but I don't see any problem with that.
> 
> uh, why does one need permission of the usg to issue "magic certs"?

Because issuing these certs is defined as a "defense service".

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@netscape.com
transcending structure.  -- The Tao of Programming   |

At 10:02 PM -0700 7/18/97, Tom Weinstein wrote:
>amp@pobox.com wrote:
>>
>>> There's nothing preventing another CA from getting permission from
>>> the USG to issue these magic certs.  We would have to distribute a
>>> patch, but I don't see any problem with that.
>>
>> uh, why does one need permission of the usg to issue "magic certs"?
>
>Because issuing these certs is defined as a "defense service".

Precisely why there needs to be some hacks, from offshore CP, to enable
anyone to issue "magic certs".  Any volunteers?

--Steve

Steve Schear wrote:
> 
> At 10:02 PM -0700 7/18/97, Tom Weinstein wrote:
>> amp@pobox.com wrote:
>>>
>>>> There's nothing preventing another CA from getting permission from
>>>> the USG to issue these magic certs.  We would have to distribute a
>>>> patch, but I don't see any problem with that.
>>>
>>> uh, why does one need permission of the usg to issue "magic certs"?
>>
>> Because issuing these certs is defined as a "defense service".
> 
> Precisely why there needs to be some hacks, from offshore CP, to
> enable anyone to issue "magic certs".  Any volunteers?

The main result of such a hack would probably be to get our export
license yanked.  Of course, you might see that as desirable, for either
its direct or indirect effects.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@netscape.com
transcending structure.  -- The Tao of Programming   |

-----BEGIN PGP SIGNED MESSAGE-----

In article <33D04A75.31E08282@netscape.com>,
Tom Weinstein <tomw@netscape.com> wrote:
>amp@pobox.com wrote:
>> 
>>> There's nothing preventing another CA from getting permission from
>>> the USG to issue these magic certs.  We would have to distribute a
>>> patch, but I don't see any problem with that.
>> 
>> uh, why does one need permission of the usg to issue "magic certs"?
>
>Because issuing these certs is defined as a "defense service".

It is in no way a defense service for Ian's Certificate Authority to issue
a digital certificate to Steve's Offshore Laundry, Inc. that basically
says "I think communications to the holder of this cert should use 128-bit
encryption.", even if it uses the same V3 extension that Verisign uses.

Now, if some company were to sell a browser overseas that enabled 128-bit
encryption when it saw _any_ cert with this extension (or even any such
cert from a CA in the user's trusted CAs list), I'd say it's the browser
company that's supplying the encryption, not the CA; the CA just issued
a signed statement of fact/opinion.

It would seem to me, though, that the only reason Netscape was able to
release a browser with the "128-bit-if-Verisign-magic" mode overseas
was that the USG had gotten Verisign to agree that it wouldn't issue
Verisign-magic certs to "alledged terrorists", etc.  If Verisign renegs
on the agreement, and issues the Verisign-magic certs to left-handed
albino money-laundering aliens, they'd be in violation of whatever
they signed with the USG, but certainly not in violation of the crypto
export regs (which, now that they're under Commerce, I'm not sure even have
a "defense service" category anymore).

So in answer to the original question (IMHO), you don't need the permission
of the USG to issue "magic" certs (ones with the V3 extension).  It's just
that browser companies won't be allowed to make browsers that turn on
strong encryption for _your_ "magic" certs unless the USG trusts you
not to give such certs to just anybody.

Contrasting this situation with Microsoft signing CAPI modules is left
as an exercise for the reader.

   - Ian "I believe that the bearer of this signed message should be entitled
          to use as strong crypto as he likes."

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM9FR/kZRiTErSPb1AQG0ogP9HC1bMyak7D1PEgRHVHPYU+a5BzTpyf/W
4aYINON+eKxw0PbDM6Q6FjnP8r1dXSBPH1T8v+2RbTqQ0A4bGVEZWGlcJv5jzuRG
pJb/PuZQwNgecp2sx/sniyfHJdhE6H4omiaDa2URO00Mr9s7iotFleC5LdgGg+XV
n9EeJJDxLtY=
=mp59
-----END PGP SIGNATURE-----

This is sort of entertaining considering that Verisign still
doesn't use strong encryption for themselves.  (Set your browser to
not use broken algorithms, and try to connect to www.verisign.com.
Makes me want to send them the data for a class 3 cert.)

Lucky Green wrote:
| >
| >     "VeriSign on Monday said it received permission from 
| >       the U.S. Department of Commerce to export 128-bit 
| >       strong encryption software and issue digital 
| >       identifications to approved organizations based on 
| >       that software. "
| 
| It tells us that the US government has found yet another sucker to support
| their failed policy of bait and switch. VeriSign, just as AT&T and National
| Semiconductor have discovered in the past, will discover soon that the
| revenue generated by "playing ball" isn't nearly as large as promised. [How
| many Clipper phones and Fortezza iPower cards were sold? Total?] In fact,
| it the revenue may well prove to be in the negative digits.

| time by VeriSign upon the USG's request. Such revocation or refusal to
| issue a new cert after the first year of operation will leave the webserver
| operator with a server that is no longer able to encrypt communications to
| their customers in any meaningful way, thereby effectively shutting down
| Internet based operations of the company unfortunate enough to invest in
| such a flawed solution.

	I'll save Sameer the trouble, and suggest that people buy
Stronghold.

Adam

-- 
He has erected a multitude of new offices, and sent hither swarms of
officers to harrass our people, and eat out their substance.

At 09:16 AM 7/17/97 -0700, Bill Frantz wrote:
>It seems to me that someone who has a one year export approved Verisign
>cert should use it to authenticate a new top-level CA cert which they pass
>to their customers.  Cut Verisign and their nosy/noisy partner out of the
>loop.

Only a valid VeriSign Global ID cert (an X.509 v3 cert with a special
extension) will activate the strong encryption in exportable browsers. This
is hardcoded into Navigator and Internet Explorer.


--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

-----BEGIN PGP SIGNED MESSAGE-----

In <3.0.2.32.19970717100056.00733db4@netcom10.netcom.com>, on 07/17/97 
   at 10:00 AM, Lucky Green <shamrock@netcom.com> said:

>At 09:16 AM 7/17/97 -0700, Bill Frantz wrote:
>>It seems to me that someone who has a one year export approved Verisign
>>cert should use it to authenticate a new top-level CA cert which they pass
>>to their customers.  Cut Verisign and their nosy/noisy partner out of the
>>loop.

>Only a valid VeriSign Global ID cert (an X.509 v3 cert with a special
>extension) will activate the strong encryption in exportable browsers.
>This is hardcoded into Navigator and Internet Explorer.

Yep, fairly simmilar to "policy tokens" that were disscused on the list
last year.

Let's face it people the management of Nut$cape & Mick$loth are a bunch of
rat bastards who would sell their own mothers to make a buck.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBM85khI9Co1n+aLhhAQFjlQP/a5Cp4KTDNKh0wzvF/Y6YoJOd0u2swbvv
j02akFcab+mgfYGvEq9qUOmEoxw/jJ+4XXas0Zw/Ap6I8QcNEqRUQ/vAzR0UgUzo
m039NpNzT8KTo8TtX6Ry2Zhob2Wk3cpZ2+1H+mOpmYKBbXd6PZfna4u6sk2W6BTk
zNjh79taSDQ=
=TuK9
-----END PGP SIGNATURE-----

> 
> Only a valid VeriSign Global ID cert (an X.509 v3 cert with a special
> extension) will activate the strong encryption in exportable browsers. This
> is hardcoded into Navigator and Internet Explorer.
> 
So, write a new browser (Theres a linux project staring to do 
this for linux soon/now (i think anyway)) and then port to a bunch of 
systems and base it outside the US. There aren't any import restriction 
on strong crypto yet are there ?? Besides you could then set up a home 
page ala. netscape.com and rake in the advertising dollars, if you can 
get teh browser to take off. A lot of if's and work but in theory it 
works.

Jason =8-]