[2077] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: GAK and S/MIME

daemon@ATHENA.MIT.EDU (Colin Plumb)
Sat Jan 24 17:00:49 1998

Date: Sat, 24 Jan 1998 00:08:30 -0700 (MST)
From: Colin Plumb <colin@nyx.net>
To: aba@dcs.ex.ac.uk, cryptography@c2.net

Adam Back wrote:
> You may recall the furor generated by PGP Inc adding a GAK enabling
> feature thus making it easier for governments to impose GAK on the
> deployed PGP 5.x user base.  PGP Inc called this feature CMR
> (Corporate Message Recovery) or ARR (Additional Recipient Request).

You know, I helped design this feature, and I have to defend it a
little.  It's as far from classic GAK as I could dream up.  the closest
scheme I can think of is the Clipper chip's LEAF system, but the
critical differences (in addition to choice of additional session key
recipient) are that 1) it's only used at the recipient's request, and
2) there is no attempt to enforce its use by the sender.

It is particularly designed to *reduce* pressure to share your long-term
key.  Lots of companies were using PGP 2.x and insisting on keeping a copy
of every employee's keys.  I thought this was a Bad Thing.

I presume everyone knows that this is a signature that my key can make
requesting any message encrypted to it also be encrypted to some other
key.  And PGP 5.x by default obeys the request.  In the GUI, it just
adds the second key to the recipient list when the first key is added.
The sender can take the second key off again if they wish; its just
the default to have it included.

Obviously, once I have the message, I can share it with anyone I like.
In any group effort, it is very likely that I will share the message.
Indeed, I may share essentially all of my correspondence with someone,
such as my secretary.  (Who do you think first reads mail to
billg@microsoft.com?  Or snailmail, for that matter?)

However, it's nice to have a way to mark a messge "personal and
confidential" for the times that a sender does need it.  If I share my
private key, the sender hasn't got that choice.  If I ask the sender to
share it, the sender does have that choice.  If using this facility
works well, then I never have a need to share my private key, or sent
up a system to automatically share mail sent to me, and the sender
*gains* privacy.

You could give everyone two keys - a "me or my agent" key, and a
"private and confidential" key, but this system seems to better
reflect what is actually happening.

And by pushing the cryptographic operation to the sender, the system
*must* have the sender's cooperation.  It can't possibly work without
notifying the sender, and I'm sure I don't need to explain all the says
that a sender can not cooperate even if the appearance of cooperation
is required.  The distinction between keys I share and keys I don't
share goes away.  Private keys are never shared.  End of story.  Easier
to explain, easier to rememeber, easier to verify.  More likely to be
honoured.

It's an attempt to be flexible and extend the security system to
satisfy legitimate needs people have to share information, but do so in
a careful and controlled way, being as strict as possible rather than
have people puch great big holes in the security for the sake of
convenience.

Just sharing the private keys is simple, doesn't make waves (because
the outside world doesn't see it), easier to explain and sell, and
generally has lots of advantages.  I just thought that it's bad for
privacy.

Can someone think of a better scheme?  I really am interested.
-- 
	-Colin

home help back first fref pref prev next nref lref last post