[2095] 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 (Bodo Moeller)
Sun Feb 1 18:05:40 1998

Date: Sat, 31 Jan 98 00:55 GMT+0100
From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller)
To: cryptography@c2.net
In-Reply-To: <199801240708.AAA28558@nyx10.nyx.net>

Colin Plumb <colin@nyx.net>:
> Adam Back:

>> You may recall the furor generated by PGP Inc adding a [...]
>> feature [...] called [...] 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 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.

Indeed.

> 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.  [...]

> Obviously, once I have the message, I can share it with anyone I
> like. [...]  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.
> [...]

It is my understanding that the PGP software still follows a strict
"sign before encrypting" rule, which means that encrypted session key
packets are not authenticated.  Also, I believe that the CMR/ARR
concept was designed with the intention that the private component of
the recovery key not be used anywhere unless actual message recovery
seems necessary.  Unless I am mistaken on one of those points, the
message recovery design has the following drawbacks:

-- The CMR/ARR feature _cannot_ be relied on to mark a message either
   "recoverable" or "personal and confidential".  The presence or
   absence of an encrypted session key packet for the recovery key at
   the receiver's side quite simply has no meaning at all (unless
   active attackers are not in our threat model).

-- An encrypted session key packet allegedly decryptable by the
   recovery key might simply contain garbage (either because the
   sender wants to circumvent the recovery mechanism, or because the
   message was altered during transit).  Thus, in order to ensure
   recoverability of stored messages in case that, e.g., the recipient
   forgets his pass phrase, the _recipient_ has to reencrypt the
   message (or, equivalently, the session key) to some recovery key.

Since the recipient cannot rely on the usefulness of encrypted session
key packets for his recovery key, there arguably is no point in
transmitting them in the first place.  Also, it is unfortunate that
following the CMR/ARR protocol forces the sender to reveal to the
outside world whether a given encrypted message is intended to be
"private and personal" or not.

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