[799] in cryptography@c2.net mail archive
Re: CACK without GAK
daemon@ATHENA.MIT.EDU (Hal Finney)
Mon May 12 10:16:25 1997
Date: Sun, 11 May 1997 10:52:31 -0700
From: Hal Finney <hal@rain.org>
To: cryptography@c2.net
James Donald, <jamesd@echeque.com>, writes:
> We want to support corporate access to corporate keys,
> collective access to collective keys, without supporting
> government access to individual keys.
> [...]
> An encryption key will have a name like "Accounts receivable, MegaCorp",
> and will be known to more than one member of the corporation,
> probably to the keymaster, the CEO, and possibly more than one
> person in accounts receivable. The private key will be a corporate
> secret, but not an individual secret.
This is a reasonable idea, but it is difficult to implement.
It comes down to sharing encryption keys, and somehow arranging that the
names associated with them are generic and not individual. We must make
sure that the senders know they are sending to a corporate entity rather
than to an individual. However I don't see any way for the software to
enforce this usage mode. Software cannot reasonably distinguish between
general terms like "Accounts receivable" and names like "John Doe".
It would be unreasonable for most customers to have the software reject
a key certificate because the ID bound to the key looked too much like
a personal name, in the software's opinion. So at best you can encourage
or recommend this mode of usage.
A variant on the idea is not to worry about the names on the keys, but
simply to provide a feature whereby keys can be marked as corporate vs
personal, or more specifically, escrowed vs private. This would also
allow senders to know whether third parties are going to be able to read
what they send. Again, it is not possible to force this feature to be
enabled.
> This system is free from the nefarious, fraudulent, and coercive aspect
> that makes most schemes for CACK suitable for GAK, because the level
> of access is known to, and controllable by, the person encrypting.
Your proposal makes the level of access known to the person encrypting,
but not necessarily controllable by him. If the corporation does not
allow un-shared encryption keys for employees, then all messages sent
to corporate addresses can be accessed by the corporation.
Also, it is not clear that simply making the level of access known
to the person encrypting is sufficient to prevent a system of GAK.
Once a mechanism is in place to share secret keys, the government could
require it to be used for everyone. I am sure you will agree that even
if you knew that every message you sent were readable by the government,
that would not make the practice acceptable.
> Integrating key access with certification and distribution is both
> morally acceptable, and considerably more convenient and safer than
> integrating it with key use.
>
> A key certificate should give the person relying on that certificate
> an accurate impression as to who will have access to an encrypted
> message, and who could have signed a message.
Notification is a good step forward. Certainly the worst situation would
be one where someone assumed that the message he was sending was private,
when actually the keys had been shared so that other people could read it.
However I don't see it as a full solution to the problem.
Hal
