RE: secure sign & encrypt
john.dlugosz@kodak.com Mon, 10 June 2002 18:16 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 OAA17316 for <openpgp-archive@odin.ietf.org>; Mon, 10 Jun 2002 14:16:53 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g5AI9Ul22346 for ietf-openpgp-bks; Mon, 10 Jun 2002 11:09:30 -0700 (PDT)
Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AI9Sn22340 for <ietf-openpgp@imc.org>; Mon, 10 Jun 2002 11:09:28 -0700 (PDT)
Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g5AI9gB26846; Mon, 10 Jun 2002 14:09:42 -0400 (EDT)
Subject: RE: secure sign & encrypt
To: Terje.Braaten@concept.fr
Cc: ietf-openpgp@imc.org
From: john.dlugosz@kodak.com
Date: Mon, 10 Jun 2002 13:09:16 -0500
Message-ID: <OF79328E9B.ABB60A6D-ON86256BD4.00633EB8@kodak.com>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 06/10/2002 02:09:18 PM
MIME-Version: 1.0
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 g5AI9Tn22342
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
From: John Dlugosz Emails are the only thing where we might have missing context information. In an informal note typed by a person, it might assume the conversation in progress. But what contract or other formal document doesn't list the parties as part of the document content? And what does "intended recipient" mean for things that are not messages sent to somebody? If an application wants to automatically add context information before signing, without messing up the document proper, then a general purpose "extra information" field is needed, since "TO:" is just a special case of this general problem. And I think it's been said that a suitable field already exists. Terje Braaten <Terje.Braaten@concept.fr>@mail.imc.org on 05-30-2002 12:38:22 AM Sent by: owner-ietf-openpgp@mail.imc.org To: "OpenPGP (E-mail)" <ietf-openpgp@imc.org> cc: Subject: RE: secure sign & encrypt 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
- secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Hal Finney
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt vedaal
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt vedaal
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt vedaal
- Re: secure sign & encrypt Jon Callas
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt vedaal
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Hal Finney
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Jon Callas
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Peter Gutmann
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Matthew Byng-Maddick
- RE: secure sign & encrypt Dominikus Scherkl
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt David P. Kemp
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Matthew Byng-Maddick
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Dominikus Scherkl
- RE: secure sign & encrypt Dominikus Scherkl
- Re: secure sign & encrypt disastry
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt disastry
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Peter Gutmann
- Re: secure sign & encrypt Michael Young
- Re: secure sign & encrypt Paul Hoffman / IMC
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Brian M. Carlson
- Re: secure sign & encrypt Jon Callas
- Re: secure sign & encrypt Adrian 'Dagurashibanipal' von Bidder
- RE: secure sign & encrypt john.dlugosz
- RE: secure sign & encrypt Terje Braaten