RE: secure sign & encrypt

Terje Braaten <> Mon, 10 June 2002 18:31 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA17873 for <>; Mon, 10 Jun 2002 14:31:01 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by (8.11.6/8.11.3) id g5AIPDe22954 for ietf-openpgp-bks; Mon, 10 Jun 2002 11:25:13 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g5AIPBn22950 for <>; Mon, 10 Jun 2002 11:25:11 -0700 (PDT)
Received: by with Internet Mail Service (5.5.2653.19) id <M4109YRZ>; Mon, 10 Jun 2002 20:24:46 +0200
Message-ID: <>
From: Terje Braaten <>
To: "''" <>
Subject: RE: secure sign & encrypt
Date: Mon, 10 Jun 2002 20:24:45 +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 id g5AIPCn22951
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 8bit wrote:
> 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?

Everything that is "signed & encrypted" has a list of recipients that it
is encrypted to. This list of recipients is included in the protocol. That
is why I mean the protection of this information by signing it also belongs
the protocol.

> 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.

I think you have completely missed my point here. Please read what
I wrote once again. I am making an argument for that this is NOT
a kind of general "extra information", it is information that already
are included as a part of the protocol. And a proper standard for how
to duplicate this information inside the signed part of the message
should also be a part of the standard, so that this can be done in the
same way by all applications that uses this standard. Is this to much
to ask?

> Terje Braaten <> on 05-30-2002
> 12:38:22 AM
> Sent by:
> To:    "OpenPGP (E-mail)" <>
> 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