RE: secure sign & encrypt

Terje Braaten <Terje.Braaten@concept.fr> Thu, 30 May 2002 05:53 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14776 for <openpgp-archive@odin.ietf.org>; Thu, 30 May 2002 01:53:44 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4U5fLp13390 for ietf-openpgp-bks; Wed, 29 May 2002 22:41:21 -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 g4U5fI113386 for <ietf-openpgp@imc.org>; Wed, 29 May 2002 22:41:19 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <L8P7ZZ2J>; Thu, 30 May 2002 07:38:23 +0200
Message-ID: <1F4F2D8ADFFCD411819300B0D0AA862E29ABFC@csexch.Conceptfr.net>
From: Terje Braaten <Terje.Braaten@concept.fr>
To: "OpenPGP (E-mail)" <ietf-openpgp@imc.org>
Subject: RE: secure sign & encrypt
Date: Thu, 30 May 2002 07:38:22 +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 g4U5fJ113387
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

Michael Young writes that "The intended recipient is only one of many
pieces of context that a user might mistakenly believe was included
in the signed material." That is correct, but I will still argue that
the information on which keys the message is encrypted to (or intended
to be encrypted to) is special, and belongs in the OpenPGP standard.

It is not only mail that can be signed and encrypted with OpenPGP,
it can be all kinds of electronic documents and messages. When f.ex.
an "X-To-PGP-Key" header might be an adequate solution for e-mail
messages, it will not fit at all for other sorts of messages.
In fact, the only meta data about a message that is common to all
encrypted messages is the recipient public keys. And since this
is meta data about the message that is always present, I think
it is very appropriate to be specified in the protocol a convention
on how this is to be protected in a message that is signed and encrypted.

(If we could just have an optional sub packet on the signature in the first
round I would be happy.)

-- 
Terje BrĂ¥ten