Encryption standards & procedures legislation

gnu gnu
Wed Sep 21 16:21:24 PDT 1994


The House Committee on Science, Space & Technology is thinking about
legislation that would lay down the rules for the Federal Government
with respect to encryption standards.  On July 13, they released
a draft bill, which hasn't been introduced as legislation; they are just
passing it around for comment.  

The draft bill is available at ftp://ftp.eff.org/pub/EFF/Legislation/
Bills_by_name/encryption_standards_procedures_94_bill.draft.  The draft
has both good and bad ideas in it.

But I'm writing to you to ask for ideas on what the RIGHT bill would
be.  Perhaps there should be no legislation about this at all.
Perhaps there should be tight controls on encryption standards.  There
are a myriad of possible positions and side issues, like how would you
enforce such a bill?  What rights of public input and information
should there be?  How can the public prevent a rerun of Clipper, in
which all the public input was accepted but ignored?  What standards
should the encryption algorithms themselves meet?  Should these
standards be mandatory for the federal govt?  States?  Banks?  The
public?  Simply guidelines for voluntary use?  Should anyone be liable
if a standard, relied upon, is broken?  Was known to be broken when
proposed?  If keys were released which violate someone's rights?  If
keys were stolen through inadequate security?  Should there be tight
procedures for escrowed encryption standards, but fewer controls on
non-escrowed standards?  What level of risk is acceptable in producing
encryption standards?  Should standards always be public, or can they
be trade secret and/or classified?  Must they be public domain, or can
they be proprietary?  Can NSA control a standard, or should some other
agency?  Should the people at NSA working on standards for
non-classified use be available to the FOIA process, or can they
remain behind the NSA's FOIA shield law?  Must standardized encryption
be exportable?  Can export controls be based on non-public standards
like RC2?  Can a standard be adopted over the objection of NSA?  Can a
standard be adopted which increases the privacy, security, or
accountability of the public even though it decreases the NSA's or
FBI's ability to wiretap?  Etc.

Encryption standards range from algorithms (DES), to protocols (Secure
IP, digital cash), to verification criteria (DES validation), to
procedural issues (Clipper key access, creation and programming of
Clipper chips).  I've probably forgotten a few.

So, please don't take the current draft as a starting point.  Tell me
what you think the legislation OUGHT to cover, and why.  EFF will be
talking to the committee over the next weeks and years.  You can too,
if you want; Tony Clark is the staff member who released the draft.
I'm more interested in ideas -- "what might we be forgetting" -- than
in detailed legislative language or anything like that.

Thanks!  The brainstorming that the net and the Cypherpunks did about
Clipper issues raised issues that continue to be troublesome and
useful.  I'm hoping that we can do a similar job for issues related to
encryption standards in general.  Feel free to forward this message to
other interested parties.

I recommend sending ideas directly to me (gnu at toad.com); I will
summarize the results.  CC to cypherpunks at toad.com, sci.crypt, RISKS,
or elsewhere, if you think it's worthwhile for the larger community to
discuss your suggestions in detail rather than as part of discussing
and elaborating the resulting summary of issues.

	John Gilmore
	Chair, EFF Board Crypto Committee






More information about the cypherpunks-legacy mailing list