From: karlsiil@attmail.com (Karl A Siil)
Date: Thu, 31 Aug 95 08:21:34 PDT
To: cypherpunks@toad.com
Subject: Re: opinions on RSA Secure?
In-Reply-To: <199508311318.JAA47267@rs8.loc.gov>
Message-ID: <winATT-2.7-karlsiil-1478>
MIME-Version: 1.0
Content-Type: text/plain


Bill, et. al.,

>and generates an 80-bit key using Rivest's RC4. It has an "emergency access"
>feature (splittable key escrow) which can, however, be disabled by the user.
	.
	.
	.
>Bill Nugent
>Library of Congress
>(a personal, not an institutional, query)

To clarify, the Emergency Access (EA) feature's owner (e.g., the Site Security
Officer (SSO)) can determine whether to *allow* users to disable EA. A 
possible way one brings RSA Secure to the(ir) masses of users is as follows:

	The SSO (or some equivalent) gets the software and configures EA 
	(i.e., generates EA keys) on their PC. An important part of
	the EA config is the creation of a User Disk which is distributed
	to the users of the package. On that disk goes the cryto-stuff
	that lets EA work in the future, plus the config data (including
	whether or not the EA can be overridden).

	The users, on getting the User disks from the SSO, then configure
	their PC's to encrypt/decrypt their files. If the SSO hasn't
	allowed EA disabling, when the users encrypt, the "Disable EA"
	checkbox is greyed out (missing? I forget; I would prefer it to
	be missing if not available).

The important thing here is that the ability to control the RSA Secure 
"policy" is in the same hands as the responsiblity for creating the org's 
security policy, if any.

Personally, I find RSA Secure to be quite a nice package, from a usage point 
of view. The way it blends into FileManager is really convenient. The less I 
have to "work at" security, the more likely it is that I'll use it. The crypto
is satisfactory for my needs and I'm not going to rehash (no pun intended) the
arguments over RC4-40, etc.


					Karl A. Siil
					AT&T Bell Labs
					Holmdel, NJ