Subject: RE: secure sign & encrypt

From: Terje Braaten <[email-masked]>
Date: Thu, 23 May 2002 14:22:19 +0200

Matthew Byng-Maddick <[email-masked]> wrote:
> 
> As others have pointed out, what is the "atomic sign & 
> encrypt" of which you
> speak?

I envision that in a not too far feature, we can call the
sign & encrypt function in PGP an atomic sign & encrypt.
This is the solution of the problem that I have been trying
to describe all the time.

The problem is that even though sign & encrypt is not atomic
now, that is what most users expect. I do not find it
satisfying as a programmer to have to say to the users
"Sorry, but the OpenPGP protocol do not allow any atomic
sign & encrypt that would have solved your problem, so
you will have to do without."

Adding a new signature packet called 'encrypted to' (or something
like that) would allow OpenPGP applications to implement
such an atomic sign & encrypt. It could say in the protocol
that an application MAY implement atomic sign & encrypt,
and if it does, it MUST do such and such.

My suggestion for a protocol for atomic sign & encrypt is
that the application MUST make an 'encrypted to' packet in
the signature for each key the message and signature packet
is encrypted to in the encryption packet.
These 'encrypted to' packets MUST be in the signed part of the signature.

An application that implement decrypt & verify MUST/SHOULD warn the user if
the key used to decrypt the message is not found in an 'encrypted to'
packet in the signature if the signature contains 'encrypted to'
packets and thus indicates that the message is created by an atomic
sign & encrypt.

-- 
Terje Bråten

---

From: Derek Atkins <[email-masked]>
Date: 23 May 2002 08:46:45 -0400

> you will have to do without."

I disagree that all users are calmoring for this feature, but I
suppose we will have to agree to disagree on that.

> and if it does, it MUST do such and such.

Just so long as the user has to specifically specify this
functionality.  Note that this is a tradeoff and you LOSE a nice
feature of PGP in the process.  The feature that you lose is
repudiation of the recipient of a message.  You can honestly say to a
judge "I have no idea how he got that message -- I didn't encrypt it
to him".  Maybe you don't consider that a feature; some people do.

> These 'encrypted to' packets MUST be in the signed part of the signature.

As has already been suggested, the Notation packet can already do
this.  Just create an "encrypted-to" notation convention and publish
it as and RFC (and then convince people to implement it).  You do not
need any new packets to do what you want.

> packets and thus indicates that the message is created by an atomic

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Matthew Byng-Maddick <[email-masked]>
Date: Thu, 23 May 2002 15:10:34 +0100

> to describe all the time.
[...]
> and if it does, it MUST do such and such.

Of course, a better way to do this is the obvious one, for the signtext
to start with "Dear Bob," and then you know who it was intended for. This
is the recommendation in the few cryptographic texts I've read about
non-repudiation.

This, of course, requires educating users, <sarcasm>which is a much harder
problem than attempting to solve it in some convoluted (and probably wrong)
cryptographic way.</sarcasm>

If your users don't properly understand the attempted guarantees of the
cryptosystem, then whatever you do to try and make it better, they will
almost certainly make some other assumption about it.

MBM

-- 
Matthew Byng-Maddick         <[email-masked]>           http://colondot.net/