check out Islam Exposed.com at http://islamexposed.com

"Bryan Morris" <bryanmorrisjr@hotmail.com> Thu, 27 June 2002 16:33 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 MAA29668 for <openpgp-archive@odin.ietf.org>; Thu, 27 Jun 2002 12:33:05 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RGKNL25295 for ietf-openpgp-bks; Thu, 27 Jun 2002 09:20:23 -0700 (PDT)
Received: from hotmail.com (f71.law4.hotmail.com [216.33.149.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RGKNw25284 for <ietf-openpgp@imc.org>; Thu, 27 Jun 2002 09:20:23 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Jun 2002 09:20:16 -0700
Received: from 64.81.199.208 by lw4fd.law4.hotmail.msn.com with HTTP; Thu, 27 Jun 2002 16:20:16 GMT
X-Originating-IP: [64.81.199.208]
From: "Bryan Morris" <bryanmorrisjr@hotmail.com>
To: karlsson@hal-pc.org, Terje.Braaten@concept.fr
Cc: ietf-openpgp@imc.org
Subject: check out Islam Exposed.com at http://islamexposed.com
Date: Thu, 27 Jun 2002 16:20:16 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F71mOLSSPwQmWO2IskO00001d6c@hotmail.com>
X-OriginalArrivalTime: 27 Jun 2002 16:20:16.0471 (UTC) FILETIME=[85DB7E70:01C21DF6]
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>

check out Islam Exposed.com at  http://islamexposed.com


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RGKNL25295 for ietf-openpgp-bks; Thu, 27 Jun 2002 09:20:23 -0700 (PDT)
Received: from hotmail.com (f71.law4.hotmail.com [216.33.149.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RGKNw25284 for <ietf-openpgp@imc.org>rg>; Thu, 27 Jun 2002 09:20:23 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Jun 2002 09:20:16 -0700
Received: from 64.81.199.208 by lw4fd.law4.hotmail.msn.com with HTTP; Thu, 27 Jun 2002 16:20:16 GMT
X-Originating-IP: [64.81.199.208]
From: "Bryan Morris" <bryanmorrisjr@hotmail.com>
To: karlsson@hal-pc.org, Terje.Braaten@concept.fr
Cc: ietf-openpgp@imc.org
Subject: check out Islam Exposed.com at  http://islamexposed.com
Date: Thu, 27 Jun 2002 16:20:16 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F71mOLSSPwQmWO2IskO00001d6c@hotmail.com>
X-OriginalArrivalTime: 27 Jun 2002 16:20:16.0471 (UTC) FILETIME=[85DB7E70:01C21DF6]
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>

check out Islam Exposed.com at  http://islamexposed.com


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RANYT26888 for ietf-openpgp-bks; Thu, 27 Jun 2002 03:23:34 -0700 (PDT)
Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RANWw26876 for <ietf-openpgp@imc.org>rg>; Thu, 27 Jun 2002 03:23:32 -0700 (PDT)
Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id TAA17942; Thu, 27 Jun 2002 19:23:31 +0900 (JST)
Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id TAA28787; Thu, 27 Jun 2002 19:23:31 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id TAA04034; Thu, 27 Jun 2002 19:23:31 +0900 (JST)
Date: Thu, 27 Jun 2002 19:25:57 +0900 (JST)
Message-Id: <20020627.192557.125129914.kazu@iijlab.net>
To: ietf-openpgp@imc.org
Cc: stefan@epy.co.at
Subject: Secret Key Packet Formats
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <kazu@iijlab.net>
X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

Hello all,

I have several comments on Section 5.5.3 (Secret Key Packet Formats)
of 2440bis-05. 

>     - [Optional] If secret data is encrypted, Initial Vector (IV) of
>       the same length as the cipher's block size.

The following might be more easy to understand.

      - [Optional] If secret data is encrypted(string-to-key usage
        octet was not 0), Initial Vector (IV) of the same length as
        the cipher's block size.

>     - Encrypted multi-precision integers comprising the secret key
>       data. These algorithm-specific fields are as described below.

If string-to-key usage octet was 0, this field is not encrypted. So,
this should be:

      - Plain or encrypted multi-precision integers comprising the
        secret key data. These algorithm-specific fields are as
        described below.

>     - If the string-to-key usage octet was 255, then a two-octet
>       checksum of the plaintext of the algorithm-specific portion (sum
>       of all octets, mod 65536). If the string-to-key usage octet was
>       254, then a 20-octet SHA-1 hash of the plaintext of the
>       algorithm-specific portion. This checksum or hash is encrypted
>       together with the algorithm-specific fields.

This does not corver the other values than 254 and 255. According to
RFC 2440, a two-octet checksum is necessary for the other values.

>   The 16-bit checksum that follows the algorithm-specific portion is
>   the algebraic sum, mod 65536, of the plaintext of all the
>   algorithm-specific octets (including MPI prefix and data).  With V3
>   keys, the checksum is stored in the clear.  With V4 keys, the
>   checksum is encrypted like the algorithm-specific data.  This value
>   is used to check that the passphrase was correct. However, this
>   checksum is deprecated; an implementation SHOULD NOT use it, but
>   should rather use the SHA-1 hash denoted with a usage octet of 254.
>   The reason for this is that there are some attacks on the private
>   key that can undetectably modify the secret key. Using a SHA-1 hash
>   prevents this.

"16-bit checksum" should be "two-octet checksum".

This paragraph should cover V2. Actually, old PGP commands produce
Secret Key Packet with V2.

Combination of string-to-key usage octet and format version is
unclear.

2440bis-05 is read like:

		V3			V4
  0 
254		encrypted sha1 hash	encrypted sha1 hash
255		clear checksum		encrypted checksum
others

But I think this matrix should be:

		V2/V3			V4
  0		clear checksum		clear checksum
254		clear checksum		encrypted sha1 hash
255		clear checksum		encrypted checksum
others		clear checksum		encrypted checksum

If this is correct, I hope improvement of this section will be made in
the next draft.

Thanks.

--Kazu


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5AIPDe22954 for ietf-openpgp-bks; Mon, 10 Jun 2002 11:25:13 -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 g5AIPBn22950 for <ietf-openpgp@imc.org>rg>; Mon, 10 Jun 2002 11:25:11 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <M4109YRZ>; Mon, 10 Jun 2002 20:24:46 +0200
Message-ID: <1F4F2D8ADFFCD411819300B0D0AA862E29AC0E@csexch.Conceptfr.net>
From: Terje Braaten <Terje.Braaten@concept.fr>
To: "'john.dlugosz@kodak.com'" <john.dlugosz@kodak.com>
Cc: ietf-openpgp@imc.org
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 above.proper.com id g5AIPCn22951
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>

john.dlugosz@kodak.com 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
in
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 <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
> 
> 
> 
> 
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5AIGTT22682 for ietf-openpgp-bks; Mon, 10 Jun 2002 11:16:29 -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 g5AIGRn22677 for <ietf-openpgp@imc.org>rg>; Mon, 10 Jun 2002 11:16:27 -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 g5AIGoB29409; Mon, 10 Jun 2002 14:16:50 -0400 (EDT)
Sensitivity: 
Subject: Mailing List metaissue
To: karlsson@hal-pc.org
Cc: ietf-openpgp@imc.org
From: john.dlugosz@kodak.com
Date: Mon, 10 Jun 2002 13:16:24 -0500
Message-ID: <OF63A427F1.F2CF7CD9-ON86256BD4.00644561@kodak.com>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 06/10/2002 02:16:26 PM
MIME-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=09BBE147DFF7C3F18f9e8a93df938690918c09BBE147DFF7C3F1"
Content-Disposition: inline
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>

--0__=09BBE147DFF7C3F18f9e8a93df938690918c09BBE147DFF7C3F1
Content-type: text/plain; charset=us-ascii


From: John Dlugosz

Any idea why the list sent me 15 copies of this?
I've been getting dups from several of y'all, but this one just keeps on
going and going...






"Brian M. Carlson" <karlsson@hal-pc.org>@mail.imc.org on 05-30-2002
02:15:10 PM

Sent by:    owner-ietf-openpgp@mail.imc.org


To:    Terje Braaten <Terje.Braaten@concept.fr>
cc:    "OpenPGP (E-mail)" <ietf-openpgp@imc.org>
Subject:    Re: secure sign & encrypt


On Thu, May 30, 2002 at 07:38:22AM +0200, Terje Braaten wrote:
>
> 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.)

You can have this. The standard declares that subpackets 100 to 110 are
"internal or user-defined". You can even set the critical bit on it if
you like. This should solve your problem. Your only other problem is to
convince an implementer to implement this subpacket, or you can
implement it yourself. Do know that gpg has used 101 in the past for
internal purposes; this might be a bad choice.

This subpacket is completely optional; in fact all but two subpackets
are: the creation time, and the issuer.

Therefore, this discussion can end, knowing everybody is happy.

--
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A



--0__=09BBE147DFF7C3F18f9e8a93df938690918c09BBE147DFF7C3F1
Content-type: application/octet-stream; 
	name="C.DTF"
Content-Disposition: attachment; filename="C.DTF"
Content-transfer-encoding: base64

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjAuN2EtY3Zz
IChHTlUvTGludXgpDQpDb21tZW50OiBVYmkgbGliZXJ0YXMsIGliaSBwYXRyaWEuDQoNCmlRRVZB
d1VCUFBaNlBlV1IvOGxXQlZQbkFRTXZGUWY4Q3pBcHhML0lEbDdnNnpqcnh3VDRHckRDUFhYdHFX
bEYNCkthdVU3S1BvM3RJYUVPUGNZc2dnaXZzY05ISngvaGIxRlpSMjFXZkhzVTZKWjExTFgremlP
NFpCQ1hLN1lTV28NCnhTY01CUVROa3NkalY1bkdKSzRXMXNKamdTWHdMRnRpc0kxMVk1NGJrcjlM
RWRMZWE1YlphNEtoUi9QakI5OGQNCmpRdGlVeDB1YXFDejIxMURpSHprSmtZWXlONkZlREFFamVk
NGNETmpUSUxlZUNyeDRjYmZSQXNEUHFHc2Z2NzMNCjkxcmRaRll2bm9qZnBNSzUyR2tjc1l6MERU
S0gra3prYVhXaFhzZCtzVE0zY1IrYnNXVWdNQjJweDhNclhRNjENCmVlc3FXY1l5YzJ2SkxBQWQ2
U0pzYk1LTXd0YUgwUHVHbGdRd25VcHI2SDkxWU1NWXJ0UU9vUT09DQo9TjBzdw0KLS0tLS1FTkQg
UEdQIFNJR05BVFVSRS0tLS0tDQoNCg==

--0__=09BBE147DFF7C3F18f9e8a93df938690918c09BBE147DFF7C3F1--



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>rg>; 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)
Sensitivity: 
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>

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








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ACABH27409 for ietf-openpgp-bks; Mon, 10 Jun 2002 05:10:11 -0700 (PDT)
Received: from slartibartfast.fortytwo.ch ([217.162.234.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ACA8n27400 for <ietf-openpgp@imc.org>rg>; Mon, 10 Jun 2002 05:10:09 -0700 (PDT)
Received: from atlas.acter.ch (unknown [212.126.160.108]) by slartibartfast.fortytwo.ch (Postfix) with ESMTP id E54A5B48B for <ietf-openpgp@imc.org>rg>; Mon, 10 Jun 2002 14:09:46 +0200 (CEST)
Received: by atlas.acter.ch (Postfix, from userid 1047) id B11231A34E; Mon, 10 Jun 2002 14:09:44 +0200 (CEST)
Subject: Re: secure sign & encrypt
From: "Adrian 'Dagurashibanipal' von Bidder" <avbidder@fortytwo.ch>
To: ietf-openpgp@imc.org
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XsTCtWNXwjWyh/hAywkM"
X-Mailer: Ximian Evolution 1.0.5 
Date: 10 Jun 2002 14:09:44 +0200
Message-Id: <1023710984.7764.165.camel@atlas>
Mime-Version: 1.0
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>

--=-XsTCtWNXwjWyh/hAywkM
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Yo!

Jumpin' in late... [site-admin: please mark the mail archive at
../ietf-open-pgp/mail-archive as dead, or redirect to the real mail
archive. the charter on
http://www.ietf.org/html.charters/openpgp-charter.html still points to
the old location, so I assumed the list was dead. Just being nosy: the
agenda in the charter seems pretty much outdated, too. How does the
current agenda of the wg look like?]

As the one who apparently sparked this particular instance of this
discussion (remember
http://www.imc.org/ietf-openpgp/mail-archive/msg04314.html )

http://www.imc.org/ietf-openpgp/mail-archive/msg04373.html and the fact
that it's always difficult to prove that you have not done something or
that you do not possess some information convinces me that both ESE (or
SES) and my proposed 'intended encryption key' extension will never work
out. It all boils down to the fact that cryptography cannot replace
trust. So: No, I don't want to reopen this discussion.

Other comments to issues raised in this thread:

Something seemed odd throughout the discussion (the one I had on
gnupg-users, as well as the one you had here, which I only just found):
Tools (e.g. software) are made to automate and ease some tasks. The user
employs tools to get something he wants. It's not that tools are just
around until a user comes along and thinks 'oh, my, what may I do with
/that/?' So, if the user's expectations and the current behaviour of the
tool disagree, I'd want the tool fixed, not the user. To me, it seemed
that this got a bit lost in the discussion.

context info in mail, Mail headers: while message/rfc822 encapsulated in
multipart/signed would cover the issue of the headers not being
protected, it would be cumbersome to use with non-gpg users. Why not
copy these headers down into the MIME headers of the first MIME part of
the multipart/signed message? Of course, mailers will have to support
this and indicate clearly which information is signed and which is not
(kmail 1.4 does this nicely with colored boxes (at least for clearsigned
mail), evolution doesn't). encrypted messages can only be read with
gpg-enabled mailers anyway, so rfc822-encapsulation would probably be
easiest (encrypting recipient and sender may make sense, people could
just use usenet groups to make messages intraceable. Of course, normal
e-mail will still have valid To: and From: headers...). This was
probably discussed before - might somebody point me to the relevant
thread?

cheers
-- vbi

--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-XsTCtWNXwjWyh/hAywkM
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9BJcIwj49sl5Lcx8RAhibAJ9A8xiOz5hRybcnkLv5gmKlKII2rgCbBVZj
hudlPckDiCcKwFoPwKJjBfk=
=bszo
-----END PGP SIGNATURE-----

--=-XsTCtWNXwjWyh/hAywkM--