Re: BXA press release URL; and where to get the regs in HTML

[Phil Karn]

Okay, I've read the latest version of the regs. As usual, they're long and
confusing, with exceptions to the exceptions to the exceptions. But
several things seem to stand out.

1. You can export pretty much anything to anyone but a foreign
government or to the seven pariah countries (Libya, Iraq, etc).

2. You can export anything that's publicly available (retail products,
source code, toolkits, etc) to anybody, including a foreign
government, as long as they're not in one of the seven pariah
countries.

3. When posting free crypto (source or object) on the net, you don't
need to implement any form of access control, even though this would
make it technically possible for one of the seven pariah countries to
download it.

4. The bottom line is, the only stuff that's still controlled is
proprietary encryption provided directly to a foreign government, or
to the pariah countries.

Do I have all this right so far?

What still confuses me are the circumstances that let you just send
an email pointer to BXA, and which ones require a review of some
sort before you can export.

Phil

Re: BXA Press Release on New Regs

[Marc Horowitz]

"R. A. Hettinga" <[EMAIL PROTECTED]> writes:

>> Since the state is, in a world of ubiquitous networks and financial
>> cryptography, going the way of the Church (i.e. more ceremony than
>> hegemony) I bet 1gAU (compounded) that, 400 years from now,
>> cryptography will *still* be a munition.

I claim that 1gAU.  Cryptography in the US is not a munition, and
hasn't been since 1996.

Marc

Re: BXA Press Release on New Regs

[R. A. Hettinga]

At 3:31 PM -0800 on 1/12/00, John Gilmore wrote:


> In addition, the guidelines also implement agreements reached by
> the Wassenaar Arrangement in December 1998 by decontrolling
> 64-bit mass market products, 56-bit encryption items and 512-bit
> key management products. Today's changes do not affect
> restrictions on terrorist supporting states (Cuba, Iran, Iraq,
> Libya, North Korea, Sudan, and Syria), their nationals, and
> other sanctioned entities.

In other words, frankly, "Same shit, different day."

Welcome to Xeno's munitions policy, ladies and gentlemen: half-step back,
then half-step back, then half-step back, and so on, until everyone gives
up in disgust and exports crypto anyway. (Meanwhile the state takes half as
step back, and then half a step back, in infinite recursion)

Not that such mummenchance matters in a world where strong cryptography is
freely available anyway, thanks to open source cryptography, like Mr.
Gilmore's FreeS/WAN effort, CryptoMozilla, Fortify, and so on.


Remember, to the Church, Galileo is still (just barely, in the same
Xenonian fashion) an apostate.

Since the state is, in a world of ubiquitous networks and financial
cryptography, going the way of the Church (i.e. more ceremony than
hegemony) I bet 1gAU (compounded) that, 400 years from now, cryptography
will *still* be a munition.

:-).

Cheers,
RAH
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

BXA press release URL; and where to get the regs in HTML

[John Gilmore]

From: David Sobel <[EMAIL PROTECTED]>
Subject: BXA release URL

John -

It's at:

http://204.193.246.62/public.nsf/docs/60D6B47456BB389F852568640078B6C0

Also, I've put up the HTML of the regs.  CDT has them up and
they appear to be "public" at this point (the National Journal
was saying earlier today that the regs were available at their
site, but we don't have a subscription).  Our version is at:

http://www.epic.org/crypto/export_controls/regs_1_00.html

- David
...
David L. Sobel, General Counsel  *   +1 202 544 9240 (tel)
Electronic Privacy Information Center*   +1 202 547 5482 (fax)
666 Pennsylvania Ave., SE Suite 301  *   [EMAIL PROTECTED]
Washington, DC 20003   USA   *   http://www.epic.org

BXA Press Release on New Regs

[John Gilmore]

(This doesn't appear to be on www.bxa.doc.gov anywhere yet.  BXA's
PR people say their web team is off at a retreat somewhere...  --gnu)

Forwarded-by: David Sobel <[EMAIL PROTECTED]>

FOR IMMEDIATE RELEASE
Wednesday, January 12, 2000

Contact:
Morrie Goodman 202-482-4883
Eugene Cottilli (202) 482-2721


Commerce Announces Streamlined Encryption Export Regulations

Washington, DC - The U.S. Department of Commerce Bureau of
Export Administration (BXA) today issued new encryption export
regulations which implement the new approach announced by the
Clinton Administration in September.

Today's move permits U.S. companies to export any encryption
product around the world to commercial firms, individuals and
other non-government end-users under a license exception (i.e.,
without a license). In addition, "retail" encryption products
which are widely available in the market can now be exported to
any end-user including foreign governments. In most cases, a
one-time product review by BXA continues to be required.
Post-reporting requirements are reduced to track industry
business models.

"This policy helps business and promotes e-commerce by adjusting
our regulations to marketplace realities that U.S. companies
face when they try to sell their products overseas. We've also
worked very hard to address privacy concerns and to ensure that
our law enforcement and national security concerns are met,"
said Commerce Secretary William M. Daley.

For source code, the regulation reduces controls further than
announced in September. Commercial encryption source code,
encryption toolkits and components can now be exported under
license exception to businesses and non-government end-users for
internal use and customization and for the development of new
products. In addition, the regulations relax restrictions on
publicly available encryption source code, including by posting
on the Internet.

The regulation further streamlines requirements for U.S.
companies by permitting exports of any encryption item to their
foreign subsidiaries without a prior review. Foreign employees
of U.S. companies working in the United States no longer need an
export license to work on encryption.

In addition, the guidelines also implement agreements reached by
the Wassenaar Arrangement in December 1998 by decontrolling
64-bit mass market products, 56-bit encryption items and 512-bit
key management products. Today's changes do not affect
restrictions on terrorist supporting states (Cuba, Iran, Iraq,
Libya, North Korea, Sudan, and Syria), their nationals, and
other sanctioned entities.

In developing this regulation, the Administration worked closely
with stakeholders to continue a balanced approach. The
government will review the workability of the regulation,
receiving public comments for 120 days. A final revised rule
will be issued shortly thereafter.

Attached is a comprehensive fact sheet that outlines the new
export control guidelines.



FACT SHEET

Administration Implements Updated Encryption Export Policy

Today, the Commerce Department published a regulation
implementing the Clinton Administration's update to encryption
export policy announced in September, 1999. The major components
of this regulation are as follows:

Global exports to individuals, commercial firms or other
non-government end-users

Any encryption commodity or software, including components, of
any key length can now be exported under a license exception
after a technical review to any non-government end-user in any
country except for the seven state supporters of terrorism.
Exports previously allowed only for a company's internal use can
now be used for any activity, including communication with other
firms, supply chains and customers. Previous liberalizations for
banks, financial institutions and other approved sectors are
continued and subsumed under the license exception. Exports to
government end-users may be approved under a license.

Global exports of retail products

A new category of products called "Retail encryption commodities
and software" can now be exported to any end user (except in the
seven state supporters of terrorism). Retail encryption
commodities and software are those which are widely available
and can be exported and reexported to anyone (including any
Internet and telecommunications service provider), and can be
used to provide any product or service (e.g., e-commerce,
client-server applications, or software subscriptions). BXA will
determine which products qualify as retail through a review of
their functionality, sales volume, distribution methods.
Products that are functionally equivalent to products classified
as retail will also be considered retail. Finance-specific,
56-bit non-mass market products with a key exchange greater than
512 bits and up to 1024 bits, network-based applications and
other products which are functionally equivalent to retail
products are considered retail products.

Internet and Telecommunications Service Provider

Re: Killer PKI Applications

[Lynn . Wheeler]

your comments don't appear to be inconsistent with Jane Winn's writings on PKIs

for instance her paper:: Hedgehog and Fox: PKI and Plublic & Private Sector Risk
Management

The Hedgehog and the Fox: Distinguishing Public and Private Sector Approaches to
 Managing Risk for Internet Transactions, 51 ABA Administrative Law Review
955
 (1999)

 This article argues that much recent and proposed electronic commerce
legislation
 is based on flawed assumptions regarding risk management and the practical
utility of
 current electronic commerce technologies. Such flawed legislation would
produce a
 loss allocation system that would undermine incentives that currently exist
 to improve
 the technological infrastructure of Internet commerce.  This paper was
presented at a
 conference at American University in March 1999.

http://www.smu.edu/~jwinn/hedgehogfox.htm

or other papers at her site:

http://www.smu.edu/~jwinn/





Greg Broiles <[EMAIL PROTECTED]> on 01/12/2000 01:47:04 AM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC, "Bill la Forge" <[EMAIL PROTECTED]>
cc:   "bram" <[EMAIL PROTECTED]>, "Peter Cassidy" <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject:  Re: Killer PKI Applications


.

While this would certainly be an interesting goal to achieve, I think it's worth
remembering that current software industry practice is for the software
publishers themselves to disclaim all or almost all warranties regarding the
performance of their software or its lack of errors .. so you're asking CA's to
guarantee something that publishers themselves don't, at present.

Re: Killer PKI Applications

[Greg Broiles]

At 05:00 PM 1/11/00 , [EMAIL PROTECTED] wrote:
>For the CA-based trust infrastructure to work for this scenerio ... the CA 
>needs
>to be asserting the trust/quality/integrity of applications produced by each
>software company (so that I only need to record CA-level trust decisions) ...
>once I need to record vendor-level trust decisions then I've truncated any 
>trust
>hierachy (embodied by a CA which then becomes superfulous/redundant).

While this would certainly be an interesting goal to achieve, I think it's 
worth remembering that current software industry practice is for the 
software publishers themselves to disclaim all or almost all warranties 
regarding the performance of their software or its lack of errors .. so 
you're asking CA's to guarantee something that publishers themselves don't, 
at present.

Further, CA's (well, the cautious ones) carefully limit their liability to 
third parties who rely on their statements - the customer of a CA is likely 
to be different from the end user who wants or needs to rely on the CA's 
assertion.

The above model would change both of the above practices - putting the CA 
on the hook to the end user, and making a positive warranty about one or 
more aspects of the software's performance.

At present, the risk ( = cost) of software failure rests on the 
purchaser/licensee, who's frequently unable to measure or calculate or 
otherwise account for it, so it's mostly ignored. Shifting that cost to the 
publisher/licensor or a CA or their insurers means that the cost will be 
measured and calculated and not ignored. Because end users mostly don't 
account for that cost, they're not likely to assign a high value to a 
transaction which shifts that cost to another party; but the party to whom 
the cost is shifted will want to value the transaction at its cost, or 
higher, because the cost can't and won't be ignored. The difference in 
apparent value of that cost-shifting transaction makes it unattractive to 
one or the other of its participants.

Thus, while the scenario you describe is an attractive one (especially if 
I've got my end-user hat on), I suspect that it's unlikely to see the light 
of day any time soon.


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: GSM awnser to A5/1

[Erik Zenner]

Did I miss something, or is this the first time that GSM acknowledges in
an official statement (though indirectly) the correctness of the A5/1
implementation provided by Green/Goldberg/Wagner? 

Well then, congratulations! Nonetheless, I would be interested to know
where and when this statement was given. 

ERIK ZENNER


> Joint statement by Chairman GSM Association Security Group and
> Chairman ETSI SMG10 Security Group
> 
> Many questions were raised by the paper of Alex Biryukov and Adi
> Shamir [1] on the GSM A5/1 over the air encryption algorithm, we would
> like to make the following comments:
> 
> The paper describes an interesting application of the time^^memory
> trade^^off principle to the A5/1 algorithm. This results in the
> described attack on A5/1 requiring known plaintext relating to the
> first few minutes of a GSM call.
> 
> We, and others, have previously examined similar attacks against A5/1,
> but they were considered not practicable. This is because the nature
> of the design of the GSM voice encoding and the GSM frame structure
> leads to very little known plaintext for A5/1.
> 
> Although of theoretical interest, the attack described by Biryukov and
> Shamir requires a similar quantity of known plaintext and must
> therefore be considered to be mainly of academic interest. There is
> still no evidence of any commercial violation of the A5/1 algorithm,
> which has now been in use for more than ten years.
> 
> However, we are not complacent about GSM security and remain totally
> committed to constantly enhancing the protection offered to our
> customers and to ensuring that GSM is afforded even better security.
> 
> Michael Walker Chairman ETSI SMG 10
> Charles Brockton Chairman GSMA SG