Re: secure sign & encrypt
"Adrian 'Dagurashibanipal' von Bidder" <avbidder@fortytwo.ch> Mon, 10 June 2002 12:23 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 IAA00742 for <openpgp-archive@lists.ietf.org>; Mon, 10 Jun 2002 08:23:01 -0400 (EDT)
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>; 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>; 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: Mon, 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>
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 -- secure email with gpg avbidder@fortytwo.ch: key id 0x92082481 avbidder@acter.ch: key id 0x5E4B731F
- 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