Re: NIST Draft Key Escrow Paper

[jim bell <jimbell@pacifier.com>]

A few comments on the NIST draft.


SUBJECT:  Draft Paper, "Enabling Privacy, Commerce, Security
          and Public Safety in the Global Information
          Infrastructure"
FROM:     Bruce W. McConnell [Initials]<br>
          Edward J. Appel [Initials]<br>
          Co-Chairs, Interagency Working Group on
          Cryptography Policy

> It would permit users and manufacturers free
>choice of encryption algorithm, facilitate international
>interoperability, preserve law enforcement access, and, most
>importantly, provide strong system security and integrity.

What if we don't WANT to "preserve law enforcement access"?  What if we 
believe that, as individuals and as a society, we would be safer and better 
off to emasculate the government-employed thugs?

>     Recognizing that a robust infrastructure is not yet a
>reality, we are also considering measures to liberalize export
>policy for some non-escrowed products.

Why restrict it at all?

>Enabling Privacy, Commerce, Security and Public Safety in the
>Global Information Infrastructure

Too bad they weren't more honest and said, "Government employee safety."

>Government
>and industry must work together to create a security
>management infrastructure and attendant products that
>incorporate robust cryptography without undermining national
>security and public safety.

I don't believe this.  Do you?

> A policy for escrow of
>cryptographic keys which provides a basis for bilateral and
>multilateral government agreements must be determined so that
>industry can produce products for worldwide interoperability.

WRONG!  This is NOT necessary in the least.  Just allow free export, period.


>Industry will participate in defining algorithms and protocol
>standards, and will develop key escrow encryption products
>suitable for the protection of both government and private
>sector information and which will assure timely, lawful,
>government decryption access.

If this system is "voluntary" then why the "assure" part?  

> Government will help set
>standards for the Key Management Infrastructure (KMI) and
>deliver a market for robust security products.

In other words, it will shell out stolen tax dollars to willing 
co-conspirators.  No thank you!

 A KMI
>infrastructure and attendant key escrow products will provide
>many benefits, both domestic and internationally, as the US
>begins to realize the advantages of the global network for
improve commerce, security and public safety.

Most if not all of these advantages have no need for a "key management 
infrastructure."


> The nation's commerce is moving to
>networking. With these enormous changes, means must be found
>to responsibly raise the quality of cryptographic services
>without jeopardizing effective law enforcement, imperilling
>public safety.

I wish they'd be a bit more honest and use "government safety" instead of 
"public safety."


>     Industry and government must partner in the development
>of a public key-based key management infrastructure and
>attendant products that will assure participants can transmit
>and receive information electronically with confidence in the
>information's integrity, authenticity, and origin and which
>will assure timely lawful government access. 

Why, exactly, "must" industry do this?  This whole system is supposed to be 
"voluntary," right?


     There is a more compelling rationale for the government
to be a partner in the development of the KMI. Not only has
the Information Age sparked fundamental changes in the way we
interact, but reliance on information systems makes our
institutions vulnerable to an unprecedented degree.

Aha!  "our institutions vulnerable to an unprecented degree?"  You're 
catching on!  But it's primarily the GOVERNMENT institutions which are going 
to be vulnerable.

> Almost all
>institutions upon which public safety and national security
>depend, ranging from the power grid to military command and
>control, are at severe risk because of their presence in and
>dependence upon a global information infrastructure.

Yes, you guys know you're gonna get your statist butts kicked, right out the 
door.

(In case you couldn't imagine it, I'm grinning right now...)



> Additionally, the widespread
>use of encryption without safety features such as key recovery
>can pose serious risks to society.

No, not a risk to "society".  A risk to government and its agents.

> It will put at risk
>important law enforcement and national security investigations
>where electronic surveillance and search and seizure are
>essential in preserving and prosecuting crimes, and more
>importantly, in saving human life.

I choose to forgo these investigations and their advantages.  

>    Participation in the KMI will be voluntary. Key escrow in
>     the KMI will occur naturally through mutually trusted
>     authorities.

What do you mean, "Voluntary"?


>+    There will be a transition period during which legacy
>     equipments which do not support key recovery can be used
>     to communicate with users in emerging full featured KMIs.

Huh?  If this system is really "voluntary," this last paragraph doesn't make 
sense.


 >    Self-escrow will be permitted under specific
 >    circumstances.(1)

Huh?  What is the word "voluntary" supposed to mean, with relation to these 
statements?


>   Export controls on Key Escrow products will be relaxed
>     progressively as the infrastructure matures.

Why not eliminate escrow controls on all products?


(1)  The escrow agency must meet performance requirements for
     law enforcement access.

Again, whither "voluntary"?

<p>
>     To participate in the network a user needs a public key
>certificate signed by a CA which "binds" the user's identity
>to their public key.

That's simply wrong.  No certification is needed to use public-key 
encryption, as users of PGP well know.

> One condition of obtaining a certificate
>is that sufficient information (e.g., private keys or other
>information as appropriate) has been escrowed with a certified
>escrow authority to allow access to a user's data or
>communications.(3) (As noted before, this might be the CA or
>an independent escrow authority). The certificate creation
>process is pictured above.

Sounds like more abuse of the word, "voluntary."

>     For users to have confidence in the KMI, CAs must meet
>minimum standards for security, performance, and liability. A
>Policy Approving Authority (PAA) certifies CAs for operation.
>The PAA sets rules and responsibilities for ensuring the
>integrity of the CAs. The PAA is also responsible for setting
>CA performance criteria to meet law enforcement needs.

"Voluntary"?

>     If law enforcement has obtained legal authority to access
>a user's encrypted data or communications, it would certify
>that authorization to the escrow authority. The escrow
>authority will then relinquish information sufficient to
>access the user's communication.

"Voluntary"?

What if the user has already come to an agreement with the escrow authority 
that under no circumstances should any key be disclosed?  What if the user 
only gives the escrow authority an encrypted key?


>III. Some Issues
>     Difficult issues include i) how to refine the application
>of export controls, ii) whether and to what extent to permit
?self-escrow, 

More "voluntary" abuse...


>Export Controls
> The task, then, is to find a method of applying
>export controls that meets the interest of national security,
>public safety, privacy, and competitiveness.

Uh, have you forgotten about "individual freedom"?

>    Freedom to choose any mutually trusted certificate
>authority may accommodate the above interests.

How about "freedom to choose NO trusted certificate authority"?

>(4) In addition,
>allowing ready export of products of any bit length to markets
>where the key management infrastructure, which complies with
>statuatory constraints, is in place to permit government
>access to keys, would provide both a level market for U.S.
>manufacturers and higher quality security products for users.

I don't want a "level playing field" here.  I want a free, unrestricted, and 
open playing field.


>Products that meet defined performance requirements and which
>will not operate until the key is escrowed with an appropriate
>certificate authority will address commercial, public safety
>and national security needs.

But they won't address individual freedom needs.


(4)  A mutually trusted authority is an escrow agent trusted
     by users to store keys and trusted by law enforcement to
     provive access upon certification of lawful authority.

How can I trust any organization that will compromise my privacy on request 
by the government thugs?


>Transition
>     We are working toward a policy that permits licensing of
>key recovery encryption systems regardless of algorithm, bit
>length, or whether implemented in hardware or software, once
>needed infrastructure and government-to-government agreements
>are in place.

Don't bother.  I have an easier system already.  "Free and unencumbered 
exports for all software and hardware."
There, that's easy.


> In the interim we recognize that the policy must
>make it worthwhile for manufacturers and users to invest in
>escrowed KMI.

In other words, you want to misuse the power of government to bribe them 
into cooperation.


 With these objectives in mind, and consistent
>with applicable statutes,

But ignoring most of the US Constitution...


 the interim policy will consider:
<p>
Prior to formal government-to-government agreements:

>+    Permitting export of products that use an escrowed KMI to
>     approved markets, e.g., Europe or Australia, consistent
>     with the policies of the destination country.

What if "the politcies of the destination country" don't ask for ANY escrow 
system?  Are you saying you'll support free export in those cases?

>    Continuing and expanding the administration's previously
>     announced key escrow initiative by permitting the export
>     of 64 bit S/W or 80 bit H/W key escrow products that meet
>     defined performance requirements, after one-time review,
>     to any destination if keys will be escrowed in the U.S.,
>     or in foreign countries with which the U.S. has a
>     govvernment-to-government key escrow agreement.

Not acceptable.  How about 128-bit, non-escrowed softeware?  That would be a 
good start.


>   Permitting the export of other products on a case-by-case
>     determination that such exports are consistent with US
>     interests.

Maybe you meant, "government interests"?


>     The proposals for an interim export control policy are
>founded on the assumption that the products will require the
>use of an escrowed KMI in a country with which the U.S. has a
>government-to-government agreement. 

Aha!  So you're assuming THEIR country's thugs and OUR country's thugs will 
gang up on us?


>     The interim policy also reflects a judgment that overseas
>escrow of key will generally be permissible with suitable
>government-to-government arrangements. There is a concern that
>U.S. products with keys escrowed in the U.S. will not be
>saleable overseas. Hence, it may be possible to permit
>overseas escrow in Europe, even before government-to-
>government arrangments are completed. This exception is
>possible since the European countries are already moving to
>implement key escrow systems and we can reasonably expect to
>enter into law enforcement agreements in the near term.

Danger Will Robinson!  Danger!


>The
>OECD's goal of negotiating multilateral cryptography
>guidelines by 31 December 1996 is further evidence of European
>intent and momentum in infrastructure development.

YES!  Gotta make sure you don't get your collective butts kicked out of 
power , huh?


     The interim policy reflects a differentiation between
hardware and software products, i.e., hardware products with
greater bit lengths are treated more favorably under this
policy. Hardware implementations of products permit more
confident binding between encryption and the key management,
limiting the risk that the encryption can be easily stripped
from the key management and used independently of key
recovery. 

Uh, where's that "voluntary"?


>Software does not provide similar protection. This
>said, the interim policy to permit export of 64 bit software
>key recovery products would reflect a significant increase
>over the bit length restrictions applicable to non-key
>recovery products.

Self-Escrow
<p>
>     Self-escrow will be a principal concern of many large
>corporations that want to provide corporate data recovery,
>protect against loss of proprietary data from use of an
>outside escrow agent, and simply for reasons of efficiency and
>cost. Hence, self-escrow must be considered as an acceptable
>option.

How about "non-escrow"?

>     A solution is a national policy which allows CAs for an
>organization to serve as escrow authorities if they can meet
>necessary performance requirements. These requirements should
>be determined by government in consultation with industry and
>should address timeliness, security, confidentiality of
>requests for, or release of, keys, and independence of the
>escrow authority from the rest of the organization. To this
>end, the government should seek legislation that would shield
>organization certificate authorities from internal pressures
>in the course of law enforcement investigations.

In other words, you don't want "honesty" to affect the snitches?

>Legislation
>     There is some consensus that the ultimate legislative
>package should include provisions to criminalize the
>unauthorized disclosure/use of escrowed key, provisions to
>authorize civil actions by victims against those responsible
>for the unauthorized disclosure/use of escrowed key,
>provisions specifying the circumstances in which escrowed key
>may be requested and released (e.g., death of a family member
>or employee), and establishing liability protection for
>certificate authorities who exercizes due prudence in the
>fulfillment of their performance obligations.

What about requirements that people whose keys are requested be notified 
immediately of such a request and are given an opportunity to challenge it, 
or even better given an opportunity to demand that the key is erased, or 
given an opportunity to FAIL to provide a decrypt key to unlock the escrowed 
decrypt key?

  

>Government to Government Agreements
>
>     There is an expressed need by all govenments to have
>access to information affecting their own security 

Finally they admit it!

> To demonstrate resolve and good faith, the United States
>Government should immediately:
>

The only way the US government could demonstrate "good faith" is to disband 
itself immediately.

     6.   Negotiate with other governments arrangements for
          access to escrowed keys consistent with national
          sovereignty, national security, and public safety.
<p>
<p>
     As trusted partners, industry and government can share
expertise and tackle intractable problems such as the insecure
operating system. In times past, the cryptographic algorithm
was the core of the solution: now it is the easy part. The
debate over algorithms and bit lengths should end: it is time
for industry and governments to work together to secure the
GII in such a way that does not put the world at risk.


We agree that "the debate over algorithms and bit lengths should end."  We 
just think it should end with complete and total elimination of export 
restrictions.  Period!


<p>
Key Recovery Performance Criteria
<p>
     Key recovery provides for backup storage of a user's
private keys. This backup capability helps ensure the
availability of a user's data even after it has been
encrypted. It also provides for an effective means for law
enforcement access. Key recovery requirements whould be viewed
from the perspective of the individual, the corporation, or
governments that require access. Most of the criteria to be
discussed have a dimension for key recovery on an individual
basis as well as from a corporate or government perspective.
The criteria can be grouped into three categories.


+    Confidentiality - Confidentiality must be maintained on
     all requests for release of key recovery information.

WHY?  If the system is VOLUNTARY....


[is there some reason that the bozo didn't include an email address?]

Jim Bell
jimbell@pacifier.com