From: gnu
To: cypherpunks@toad.com, gnu
Message Hash: 13f66c1db160fe99ea11c5e4a7c9239ff85a61f66a86b5882825f0bebb860d4a
Message ID: <9409212321.AA09967@toad.com>
Reply To: N/A
UTC Datetime: 1994-09-21 23:21:24 UTC
Raw Date: Wed, 21 Sep 94 16:21:24 PDT
From: gnu
Date: Wed, 21 Sep 94 16:21:24 PDT
To: cypherpunks@toad.com, gnu
Subject: Encryption standards & procedures legislation
Message-ID: <9409212321.AA09967@toad.com>
MIME-Version: 1.0
Content-Type: text/plain
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@toad.com); I will
summarize the results. CC to cypherpunks@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
Return to September 1994
Return to “gnu”
1994-09-21 (Wed, 21 Sep 94 16:21:24 PDT) - Encryption standards & procedures legislation - gnu