RE: secure sign & encrypt

Terje Braaten <Terje.Braaten@concept.fr> Wed, 22 May 2002 16:28 UTC

Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16615 for <openpgp-archive@odin.ietf.org>; Wed, 22 May 2002 12:28:14 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g4MGD8919587 for ietf-openpgp-bks; Wed, 22 May 2002 09:13:08 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MGD6L19581 for <ietf-openpgp@imc.org>; Wed, 22 May 2002 09:13:06 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYMJ5>; Wed, 22 May 2002 18:10:36 +0200
Message-ID: <1F4F2D8ADFFCD411819300B0D0AA862E29ABE9@csexch.Conceptfr.net>
From: Terje Braaten <Terje.Braaten@concept.fr>
To: "OpenPGP (E-mail)" <ietf-openpgp@imc.org>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 18:10:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MGD7L19584
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 8bit

> -----Original Message-----
> From: Derek Atkins [mailto:warlord@mit.edu]
> Sent: 22. May 2002 16:09
[...]
> No, the best way around this problem is the USER INTERFACE and
> EDUCATION.  If you receive a signed message that looks like:

I have to disagree with you there Derek. It is not possible to
write an user interface that automatically detects this problem if
there is no support for it in the protocol. It has to be specified
in the protocol that under a sign & encrypt operation 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 warn the user if
the key used to decrypt the message is not found in an 'encrypted to'
packet in the signature (if it is to be a good signature).

No matter how much you try to educate your users, I think that
yet for a few decades most people will think that when they receive
an email that is both signed and encrypted, most will assume that
they can be sure that the signer and the encrypter is the same person.
I think it will be a very great improvement in the protocol to make
it so that it really can be true.

-- 
Terje BrĂ¥ten