| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
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 |