Re: No liberalization for source code, API's

[Dan Geer]

I will be on stage at a minor league debating forum with Bill Reinsch
on Thursday of this week.

If you had one question you would want asked, what would it be?

Reply directly, please.  I'll read it all late Wednesday.

--dan

Re: No liberalization for source code, API's

[John Gilmore]

 If you had one question you would want asked, what would it be?

Why did the result of your year-long review of encryption policy
ignore the blatant unconstitutionality that the Justice Department's
Office of Legal Counsel found 20 years ago and that two Federal courts
have confirmed recently?  How can you, as an officer and a gentleman,
implement and enforce a policy that you know in your heart and soul to
violate the fundamental rights of your fellow citizens?

(Yes, I think Bill Reinsch does have a heart and a soul, unlike some of
the people who work on this issue in the government.  And he's also a
gentleman.  What's he doing in the muck with those other chaps?)

John

PS: Well, how about two questions...  How can exporters effectively
enforce the regulations against the government, if the government ever
violates its own regulations, e.g. by refusing to complete a "one time
technical review" after months or years?

No liberalization for source code, API's

[Greg Broiles]

There's been some discussion of this in the press, but not much discussion 
of the specifics. BXA has published a "question-and-answer" document 
discussing the anticipated regulations; it's available at 
http://www.bxa.doc.gov/Encryption/qa99.htm, and John Young has archived 
a copy at http://cryptome.org/bxa091699.htm.

In particular, the aspects of the crypto export policy most directly 
related to research, development, and discussion of improving security are 
unchanged. In the BXA's words -

 Can you provide a few examples where a license will still be required?
 
 Licenses will still be required for exports of encryption technology,
 technical assistance, cryptographic application programming interfaces
 (CAPIs), source code and exports destined to foreign government and military
 end users.

and

 Is source code allowed to be exported under a license exception or does this
 policy only authorize the export of encryption object code?
 
 Source code will continue to be reviewed under a case-by-case basis. This
 update will allow the global export of object code encryption software under
 a license exception.

Also, their thinking about API's seems to have become more nuanced; they 
now envision two classes of API's which are treated differently for export 
purposes, to wit -

 How does the update to encryption policy affect the export of
 cryptographic application programming interfaces (CAPIs)?
 
 Cryptographic interfaces are divided into two classes: Open Cryptographic
 Interfaces (OCI) andClosed Cryptographic Interfaces (CCI). OCI's are
 considered crypto-with-a-hole because they permit a customer or other party
 to insert cryptography into an encryption item. OCI's will continue to be
 reviewed on a case-by-case basis through the licensing process.
 
 CCI's contain a mechanism (such as a digital signing key) that prevents a
 customer or other party from inserting cryptography into an encryption item.
 After a technical review of the binding mechanism, these products will be
 eligible for export under a license exception. If destined to a commercial
 enduser, the additional signing can take place under a license exception
 after a technical review. If destined to a foreign government or military
 entity, the additional signing requires a license.
 
 We intend to discuss this issue with industry as we consult on the
 implementation of this regulation.

.. so don't throw away those license forms yet, open source fans. The BXA 
can now focus its efforts on Linux fans instead of Microsoft and Netscape/AOL.


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