Re: bis05: Armor Headers

[David Shaw <[e-mail]>]

On Tue, Apr 30, 2002 at 05:09:32PM +0200, Marc Mutz wrote:

> I've looked through bis05 and I think the wording on non-US-ASCII characters 
> in armor headers is still too vague.
> 
> 1. It's not only the Comment field that is affected here. IIRC, GnuPG uses 
> non-us-ascii characters for the version header if localized, too.
> 2. An implementation allowing full UTF-8 in the Armor Headers indirectly 
> violates rfc3156.
> 
> I'd really like to see that Armor Headers MUST (at least SHOULD) be 
> constrained to US-ASCII, except in clearsigning, where the full UTF-8 may be 
> used since the enclosed text is already UTF-8.
> 
> The other way round: If exporting keys with armor or creating an armored 
> detached signature, all armor headers MUST be constrained to US-ASCII.

I agree with Marc.  I'd even go further and say for the sake of
simplicity that all armor headers MUST be US-ASCII with no special
case for clearsigning.  This certainly does violate the nice
UTF8-for-all-text policy of OpenPGP, but we're talking about *armor*
here - the point is to be 7 bit clean.  If we have an 8-bit transport,
why use armor at all?

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UHstn14701 for ietf-openpgp-bks; Tue, 30 Apr 2002 10:54:55 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UHssa14697 for <[e-mail]>; Tue, 30 Apr 2002 10:54:54 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3UHspo02015 for [e-mail]; Tue, 30 Apr 2002 13:54:51 -0400
Date: Tue, 30 Apr 2002 13:54:51 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: bis05: Armor Headers
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waning Gibbous (84% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Apr 30, 2002 at 05:09:32PM +0200, Marc Mutz wrote:

> I've looked through bis05 and I think the wording on non-US-ASCII characters 
> in armor headers is still too vague.
> 
> 1. It's not only the Comment field that is affected here. IIRC, GnuPG uses 
> non-us-ascii characters for the version header if localized, too.
> 2. An implementation allowing full UTF-8 in the Armor Headers indirectly 
> violates rfc3156.
> 
> I'd really like to see that Armor Headers MUST (at least SHOULD) be 
> constrained to US-ASCII, except in clearsigning, where the full UTF-8 may be 
> used since the enclosed text is already UTF-8.
> 
> The other way round: If exporting keys with armor or creating an armored 
> detached signature, all armor headers MUST be constrained to US-ASCII.

I agree with Marc.  I'd even go further and say for the sake of
simplicity that all armor headers MUST be US-ASCII with no special
case for clearsigning.  This certainly does violate the nice
UTF8-for-all-text policy of OpenPGP, but we're talking about *armor*
here - the point is to be 7 bit clean.  If we have an 8-bit transport,
why use armor at all?

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UHTrg14140 for ietf-openpgp-bks; Tue, 30 Apr 2002 10:29:53 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UHToa14135 for <[e-mail]>; Tue, 30 Apr 2002 10:29:50 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 172cES-0005XM-00; Tue, 30 Apr 2002 20:20:08 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 172bT2-00008p-00; Tue, 30 Apr 2002 19:31:08 +0200
To: [e-mail]
Subject: Re: bis05: Armor Headers
References: <[e-mail]>
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est.
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Tue, 30 Apr 2002 19:31:07 +0200
In-Reply-To: <[e-mail]> (Marc Mutz's message of "Tue, 30 Apr 2002 17:09:32 +0200")
Message-ID: <[e-mail]>
Lines: 19
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, 30 Apr 2002 17:09:32 +0200, Marc Mutz said:

> 1. It's not only the Comment field that is affected here. IIRC, GnuPG uses 
> non-us-ascii characters for the version header if localized, too.

This field is not anymore subject to localization.

> 2. An implementation allowing full UTF-8 in the Armor Headers indirectly 
> violates rfc3156.

An rfc3156 implementation can simply strip the armor headers - they
are of no use.  I don't think that this is an OpenPGP issue.

If we would start to straighten the language, there are a lot more
places where this would be due.  Better keep it as it is and get the
implementations right.

  Werner




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UGBIG12175 for ietf-openpgp-bks; Tue, 30 Apr 2002 09:11:18 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UGBGa12170 for <[e-mail]>; Tue, 30 Apr 2002 09:11:16 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (ppp36-205.hrz.uni-bielefeld.de [129.70.36.205]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]> for [e-mail]; Tue, 30 Apr 2002 18:11:16 +0200 (MET DST)
Date: Tue, 30 Apr 2002 17:09:32 +0200
From: Marc Mutz <[e-mail]>
Subject: bis05: Armor Headers
To: [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: Text/Plain; charset=us-ascii
Content-description: clearsigned data
Content-disposition: inline
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I've looked through bis05 and I think the wording on non-US-ASCII characters 
in armor headers is still too vague.

1. It's not only the Comment field that is affected here. IIRC, GnuPG uses 
non-us-ascii characters for the version header if localized, too.
2. An implementation allowing full UTF-8 in the Armor Headers indirectly 
violates rfc3156.

I'd really like to see that Armor Headers MUST (at least SHOULD) be 
constrained to US-ASCII, except in clearsigning, where the full UTF-8 may be 
used since the enclosed text is already UTF-8.

The other way round: If exporting keys with armor or creating an armored 
detached signature, all armor headers MUST be constrained to US-ASCII.

AFAISI, this should suffice for the rfc3156 cases.

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE8zrOs3oWD+L2/6DgRAiMJAKC+QI2vB6OKGDrUfYNaCQiHidgAegCg0/+f
xm4OYZyplIJvDf14SdtVL5Y=
=2vJf
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TBqDf24358 for ietf-openpgp-bks; Mon, 29 Apr 2002 04:52:13 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TBqCa24354 for <[e-mail]>; Mon, 29 Apr 2002 04:52:12 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24701; Mon, 29 Apr 2002 07:52:10 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-05.txt
Date: Mon, 29 Apr 2002 07:52:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-05.txt
	Pages		: 71
	Date		: 26-Apr-02
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3SNvX707932 for ietf-openpgp-bks; Sun, 28 Apr 2002 16:57:33 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3SNvWa07928 for <[e-mail]>; Sun, 28 Apr 2002 16:57:32 -0700 (PDT)
Received: from [63.73.97.181] (63.73.97.181) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for <[e-mail]>; Sun, 28 Apr 2002 16:57:27 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Sun, 28 Apr 2002 16:52:22 -0700
Subject: Re: Notary signatures
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <v03110718b8eefb72daca@[67.242.199.92]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>> Note that you still cannot change the document, because to change the
>> document you would need to change the signature (unless you break the
>> Hash function).  If you change the signature, then the notary
>> signature fails.  Therefore, transitively, the notary is verifying
>> the document.

I actually disagree with this. The notary is putting a signature on a chunk
of data. The signature means, "I saw this at time T." If that data, a
signature, verifies against a document, *we* may deduce certain things about
that document using the two signatures. But the notary says nothing about
the integrity of the document.

This is a subtle point, but one about the semantics of transitivity.

If Alice says, "A -> B" and Bob says "B -> C", then I might (modulo many
details) deduce that A -> C using both data from Alice and Bob.

However, this is something that *I* am doing, not something Alice nor Bob is
doing. Alice says nothing about C. Bob says nothing about A. I put them both
together. Not Alice, not Bob.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3SEdIA25941 for ietf-openpgp-bks; Sun, 28 Apr 2002 07:39:18 -0700 (PDT)
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3SEdFa25937 for <[e-mail]>; Sun, 28 Apr 2002 07:39:17 -0700 (PDT)
Received: from 1cust5.tnt18.bos2.da.uu.net ([67.242.199.5]) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 171pp0-0000Y3-00; Sun, 28 Apr 2002 07:38:38 -0700
X-Sender: [e-mail]
Message-Id: <v03110718b8eefb72daca@[67.242.199.92]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 26 Apr 2002 08:46:08 -0400
To: Derek Atkins <[e-mail]>, Jon Callas <[e-mail]>
From: Bill Frantz <[e-mail]>
Subject: Re: Notary signatures
Cc: OpenPGP <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 11:21 PM -0400 4/25/02, Derek Atkins wrote:
>Jon Callas <[e-mail]> writes:
>
>> On 4/25/2002 5:54 PM, "Len Sassaman" <[e-mail]> wrote:
>>
>> > I'd like to be able to run a service wherein a user submits a signed
>> > document, and the service signs the signature. This is done to allow for
>> > verification that the signature was made prior to the timestamp provided
>> > by my service (the trusted notary).
>>
>> Not the document, only the signature packet? I'm trying to envision what one
>> would do with this mechanically, as well as syntactically and semantically.
>
>Yes.  The notary verifies the signature, and then signs the
>_signature_, not the document.  This is why it's a signature on a
>signature.  The notary is trusted to have verified the contents before
>it actually creates the new signature.

The notary doesn't need to verify the original signature.  Operationally,
the notary doesn't need to ever see the document, only the signature on the
document.  This lack of "need to know" seems to me to be an advantage for
confidential documents.


>
>Note that you still cannot change the document, because to change the
>document you would need to change the signature (unless you break the
>Hash function).  If you change the signature, then the notary
>signature fails.  Therefore, transitively, the notary is verifying
>the document.

Which is what happens if the original signature doesn't match the document.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
[phone]         | DMCA/CBDTPA is to      | 16345 Englewood Ave.
[e-mail] | prevent fair use.      | Los Gatos, CA 95032, USA




Received: by above.proper.com (8.11.6/8.11.3) id g3QKlHn17323 for ietf-openpgp-bks; Fri, 26 Apr 2002 13:47:17 -0700 (PDT)
Received: from hotmail.com (oe43.law3.hotmail.com [209.185.240.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QKlFa17319 for <[e-mail]>; Fri, 26 Apr 2002 13:47:15 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Apr 2002 13:47:13 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Musings on Notary signatures
Date: Fri, 26 Apr 2002 16:34:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 26 Apr 2002 20:47:13.0701 (UTC) FILETIME=[8B425550:01C1ED63]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

----- Original Message -----
From: "Jon Callas" <[e-mail]>
To: "vedaal" <[e-mail]>; "OpenPGP" <[e-mail]>
Sent: Friday, April 26, 2002 3:48 PM
Subject: Re: Musings on Notary signatures
...
> I don't see why this is a problem. Let's suppose I'm the notary and Alice
> hands me a signature that she produced in 1972. I notarize it. Big deal.
> It's 12:40pm on Friday, 26 April 2002. If you want to believe Alice's
date,
> why do you need mine?
>
> A savvy receiver of both signatures will decide that the correct timestamp
> for the document is within epsilon of my time, not Alice's.
...
It's not really a problem, but consider:

Alice is a stockbroker, Bob is a day-trader,
Bob needs a stock bought or sold at a certain time, which changes quickly in
value throughout the day.

With the notary as a simultaneous cc recipient and sender, it can add a time
verification to the transaction.

just a suggestion for a practical application at the user end.

-vedaal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QJmTQ16197 for ietf-openpgp-bks; Fri, 26 Apr 2002 12:48:29 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QJmSa16193 for <[e-mail]>; Fri, 26 Apr 2002 12:48:28 -0700 (PDT)
Received: from [192.168.1.20] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Fri, 26 Apr 2002 12:48:25 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Fri, 26 Apr 2002 12:48:26 -0700
Subject: Re: Musings on Notary signatures
From: Jon Callas <[e-mail]>
To: vedaal <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/26/2002 9:00 AM, "vedaal" <[e-mail]> wrote:

> There is still a problem with all this, in that it can verify only that the
> signature was notarized at a certain time.
> Nothing prevents the original signers from altering their computer clocks to
> later or earlier as would suit them,
> and then delay sending the signed message for notarization.

I don't see why this is a problem. Let's suppose I'm the notary and Alice
hands me a signature that she produced in 1972. I notarize it. Big deal.
It's 12:40pm on Friday, 26 April 2002. If you want to believe Alice's date,
why do you need mine?

A savvy receiver of both signatures will decide that the correct timestamp
for the document is within epsilon of my time, not Alice's. (And if you
think my clock is wrong, then just get another notarized signature, or
notarize the darn thing yourself, and use *that* timestamp.)

All you have to do is assign reasonable semantics and procedures to
something. The semantic meaning of a notary signature is merely, "I saw it
at time T." It is a certification of sorts. It certifies not a name, but a
timestamp. Apply whatever trust model you like best to that signature.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3QJKVp15611 for ietf-openpgp-bks; Fri, 26 Apr 2002 12:20:31 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QJKTa15606 for <[e-mail]>; Fri, 26 Apr 2002 12:20:29 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3QJIvd00788; Fri, 26 Apr 2002 15:18:57 -0400
Date: Fri, 26 Apr 2002 15:18:57 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Musings on Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Full
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Apr 26, 2002 at 02:17:03PM -0500, [e-mail] wrote:

> And, he would need a standard way to put the serial number into the
> proposed 0x50 packet.

Signature notation subpacket.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3QJHFD15553 for ietf-openpgp-bks; Fri, 26 Apr 2002 12:17:15 -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 g3QJH7a15548 for <[e-mail]>; Fri, 26 Apr 2002 12:17:07 -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 g3QJHNK09328; Fri, 26 Apr 2002 15:17:23 -0400 (EDT)
Subject: Re: Musings on Notary signatures
To: [e-mail]
Cc: [e-mail], [e-mail]
From: [e-mail]
Date: Fri, 26 Apr 2002 14:17:03 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/26/2002 03:17:05 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

So if I understand http://www.itconsult.co.uk/stamper/stampinf.htm, it adds
another signature in parelell to existing signatures when in "pgp mode".
With this new proposal, he would simply use the new sig type, with the
referring field being the main message.  A new service not listed there
would be to verify that the existing signatures were made at the specified
time, and to do that the referring field would refer to the other signature
block.  To do that the existing way, you would stamp your detached
signature in "clear" mode, so he signs your signature record.

And, he would need a standard way to put the serial number into the
proposed 0x50 packet.





David Shaw <[e-mail]> on 04-26-2002 11:18:30 AM

To:   [e-mail]
cc:   [e-mail]
Subject:  Re: Musings on Notary signatures


On Fri, Apr 26, 2002 at 10:12:57AM -0500, [e-mail] wrote:
> However, the above allows for another feature.  The document produced by
> the notary can contain other information too, to implement things from
> section 4.1 of Applied Cryptography.  For example, it can contain a
serial
> number, so someone who doesn't trust Trent's clock can find other
documents
> and know what order they were signed in (hmm, why would you trust Trent's
> counter but not his clock?), lists of other "before" and "after"
customers,
> or other verification information that can be used to validate the
> timestamp in other ways, without the need for a trusted notary to have
> produced the timestamp signature.

This is essentially what the notary service at
http://www.itconsult.co.uk/stamper.htm does with serial numbers.  One
can use a signature notation to do the same thing with the proposed
notary signature as well.

As a receipient of such a message, I think I would prefer the proposed
notary signature.  It is in a well specified and understood machine
readable format, so anyone can verify any notary signature with a
minimum of fuss and/or new code.

David

--
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+

   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson







Received: by above.proper.com (8.11.6/8.11.3) id g3QGkbR11726 for ietf-openpgp-bks; Fri, 26 Apr 2002 09:46:37 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QGkaa11722 for <[e-mail]>; Fri, 26 Apr 2002 09:46:36 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3QGkdQ09962 for [e-mail]; Fri, 26 Apr 2002 09:46:39 -0700
Date: Fri, 26 Apr 2002 09:46:39 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Notary signatures
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I don't think we have had to hash a signature packet before.  That means
that we have to canonicalize the header.  Following our wonderful OpenPGP
tradition, we of course have completely different canonicalization rules
for key and userid packets.  Here is what we do for userids:

   A certification signature (type 0x10 through 0x13) hashes the user id
   being bound to the key into the hash context after the above data. A
   V3 certification hashes the contents of the name packet, without any
   header. A V4 certification hashes the constant 0xb4 (which is an
   old-style packet header with the length-of-length set to zero), a
   four-octet number giving the length of the username, and then the
   username data.

I suppose we want to follow the same rules as the V4 case, for signature
packets.  We would hash the constant 0x84 (an old-style packet header
with length-of-length set to zero), a four-octet length, and then the
packet contents.  Since sigs-on-sigs need a target subpacket, it would
not be legal to do a V3 sig on a sig.  So we only need to consider the
V4 case.

BTW I notice we don't say here how to hash attribute packets.  In the NAI
PGP code we do as above except instead of the constant 0xb4 we use 0xd1,
a new-style packet header for attribute packets.  If the signature is a
V3 certification on the attribute packet we do as with userid packets,
and just hash the contents, without hashing the packet header.  That was
probably a mistake; since we had no need for backwards compatibility
with V3 sigs on attribute packets, we should have used the V4 rules for
both V3 and V4 signatures.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g3QGLo511104 for ietf-openpgp-bks; Fri, 26 Apr 2002 09:21:50 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QGLna11100 for <[e-mail]>; Fri, 26 Apr 2002 09:21:49 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3QGIUj08513; Fri, 26 Apr 2002 12:18:30 -0400
Date: Fri, 26 Apr 2002 12:18:30 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Musings on Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Apr 26, 2002 at 10:12:57AM -0500, [e-mail] wrote:
> However, the above allows for another feature.  The document produced by
> the notary can contain other information too, to implement things from
> section 4.1 of Applied Cryptography.  For example, it can contain a serial
> number, so someone who doesn't trust Trent's clock can find other documents
> and know what order they were signed in (hmm, why would you trust Trent's
> counter but not his clock?), lists of other "before" and "after" customers,
> or other verification information that can be used to validate the
> timestamp in other ways, without the need for a trusted notary to have
> produced the timestamp signature.

This is essentially what the notary service at
http://www.itconsult.co.uk/stamper.htm does with serial numbers.  One
can use a signature notation to do the same thing with the proposed
notary signature as well.

As a receipient of such a message, I think I would prefer the proposed
notary signature.  It is in a well specified and understood machine
readable format, so anyone can verify any notary signature with a
minimum of fuss and/or new code.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3QG5qw09687 for ietf-openpgp-bks; Fri, 26 Apr 2002 09:05:52 -0700 (PDT)
Received: from hotmail.com (oe67.law3.hotmail.com [209.185.240.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QG5pa09681 for <[e-mail]>; Fri, 26 Apr 2002 09:05:51 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Apr 2002 09:04:48 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Musings on Notary signatures
Date: Fri, 26 Apr 2002 12:00:57 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 26 Apr 2002 16:04:48.0284 (UTC) FILETIME=[1700E5C0:01C1ED3C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, April 26, 2002 11:12 AM
Subject: Musings on Notary signatures


>
>
> From: John Dlugosz
>
> The normal interpretation of signing something is to agree with or assert
> its content.  If that's the only kind we have, we can do this:
>
> I sign my document.  Then to prove I did so at a specific time, send the
> signature (which may include the data or be detached, it matters not) to
> the notary.
>
> The notary produces a =new= document, which states "I afferm that the blob
> sent to me (length nn, SHA1=xxxxxxx) was done so at whatever time." and
> signs (afferms to) that.
>
> A notary sig packet would do the same thing, but could be added to the
file
> containing the signature being signed.  I beleive that is what the current
> discussion has agreed on.
>
> However, the above allows for another feature.  The document produced by
> the notary can contain other information too, to implement things from
> section 4.1 of Applied Cryptography.  For example, it can contain a serial
> number, so someone who doesn't trust Trent's clock can find other
documents
> and know what order they were signed in (hmm, why would you trust Trent's
> counter but not his clock?), lists of other "before" and "after"
customers,
> or other verification information that can be used to validate the
> timestamp in other ways, without the need for a trusted notary to have
> produced the timestamp signature.

There is still a problem with all this, in that it can verify only that the
signature was notarized at a certain time.
Nothing prevents the original signers from altering their computer clocks to
later or earlier as would suit them,
and then delay sending the signed message for notarization.
A possible practical solution at the user end, might be something as
follows:

Alice sends Bob a document for review, with instructions that when Bob is re
ady to sign it, Bob should send it
signed to Alice, and cc at the same time to an agreed-upon notary, for time
stamping, who would then cc it back,
already notarized/timestamped  to Alice and Bob.

vedaal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QFDHt06842 for ietf-openpgp-bks; Fri, 26 Apr 2002 08:13:17 -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 g3QFDCa06838 for <[e-mail]>; Fri, 26 Apr 2002 08:13:13 -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 g3QFDGK27353; Fri, 26 Apr 2002 11:13:16 -0400 (EDT)
Subject: Musings on Notary signatures
To: [e-mail]
Cc: [e-mail], [e-mail]
From: [e-mail]
Date: Fri, 26 Apr 2002 10:12:57 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/26/2002 11:12:57 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

The normal interpretation of signing something is to agree with or assert
its content.  If that's the only kind we have, we can do this:

I sign my document.  Then to prove I did so at a specific time, send the
signature (which may include the data or be detached, it matters not) to
the notary.

The notary produces a =new= document, which states "I afferm that the blob
sent to me (length nn, SHA1=xxxxxxx) was done so at whatever time." and
signs (afferms to) that.

A notary sig packet would do the same thing, but could be added to the file
containing the signature being signed.  I beleive that is what the current
discussion has agreed on.

However, the above allows for another feature.  The document produced by
the notary can contain other information too, to implement things from
section 4.1 of Applied Cryptography.  For example, it can contain a serial
number, so someone who doesn't trust Trent's clock can find other documents
and know what order they were signed in (hmm, why would you trust Trent's
counter but not his clock?), lists of other "before" and "after" customers,
or other verification information that can be used to validate the
timestamp in other ways, without the need for a trusted notary to have
produced the timestamp signature.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QDXfI02766 for ietf-openpgp-bks; Fri, 26 Apr 2002 06:33:41 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QDXea02758 for <[e-mail]>; Fri, 26 Apr 2002 06:33:40 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA01131; Fri, 26 Apr 2002 09:33:40 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA10903; Fri, 26 Apr 2002 09:33:40 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA22562; Fri, 26 Apr 2002 09:33:39 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA19191; Fri, 26 Apr 2002 09:33:39 -0400 (EDT)
To: David Shaw <[e-mail]>, Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
From: Derek Atkins <[e-mail]>
Subject: Re: Notary signatures
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: 26 Apr 2002 09:33:39 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 36
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw <[e-mail]> writes:

> This is interesting, as I had been thinking of a service that did not
> verify the contents of the original document before notarizing the
> signature.  This service would purely be to validate the timestamp
> (and other data) in the original signature, so no need to send the
> original document which may be sensitive.

Well, there are certainly multiple services available.  You are
correct that validating the signature is not a requirement.

Jon Callas <[e-mail]> writes:

> I like the idea of a notary signature that only signs a signature packet.
> This would mean your signer doesn't even need to see the document that's
> being notarized, which has a certain panache to it.

*smiles*

> How about if I do this:
> 
> * Write up a description of a notary signature.
> 
> * Change the "revocation target" subpacket to be a "signature target"
> subpacket so it can work double duty
> 
> How's that sound?

Sounds good to me.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QBJx628399 for ietf-openpgp-bks; Fri, 26 Apr 2002 04:19:59 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QBJwa28393 for <[e-mail]>; Fri, 26 Apr 2002 04:19:58 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3QBIqh05415; Fri, 26 Apr 2002 07:18:52 -0400
Date: Fri, 26 Apr 2002 07:18:52 -0400
From: David Shaw <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Apr 25, 2002 at 10:31:00PM -0700, Jon Callas wrote:
> 
> I like the idea of a notary signature that only signs a signature packet.
> This would mean your signer doesn't even need to see the document that's
> being notarized, which has a certain panache to it.
> 
> How about if I do this:
> 
> * Write up a description of a notary signature.
> 
> * Change the "revocation target" subpacket to be a "signature target"
> subpacket so it can work double duty
> 
> How's that sound?

Excellent.  That would work quite well for me.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3Q8fwI14538 for ietf-openpgp-bks; Fri, 26 Apr 2002 01:41:58 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q8fta14534 for <[e-mail]>; Fri, 26 Apr 2002 01:41:56 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17124P-0008Nr-00; Fri, 26 Apr 2002 11:31:13 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 1711JD-0005PE-00; Fri, 26 Apr 2002 10:42:27 +0200
To: OpenPGP <[e-mail]>
Subject: Re: Notary signatures
References: <[e-mail]>
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est.
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Fri, 26 Apr 2002 10:42:27 +0200
In-Reply-To: <[e-mail]> (Jon Callas's message of "Thu, 25 Apr 2002 22:31:00 -0700")
Message-ID: <[e-mail]>
Lines: 17
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 25 Apr 2002 22:31:00 -0700, Jon Callas said:

> I like the idea of a notary signature that only signs a signature packet.
> This would mean your signer doesn't even need to see the document that's
> being notarized, which has a certain panache to it.

I like this. 

> * Change the "revocation target" subpacket to be a "signature target"
> subpacket so it can work double duty

Make it mandatory (SHOULD) for timestamp signatures so that already
existing 0x40 signature packets can be distinguished (or ignored) from
the new well defined timestamp/notary signatures.  I don't think there
is a reason to add a special 0x50 notary signature then.

  Werner



Received: by above.proper.com (8.11.6/8.11.3) id g3Q6r7E28986 for ietf-openpgp-bks; Thu, 25 Apr 2002 23:53:07 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q6r5a28978 for <[e-mail]>; Thu, 25 Apr 2002 23:53:06 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id XAA23113; Thu, 25 Apr 2002 23:53:02 -0700
Date: Thu, 25 Apr 2002 23:53:02 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: Jon Callas <[e-mail]>
cc: OpenPGP <[e-mail]>
Subject: Re: Notary signatures
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 25 Apr 2002, Jon Callas wrote:

>
> I like the idea of a notary signature that only signs a signature packet.
> This would mean your signer doesn't even need to see the document that's
> being notarized, which has a certain panache to it.
>
> How about if I do this:
>
> * Write up a description of a notary signature.
>
> * Change the "revocation target" subpacket to be a "signature target"
> subpacket so it can work double duty
>
> How's that sound?

Sounds great to me. Would work perfectly for what I want to do.


--Len.











Received: by above.proper.com (8.11.6/8.11.3) id g3Q5XBx18359 for ietf-openpgp-bks; Thu, 25 Apr 2002 22:33:11 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q5XAa18355 for <[e-mail]>; Thu, 25 Apr 2002 22:33:10 -0700 (PDT)
Received: from [63.73.97.185] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for <[e-mail]>; Thu, 25 Apr 2002 22:33:14 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 22:31:00 -0700
Subject: Re: Notary signatures
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I like the idea of a notary signature that only signs a signature packet.
This would mean your signer doesn't even need to see the document that's
being notarized, which has a certain panache to it.

How about if I do this:

* Write up a description of a notary signature.

* Change the "revocation target" subpacket to be a "signature target"
subpacket so it can work double duty

How's that sound?

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3Q4HIi17176 for ietf-openpgp-bks; Thu, 25 Apr 2002 21:17:18 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q4HHa17172 for <[e-mail]>; Thu, 25 Apr 2002 21:17:17 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3Q4GlH02759 for [e-mail]; Fri, 26 Apr 2002 00:16:47 -0400
Date: Fri, 26 Apr 2002 00:16:47 -0400
From: David Shaw <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Apr 25, 2002 at 11:21:43PM -0400, Derek Atkins wrote:
> 
> Jon Callas <[e-mail]> writes:
> 
> > On 4/25/2002 5:54 PM, "Len Sassaman" <[e-mail]> wrote:
> > 
> > > I'd like to be able to run a service wherein a user submits a signed
> > > document, and the service signs the signature. This is done to allow for
> > > verification that the signature was made prior to the timestamp provided
> > > by my service (the trusted notary).
> > 
> > Not the document, only the signature packet? I'm trying to
> > envision what one would do with this mechanically, as well as
> > syntactically and semantically.
> 
> Yes.  The notary verifies the signature, and then signs the
> _signature_, not the document.  This is why it's a signature on a
> signature.  The notary is trusted to have verified the contents before
> it actually creates the new signature.

This is interesting, as I had been thinking of a service that did not
verify the contents of the original document before notarizing the
signature.  This service would purely be to validate the timestamp
(and other data) in the original signature, so no need to send the
original document which may be sensitive.

In notary talk (at least US notary talk), this is somewhat similar to
what is called an "acknowledgement"[1] - the notary taking note that a
document was signed, and affixing a seal to indicate that.  Nothing in
the actual document is relevant in an acknowledgement - just that it
was signed and the signer requested a notary to note that fact.

> Note that you still cannot change the document, because to change the
> document you would need to change the signature (unless you break the
> Hash function).  If you change the signature, then the notary
> signature fails.  Therefore, transitively, the notary is verifying
> the document.

Yes.

David

[1] Not an exact match - an acknowledgement generally also has the
    statement that the signature was a voluntary act by the signer.
    I don't think there is an algorithm for that. :)

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3Q3LlL16184 for ietf-openpgp-bks; Thu, 25 Apr 2002 20:21:47 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q3Lja16180 for <[e-mail]>; Thu, 25 Apr 2002 20:21:45 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA03862; Thu, 25 Apr 2002 23:21:47 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA13473; Thu, 25 Apr 2002 23:21:46 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA25531; Thu, 25 Apr 2002 23:21:44 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA17951; Thu, 25 Apr 2002 23:21:44 -0400 (EDT)
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
From: Derek Atkins <[e-mail]>
Subject: Re: Notary signatures
References: <[e-mail]>
Date: 25 Apr 2002 23:21:43 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 33
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> writes:

> On 4/25/2002 5:54 PM, "Len Sassaman" <[e-mail]> wrote:
> 
> > I'd like to be able to run a service wherein a user submits a signed
> > document, and the service signs the signature. This is done to allow for
> > verification that the signature was made prior to the timestamp provided
> > by my service (the trusted notary).
> 
> Not the document, only the signature packet? I'm trying to envision what one
> would do with this mechanically, as well as syntactically and semantically.

Yes.  The notary verifies the signature, and then signs the
_signature_, not the document.  This is why it's a signature on a
signature.  The notary is trusted to have verified the contents before
it actually creates the new signature.

Note that you still cannot change the document, because to change the
document you would need to change the signature (unless you break the
Hash function).  If you change the signature, then the notary
signature fails.  Therefore, transitively, the notary is verifying
the document.

At least, this was the theory we had when wrtiing 1991.

>     Jon

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: by above.proper.com (8.11.6/8.11.3) id g3Q28ab14631 for ietf-openpgp-bks; Thu, 25 Apr 2002 19:08:36 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q28Za14625 for <[e-mail]>; Thu, 25 Apr 2002 19:08:35 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3Q23Ex01767; Thu, 25 Apr 2002 22:03:14 -0400
Date: Thu, 25 Apr 2002 22:03:14 -0400
From: David Shaw <[e-mail]>
To: Hal Finney <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: Hal Finney <[e-mail]>, [e-mail], [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (98% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Apr 25, 2002 at 06:27:39PM -0700, Hal Finney wrote:
> If you're going to do a notary signature, you'd probably need something
> like that "target signature" subpacket we talked about for revocation
> signatures, right?

Yes, I was thinking that as well.  The subpacket would be useful for
those cases when the intended target was not obvious from the context.
It would need a different name than "revocation target", though :)

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3Q1tHa14470 for ietf-openpgp-bks; Thu, 25 Apr 2002 18:55:17 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q1tFa14466 for <[e-mail]>; Thu, 25 Apr 2002 18:55:15 -0700 (PDT)
Received: from [63.73.97.185] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Thu, 25 Apr 2002 18:55:19 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 18:55:19 -0700
Subject: Re: Timestamp Signatures (was Re: Notary signatures)
From: Jon Callas <[e-mail]>
To: David Shaw <[e-mail]>
CC: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/25/2002 6:18 PM, "David Shaw" <[e-mail]> wrote:

> A regular 0x00 or 0x01 signature has no defined meaning, so it can
> therefore mean anything the signer and recepient agree on it to mean.

Or what a litigant can convince a judge or jury that any reasonable person
would have thought it to mean. That's the downside of no defined meaning in
a world where there are laws about what signatures mean.

> The 0x40 is just like these signatures except that it is has the
> defined meaning of "timestamp". ?  Ok, I get it.  I imagine this is
> something that if done today would be done with a signature notation.
> 
> Is it possible to get some language in the draft saying what an 0x40
> signature is issued on (binary or canonical text data)?

All signatures are on binary content. A text-mode signature is on binary
content that conforms to some rules. Or so I think. :-)

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3Q1mME14342 for ietf-openpgp-bks; Thu, 25 Apr 2002 18:48:22 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q1mLa14338 for <[e-mail]>; Thu, 25 Apr 2002 18:48:21 -0700 (PDT)
Received: from [63.73.97.185] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Thu, 25 Apr 2002 18:48:24 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 18:48:24 -0700
Subject: Re: Notary signatures
From: Jon Callas <[e-mail]>
To: Hal Finney <[e-mail]>, <[e-mail]>
CC: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/25/2002 6:27 PM, "Hal Finney" <[e-mail]> wrote:

> 
> If you're going to do a notary signature, you'd probably need something
> like that "target signature" subpacket we talked about for revocation
> signatures, right?

The target subpacket is in the draft that is presently on the editor's desk.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3Q1RmE14082 for ietf-openpgp-bks; Thu, 25 Apr 2002 18:27:48 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q1Rka14075 for <[e-mail]>; Thu, 25 Apr 2002 18:27:46 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3Q1RdG04901; Thu, 25 Apr 2002 18:27:39 -0700
Date: Thu, 25 Apr 2002 18:27:39 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Notary signatures
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

If you're going to do a notary signature, you'd probably need something
like that "target signature" subpacket we talked about for revocation
signatures, right?

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g3Q1J5g13811 for ietf-openpgp-bks; Thu, 25 Apr 2002 18:19:05 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q1J4a13807 for <[e-mail]>; Thu, 25 Apr 2002 18:19:04 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3Q1IrT01410; Thu, 25 Apr 2002 21:18:53 -0400
Date: Thu, 25 Apr 2002 21:18:53 -0400
From: David Shaw <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Timestamp Signatures (was Re: Notary signatures)
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (98% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Apr 25, 2002 at 05:58:35PM -0700, Jon Callas wrote:
> Here's what I believe timestamp signatures are for --
> 
> The hard problem in digital signatures is knowing what they mean. The
> semantic content of the signature. Lots of ink has been spilled on this.
> 
> The 0x40 timestamp signature is a semantic notation. What it says is "I saw
> this blob of data at time T. I know nothing more nor assert nothing other
> than I saw it at that time."
> 
> It is thus a way for an entity to do nothing but -- well, timestamp it.

A regular 0x00 or 0x01 signature has no defined meaning, so it can
therefore mean anything the signer and recepient agree on it to mean.
The 0x40 is just like these signatures except that it is has the
defined meaning of "timestamp". ?  Ok, I get it.  I imagine this is
something that if done today would be done with a signature notation.

Is it possible to get some language in the draft saying what an 0x40
signature is issued on (binary or canonical text data)?

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3Q193913560 for ietf-openpgp-bks; Thu, 25 Apr 2002 18:09:03 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q192a13556 for <[e-mail]>; Thu, 25 Apr 2002 18:09:02 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3Q18o301348; Thu, 25 Apr 2002 21:08:50 -0400
Date: Thu, 25 Apr 2002 21:08:50 -0400
From: David Shaw <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (98% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Apr 25, 2002 at 05:27:37PM -0700, Jon Callas wrote:
> So -- what are you going to do with them? Why do you need it? I'd like to
> move towards getting a new RFC soon, so explain what you want, and lets get
> a rough consensus of the group that it's a good idea. If we get that, I'll
> put it in.

Well, I'll let Len speak for what he is planning, but for me, it's
come up a number of times in the context of timestamping services.
There is no way to really trust the timestamp in a signature since the
maker of the signature can use whatever timestamp that suits them.  A
notary service can "guarantee" that signature by signing the
signature, and multiple independent notary services can be used to add
even more assurance that there is no collusion.  I have heard that
this was the intended use of the old notary signature.

Using a different type (0x50 is fine) for this is not strictly
required, but would be very useful on the validation side to know that
when you come across such a packet you are going to be looking for
another signature to check against it.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3Q12Aq13498 for ietf-openpgp-bks; Thu, 25 Apr 2002 18:02:10 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q129a13494 for <[e-mail]>; Thu, 25 Apr 2002 18:02:09 -0700 (PDT)
Received: from [192.168.1.23] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for <[e-mail]>; Thu, 25 Apr 2002 18:02:12 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 18:02:10 -0700
Subject: Re: Notary signatures
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/25/2002 5:54 PM, "Len Sassaman" <[e-mail]> wrote:

> I'd like to be able to run a service wherein a user submits a signed
> document, and the service signs the signature. This is done to allow for
> verification that the signature was made prior to the timestamp provided
> by my service (the trusted notary).

Not the document, only the signature packet? I'm trying to envision what one
would do with this mechanically, as well as syntactically and semantically.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3Q0wb613431 for ietf-openpgp-bks; Thu, 25 Apr 2002 17:58:37 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q0waa13427 for <[e-mail]>; Thu, 25 Apr 2002 17:58:36 -0700 (PDT)
Received: from [192.168.1.23] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Thu, 25 Apr 2002 17:58:38 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 17:58:35 -0700
Subject: Timestamp Signatures (was Re: Notary signatures)
From: Jon Callas <[e-mail]>
To: David Shaw <[e-mail]>
CC: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Here's what I believe timestamp signatures are for --

The hard problem in digital signatures is knowing what they mean. The
semantic content of the signature. Lots of ink has been spilled on this.

The 0x40 timestamp signature is a semantic notation. What it says is "I saw
this blob of data at time T. I know nothing more nor assert nothing other
than I saw it at that time."

It is thus a way for an entity to do nothing but -- well, timestamp it.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3Q0sOL13359 for ietf-openpgp-bks; Thu, 25 Apr 2002 17:54:24 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q0sMa13352 for <[e-mail]>; Thu, 25 Apr 2002 17:54:22 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id RAA08914; Thu, 25 Apr 2002 17:54:21 -0700
Date: Thu, 25 Apr 2002 17:54:21 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: Jon Callas <[e-mail]>
cc: David Shaw <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: Notary signatures
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 25 Apr 2002, Jon Callas wrote:

> So -- what are you going to do with them? Why do you need it? I'd like to
> move towards getting a new RFC soon, so explain what you want, and lets get
> a rough consensus of the group that it's a good idea. If we get that, I'll
> put it in.

I'd like to be able to run a service wherein a user submits a signed
document, and the service signs the signature. This is done to allow for
verification that the signature was made prior to the timestamp provided
by my service (the trusted notary).

--Len.











Received: by above.proper.com (8.11.6/8.11.3) id g3Q0Xrd13080 for ietf-openpgp-bks; Thu, 25 Apr 2002 17:33:53 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q0Xqa13076 for <[e-mail]>; Thu, 25 Apr 2002 17:33:52 -0700 (PDT)
Received: from [192.168.1.23] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Thu, 25 Apr 2002 17:33:46 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 17:27:37 -0700
Subject: Re: Notary signatures
From: Jon Callas <[e-mail]>
To: David Shaw <[e-mail]>
CC: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/25/2002 5:05 PM, "David Shaw" <[e-mail]> wrote:

> As I see it, all signatures can have a timestamp, so really any of
> them is usable for a timestamp signature.  I'm not sure how 0x40
> differs here, as it doesn't seem clear what 0x40 is a signature on.
> If it is on binary data, then we have a type for that already.  If it
> is on textual data, we have a type for that as well.  We even have a
> type for a standalone signature-on-nothing "token".
> 
> A notary signature does not have to be class 0x40, but since 0x40 was
> intended for this in the past, and (as far as I can see) does not
> serve a purpose that other signature types cannot already provide, why
> not make it 0x40?

0x40 was added in as a timestamp signature after the unused types were all
removed. As I remember, Lutz Donnerhacke was going to be using it, and I
think other people are as well.

I'm not going to overload timestamps with notary signatures. That's a bad
idea. If we decide to put notary signatures back in, they'll get a new
number. RFC 1991 was only ever informational, and is dead as far as we're
concerned. (And no one ever implemented that.) 0x50 is a fine number.

So -- what are you going to do with them? Why do you need it? I'd like to
move towards getting a new RFC soon, so explain what you want, and lets get
a rough consensus of the group that it's a good idea. If we get that, I'll
put it in.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3Q05VD12672 for ietf-openpgp-bks; Thu, 25 Apr 2002 17:05:31 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3Q05Ua12668 for <[e-mail]>; Thu, 25 Apr 2002 17:05:30 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3Q05RV00885; Thu, 25 Apr 2002 20:05:27 -0400
Date: Thu, 25 Apr 2002 20:05:27 -0400
From: David Shaw <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (98% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Apr 25, 2002 at 04:49:46PM -0700, Jon Callas wrote:
> On 4/25/2002 3:07 PM, "David Shaw" <[e-mail]> wrote:
> 
> > RFC-1991 defined sigclass 0x40 as a timestamp, and went on to further
> > explain its intended use ("Type <40> is intended to be a signature of
> > a signature, as a notary seal on a signed document.")
> > 
> > When RFC-2440 came out, this extra explanation seems to have been
> > lost, as 2440 defines 0x40 only as a timestamp.  A sigclass for a
> > signature on a signature would be very useful.  Any chance to restore
> > this clarification in the next draft?
> 
> It wasn't so much that it was lost, but that it was actively removed.
> 
> Only the document and certification signatures were ever implemented before
> 2440 came out. At one time, we removed all the definitions to simplify. Then
> they gradually crept back in. 0x40 became a timestamp because there were
> people who wanted to use it.
> 
> I may be wrong on this, but would it be better to introduce a new type if
> you want to do notaries? Or do this with a notation?

As I see it, all signatures can have a timestamp, so really any of
them is usable for a timestamp signature.  I'm not sure how 0x40
differs here, as it doesn't seem clear what 0x40 is a signature on.
If it is on binary data, then we have a type for that already.  If it
is on textual data, we have a type for that as well.  We even have a
type for a standalone signature-on-nothing "token".

A notary signature does not have to be class 0x40, but since 0x40 was
intended for this in the past, and (as far as I can see) does not
serve a purpose that other signature types cannot already provide, why
not make it 0x40?

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3PNnmS12493 for ietf-openpgp-bks; Thu, 25 Apr 2002 16:49:48 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PNnla12489 for <[e-mail]>; Thu, 25 Apr 2002 16:49:47 -0700 (PDT)
Received: from [192.168.1.23] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Thu, 25 Apr 2002 16:49:41 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 16:49:46 -0700
Subject: Re: Notary signatures
From: Jon Callas <[e-mail]>
To: David Shaw <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/25/2002 3:07 PM, "David Shaw" <[e-mail]> wrote:

> RFC-1991 defined sigclass 0x40 as a timestamp, and went on to further
> explain its intended use ("Type <40> is intended to be a signature of
> a signature, as a notary seal on a signed document.")
> 
> When RFC-2440 came out, this extra explanation seems to have been
> lost, as 2440 defines 0x40 only as a timestamp.  A sigclass for a
> signature on a signature would be very useful.  Any chance to restore
> this clarification in the next draft?

It wasn't so much that it was lost, but that it was actively removed.

Only the document and certification signatures were ever implemented before
2440 came out. At one time, we removed all the definitions to simplify. Then
they gradually crept back in. 0x40 became a timestamp because there were
people who wanted to use it.

I may be wrong on this, but would it be better to introduce a new type if
you want to do notaries? Or do this with a notation?

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3PNM2d11887 for ietf-openpgp-bks; Thu, 25 Apr 2002 16:22:02 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PNM0a11880 for <[e-mail]>; Thu, 25 Apr 2002 16:22:00 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id QAA05704; Thu, 25 Apr 2002 16:22:00 -0700
Date: Thu, 25 Apr 2002 16:22:00 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: David Shaw <[e-mail]>
cc: <[e-mail]>
Subject: Re: Notary signatures
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 25 Apr 2002, David Shaw wrote:

> RFC-1991 defined sigclass 0x40 as a timestamp, and went on to further
> explain its intended use ("Type <40> is intended to be a signature of
> a signature, as a notary seal on a signed document.")
>
> When RFC-2440 came out, this extra explanation seems to have been
> lost, as 2440 defines 0x40 only as a timestamp.  A sigclass for a
> signature on a signature would be very useful.  Any chance to restore
> this clarification in the next draft?

Yes, please. I plan to use this in a project in the not-so-distant future.

I know there are a few timestamping services for OpenPGP in operation
already -- are any of them using this now?


--Len.



Received: by above.proper.com (8.11.6/8.11.3) id g3PM7Km09912 for ietf-openpgp-bks; Thu, 25 Apr 2002 15:07:20 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PM7Ha09908 for <[e-mail]>; Thu, 25 Apr 2002 15:07:17 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3PM74j09864 for [e-mail]; Thu, 25 Apr 2002 18:07:04 -0400
Date: Thu, 25 Apr 2002 18:07:04 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Notary signatures
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (97% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

RFC-1991 defined sigclass 0x40 as a timestamp, and went on to further
explain its intended use ("Type <40> is intended to be a signature of
a signature, as a notary seal on a signed document.")

When RFC-2440 came out, this extra explanation seems to have been
lost, as 2440 defines 0x40 only as a timestamp.  A sigclass for a
signature on a signature would be very useful.  Any chance to restore
this clarification in the next draft?

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3PLUju09322 for ietf-openpgp-bks; Thu, 25 Apr 2002 14:30:45 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PLUia09318 for <[e-mail]>; Thu, 25 Apr 2002 14:30:44 -0700 (PDT)
Received: from [192.168.1.23] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for <[e-mail]>; Thu, 25 Apr 2002 14:30:38 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 25 Apr 2002 14:30:44 -0700
Subject: New Draft Gone Out
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I send another draft out. It should have all comments reflected in it. If I
missed something, let me know.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PJVxr06626 for ietf-openpgp-bks; Thu, 25 Apr 2002 12:31:59 -0700 (PDT)
Received: from guk1d002.glueckkanja.org ([62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PJVva06622 for <[e-mail]>; Thu, 25 Apr 2002 12:31:58 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Date: Thu, 25 Apr 2002 21:31:40 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Thread-Index: AcHnUoYOrLYxk6K3QoSA2qTQsI0NAwFPKakA
From: "Dominikus Scherkl" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3PJVxa06623
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi.

> The one other point I see is that as the number of recipients
increases,
> then a priori it becomes less likely that so many people would all
> collude to forge a message from Alice.  So although you have security
> in principle, the deniability becomes a little more questionable in
> practice when the number of recipients is large.
Of course this is so - like if you tell several people a "secret" and
later
want do dement it was you who straied this rumor...
-- 
Dominikus Scherkl
[e-mail]
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3NMjPN16784 for ietf-openpgp-bks; Tue, 23 Apr 2002 15:45:25 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NMjEa16779 for <[e-mail]>; Tue, 23 Apr 2002 15:45:14 -0700 (PDT)
Received: from [192.168.1.23] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Tue, 23 Apr 2002 15:45:10 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Tue, 23 Apr 2002 15:39:11 -0700
Subject: Re: Revocation target subpacket (Re: What's left before a new RFC?)
From: Jon Callas <[e-mail]>
To: Michael Young <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <00d501c1e66e$e3deb920$[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/17/2002 5:20 PM, "Michael Young" <[e-mail]> wrote:

> I still desire a "revocation target" subpacket to identify the
> specific signature being revoked...

In the immortal words of Rod Serling, submitted for your approval:

.head 4 Revocation Target

.block blank
(1 octet PK algorithm,
 1 octet hash algorithm,
 N octets hash)

This subpacket identifies a specific target signature that a revocation
signature revokes. This provides explicit designation of a revocation. All
arguments are an identifier of that signature.

The N octets of hash data MUST be the size of the hash of the signature. For
example, a target signature with a SHA-1 hash MUST have 20 octets of hash
data.




Received: by above.proper.com (8.11.6/8.11.3) id g3K7vWb23324 for ietf-openpgp-bks; Sat, 20 Apr 2002 00:57:32 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3K7vUb23318 for <[e-mail]>; Sat, 20 Apr 2002 00:57:30 -0700 (PDT)
Received: from [63.73.97.183] (63.73.97.183) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Sat, 20 Apr 2002 00:57:24 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Sat, 20 Apr 2002 00:53:50 -0700
Subject: Re: What's left before a new RFC?
From: Jon Callas <[e-mail]>
To: Florian Weimer <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/19/2002 11:47 PM, "Florian Weimer" <[e-mail]>
wrote:

> 3.2 is lacking a hint to implementors that the bit count feild for
> encrypted MPIs reflects the number of bits in the decrypted MPI (IOW,
> encrypted MPIs might not be well-formed as required by 3.2).
> 

Thank you. I wrote as the last paragraph of 3.2:

Also note that when an MPI is encrypted, the length refers to the plaintext
MPI. It may be ill-formed in its ciphertext.


> There's a formatting error in the second table of section 5.2.3.16.

Thanks. David Shaw also pointed that one out and it's fixed.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g3K6llg13929 for ietf-openpgp-bks; Fri, 19 Apr 2002 23:47:47 -0700 (PDT)
Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3K6ljb13925 for <[e-mail]>; Fri, 19 Apr 2002 23:47:46 -0700 (PDT)
Received: (qmail 27895 invoked by uid 1000); 20 Apr 2002 06:47:06 -0000
To: [e-mail]
Subject: Re: What's left before a new RFC?
References: <p05101585b8e3abe7a80e@[192.168.1.97]>
From: Florian Weimer <[e-mail]>
Date: Sat, 20 Apr 2002 08:47:06 +0200
In-Reply-To: <p05101585b8e3abe7a80e@[192.168.1.97]> (Jon Callas's message of "Wed, 17 Apr 2002 15:54:01 -0700")
Message-ID: <[e-mail]>
Lines: 15
User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> writes:

>  I know of no other desired changes. I would like bis-05 to be Penultimate
>  Call. Does anyone object?

3.2 is lacking a hint to implementors that the bit count feild for
encrypted MPIs reflects the number of bits in the decrypted MPI (IOW,
encrypted MPIs might not be well-formed as required by 3.2).

There's a formatting error in the second table of section 5.2.3.16.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.11.6/8.11.3) id g3J4SV925671 for ietf-openpgp-bks; Thu, 18 Apr 2002 21:28:31 -0700 (PDT)
Received: from mail.cablespeed.com (mail.cablespeed.com [216.45.96.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3J4STb25666 for <[e-mail]>; Thu, 18 Apr 2002 21:28:29 -0700 (PDT)
Received: (qmail 996 invoked by uid 0); 19 Apr 2002 04:28:26 -0000
Received: from unknown (HELO koma.kadrevis.com) (64.255.219.59) by mail.cablespeed.com with SMTP; 19 Apr 2002 04:28:26 -0000
Date: Thu, 18 Apr 2002 21:28:25 -0700
Subject: Re: bis04
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: Paul Holman <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3J4SUb25667
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Just confirmation, I finally performed this test, and my experience 
mirrors Jon's.  I use Mail.app on MacOS X which I suppose is uncommonly, 
multilinguistically savvy, it displayed all the characters correctly.  
GnuPG and the associated plugin handled the signature fine.

pablos.

On Tuesday, April 16, 2002, at 12:16 AM, Thomas Roessler wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2002-04-15 17:38:13 -0700, Jon Callas wrote:
>
>> The reason I dropped it is because some implementers claim that
>> base OpenPGP with armoring is deprecated. This is *not* the case.
>
> With all due respect, OpenPGP with armoring gets you into all kinds
> of hell as soon as you want to sign more than just us-ascii text,
> and as soon as you want to verify the signature on a system
> different from the one the signature was created on.  This is, in
> particular, the case when users have to feed PGP with a recoded
> version of the message.  Such recoding may be necessary in order to
> properly display the message to you.
>
> Here's a test - this message is encoded in utf-8, it's clearsigned,
> and here is a number of special characters: € ä ö ü æ ç
>
> Using widespread Windows software, can you find a messaging program
> which (1) verifies the signature AND (2) correctly displays the
> special characters (Euro symbol, a-umlaut, o-umlaut, u-umlaut, ae
> ligature, c-cedilla)?  Please tell us.
>
>> If you can come up with wording that says MIME is great, but so is
>> armoring, send it and I'll look at it.
>
> How about this?
>
> 	Note: A specification for using MIME to encapsulate OpenPGP
> 	signed or encrypted messages, and for signing and encrypting
> 	complex MIME objects with OpenPGP, can be found in RFC 3156.
>
> I'll send a separate message with somewhat more on the character
> set issues later today.
>
> - --
> Thomas Roessler                        <[e-mail]>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
>
> iQEVAwUBPLvP1dImKUTOasbBAQKr6wgAwHjiE9UzYcSvhQjmFyj4Fq34S54UmOKR
> RrF70Ecuofy77GrLapkqybhMdKlxobrncoTVE3QLnXwhvaaHD+9JIycUeu07h2nI
> ce1KBZei1CJDq0J8LY81lLAIcrOQFtkporpBKITqNdaN/AUTKOfTD+5pT+D8PWq7
> EaAP8ZXyvr4Ydswx1u1cPNM5Y79bZCsmnpaJuwqPSM8XMo6+x8FFS6lKtiZuVazP
> eoKcE1PF+UU4/hEh/FB3ypivgmykwSIAOJmSaztZr/Rrf8OWaUxodZTL6Y1lz0aJ
> FoOmlZDEsiUcvw2VOA+Nh5sM+Fc+EcSVm1SGNrQs1V70ZbZJK5yqZw==
> =LZ1m
> -----END PGP SIGNATURE-----
>



Received: by above.proper.com (8.11.6/8.11.3) id g3J3CDd23696 for ietf-openpgp-bks; Thu, 18 Apr 2002 20:12:13 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J3C2b23663 for <[e-mail]>; Thu, 18 Apr 2002 20:12:04 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3J32S003377; Thu, 18 Apr 2002 20:02:28 -0700
Date: Thu, 18 Apr 2002 20:02:28 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Adam Back writes:

> On the simple hash/encrypt approach, I think this should work:
>
> Alice sending non-transferably signed message to Bob and Charlie:
>
> Encrypt_Bob(K_B), Encrypt( K_B, Sign_Alice(K_B||Bob), H(msg) ), 
>   Encrypt_Charlie(K_C), Encrypt( K_C, Sign_Alice(K_C||Charlie), H(msg) ), 
>   msg

I see, that makes sense.  It's similar in flavor to the suggestion
I made last night, to do separate MACs on the msg using K_B and K_C.
Then I was having Alice sign the Bob- and Charlie-encrypted key blocks,
rather than the MAC and public key values directly, which probably amounts
to much the same thing.  Here's where proofs of security would be really
nice, to see if any of these constructions have subtle problems, or if
one is superior to the others.

The one other point I see is that as the number of recipients increases,
then a priori it becomes less likely that so many people would all
collude to forge a message from Alice.  So although you have security
in principle, the deniability becomes a little more questionable in
practice when the number of recipients is large.

Hal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3J2Jt320997 for ietf-openpgp-bks; Thu, 18 Apr 2002 19:19:55 -0700 (PDT)
Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J2Jr720993 for <[e-mail]>; Thu, 18 Apr 2002 19:19:54 -0700 (PDT)
Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 16yO1x-00BAe4-00; Fri, 19 Apr 2002 03:21:45 +0100
Date: Fri, 19 Apr 2002 03:19:45 +0100
From: Adam Back <[e-mail]>
To: Hal Finney <[e-mail]>
Cc: [e-mail]
Subject: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Apr 17, 2002 at 06:58:20PM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal Finney wrote:
> > The approach generalises to multiple recipient's: either hash in all
> > of the recipient public keys, or include signatures for each recipient
> > -- the latter is probably preferable as then the recipient doesn't
> > need all the other recipient's public keys to verify.
> 
> I don't think that works for multiple recipients, because any recipient
> can recover K, alter the msg, and re-create an apparently valid message
> that would be accepted by other recipients.  Alice's signature is only
> on K and public keys so that part doesn't change when the msg does.

You're right.  That doesn't work.  See below...

On Wed, Apr 17, 2002 at 06:58:20PM -0700, Hal Finney wrote:
> [...]
> 
> This concept can be applied pretty straightforwardly to the mathematical
> key-combining technique, I think (I figured out how to do it once) but
> I don't see how to use the simple hash/encrypt trick to accomplish this.

On the simple hash/encrypt approach, I think this should work:

Alice sending non-transferably signed message to Bob and Charlie:

Encrypt_Bob(K_B), Encrypt( K_B, Sign_Alice(K_B||Bob), H(msg) ), 
  Encrypt_Charlie(K_C), Encrypt( K_C, Sign_Alice(K_C||Charlie), H(msg) ), 
  msg

the message could optionally be encrypted using standard multiple
recipient technique (just include common key K):

Encrypt_Bob(K_B,K), Encrypt( K_B, Sign_Alice(K_B||Bob), H(msg) ), 
  Encrypt_Charlie(K_C,K), Encrypt( K_C, Sign_Alice(K_C||Charlie), H(msg) ), 
  Encrypt( K, msg )

The Encrypt() function should include MDC in both uses.


Bob can't transfer signatures as all he has is a signature that he
received a message from Alice and a random key.  He could forge any
message to himself with that information.

Similarly Bob and Charlie collaborating also can not transfer
signatures from Alice as they can collaboratively forge any message to
themselves.

As long as K_B is kept secret Bob is sure Alice sent him the message,
but can't convince anyone else of this fact.

Bob can't forge a message from Alice to Charlie with the information
he sees as he doesn't see Sign_Alice(K_C||Charlie), and can't
transform Sign_Alice(K_B||Bob) into that, and he doesn't know KC so he
can't decrypt to find out, nor can he modify the encryption because of
the MDC also keyed via K_C.

Adam
--
http://www.cypherspace.org/adam/


Received: by above.proper.com (8.11.6/8.11.3) id g3IKNfA06592 for ietf-openpgp-bks; Thu, 18 Apr 2002 13:23:41 -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 g3IKNd706587 for <[e-mail]>; Thu, 18 Apr 2002 13:23:39 -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 g3IKNJJ23313; Thu, 18 Apr 2002 16:23:19 -0400 (EDT)
Subject: Re: Clearsigning, MIME, etc.
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
From: [e-mail]
Date: Thu, 18 Apr 2002 15:23:10 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/18/2002 04:23:02 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

That is the official IANA name.  See
http://www.iana.org/assignments/character-sets .  A while back, when
looking for the official name, that's the only one I could find!

Now, I see that windows-1252 is listed also.  They don't show date of
listing, but if the MIBenum is incremented each time, it's clearly a
recient addition.

iso-8859-1 is also listed, and it's a subset.  Windows started with that
and added glyphs in the C1 control area.





Marc Mutz <[e-mail]> on 04-18-2002 12:35:21 PM

To:   [e-mail], [e-mail]
cc:   [e-mail]
Subject:  Re: Clearsigning, MIME, etc.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 18 April 2002 18:31, [e-mail] wrote:
<snip>
> Use a header inside the PGP envelope to note the message's character set.
>      -----BEGIN PGP SIGNED MESSAGE-----
>      Hash: SHA2
>      Charset: ISO-8859-1-Windows-3.1-Latin-1
>
>      Message starts here...
> Now how many people are going to use the correct official name, when it's
> such a jawbreaker?  Look at the charset declaration in web pages, and
very
> few get it right.  So, better make that clear.
<snip>

Which charset should this be? The official, preferred mime-name is
"iso-8859-1", and nothing else should be used, though the recveiver should
understand other common names.

Marc

- --
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vwPZ3oWD+L2/6DgRAtzUAJ9ldFWxGPh0iM8/CmXShXTpcTGEfACg/jbQ
166yx32jHn7nHrjD5tm82qI=
=G0bO
-----END PGP SIGNATURE-----









Received: by above.proper.com (8.11.6/8.11.3) id g3IJoal05215 for ietf-openpgp-bks; Thu, 18 Apr 2002 12:50:36 -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 g3IJoZ705211 for <[e-mail]>; Thu, 18 Apr 2002 12:50:35 -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 g3IJokJ11529; Thu, 18 Apr 2002 15:50:46 -0400 (EDT)
Subject: Re: What's left before a new RFC?
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
From: [e-mail]
Date: Thu, 18 Apr 2002 14:50:36 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/18/2002 03:50:29 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

Ah, excellent point.

So if you wanted to include something funny in the version or comment, you
could use something like HTML escapes.  That would be clear to the human
reader, but still pacify the person who really really wants to spell his
name correctly.





Marc Mutz <[e-mail]>@mail.imc.org on 04-18-2002 05:48:57 AM

Sent by:  [e-mail]


To:   Marcel Waldvogel <[e-mail]>, Jon Callas
      <[e-mail]>
cc:   [e-mail]
Subject:  Re: What's left before a new RFC?



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 18 April 2002 10:17, Marcel Waldvogel wrote:
<snip>
> For the Version and Comment headers, I propose to state that they are
> UTF-8, but for interoperability, implementations SHOULD restrict
> themselves to generate ASCII characters.
<snip>

I don't see the how having UTF-8 inside _ASCII_ Armor can be justified. The
problem is that the ascii armor is going to be used in non-8but-clean
environments. Else, you'd use the binary format, no?

Because of that, I'm strongly in favour of stating that implementations
MUST
NOT emit armor headers with non-US-ACSII characters in them.

Re: UTF-7. I understand that UTF-7 could be a solution. Only UTF-7 is
widely
considered to be a big mistake, so it shouldn't be used anymore.

Marc

- --
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vqSZ3oWD+L2/6DgRAvUFAJ9BG1s0Z8j+Ylmb17IpK/r7BsQE9ACfcJdz
kBG5Od9TA9P84a7Qnh+NMdk=
=TFvG
-----END PGP SIGNATURE-----







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IJm3G05050 for ietf-openpgp-bks; Thu, 18 Apr 2002 12:48:03 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IJm0705044 for <[e-mail]>; Thu, 18 Apr 2002 12:48:01 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16yId3-0007Hd-00; Thu, 18 Apr 2002 22:35:41 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16yHtz-0000PU-00; Thu, 18 Apr 2002 21:49:07 +0200
To: "Hal Finney" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
References: <[e-mail]>
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est.
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Thu, 18 Apr 2002 21:49:07 +0200
In-Reply-To: <[e-mail]> ("Hal Finney"'s message of "Thu, 18 Apr 2002 12:20:40 -0700")
Message-ID: <[e-mail]>
Lines: 11
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 18 Apr 2002 12:20:40 -0700, Hal Finney said:

> Actually I think PGP 2.X did have the ability to strip off one layer
> of PGP processing, so it could be used to turn a signed-and-encrypted
> message into a signed one.  It would not be cleartext signed, it would use

PGP/MIME provides a cleaner way to handle this

scnr,

  Werner



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IJfEY04795 for ietf-openpgp-bks; Thu, 18 Apr 2002 12:41:14 -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 g3IJfC704791 for <[e-mail]>; Thu, 18 Apr 2002 12:41:12 -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 g3IJfRJ07871; Thu, 18 Apr 2002 15:41:27 -0400 (EDT)
Subject: Re: What's left before a new RFC?
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Thu, 18 Apr 2002 14:41:17 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/18/2002 03:41:10 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

96-character G0 ASCII is a proper subset of UTF-8.
Lots of Internet protocol headers are based on a common design that uses
this small character set.  Is there any reason to break from that, rather
than saying "just like all the others"?
If the reason is to have arbitrary chars in the comment etc., then perhaps
say that it's UTF-8 but the keyword before the ':' must be confined to the
G0 characters, and the linebreak is that of the surrounding document (what
about the Unicode libebreak/parabreak chars?).





Jon Callas <[e-mail]>@mail.imc.org on 04-17-2002 05:54:01 PM

Sent by:  [e-mail]


To:   [e-mail]
cc:
Subject:  What's left before a new RFC?



When I sent out bis04, it had all previous changes and additions in it.

Thomas Roessler is convincing me that I may need to tighten up the language
about UTF-8. If anyone out there disagrees with him, speak up.

I'm willing to put in a note to say that the Version and Comment headers in
armor SHOULD or MUST be ASCII. I don't like it (I want everything to be
UTF-8), but I'll do it. Is UTF-7 too grotesque?

I know of no other desired changes. I would like bis-05 to be Penultimate
Call. Does anyone object?

     Jon






Received: by above.proper.com (8.11.6/8.11.3) id g3IJTnQ04494 for ietf-openpgp-bks; Thu, 18 Apr 2002 12:29:49 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IJTm704489 for <[e-mail]>; Thu, 18 Apr 2002 12:29:48 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3IJKei01453; Thu, 18 Apr 2002 12:20:40 -0700
Date: Thu, 18 Apr 2002 12:20:40 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Adam Back writes:
> What we proposed is related.  Rather
> than the normal encrypted signed message:
>
> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(msg)), msg)
>
> we proposed:
>
> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)
>
> with the additional restriction that the encryption mode should be one
> of the MDC modes (ie appended MAC with K outside encryption, or
> appended hash of msg inside encryption).

I see, that seems to work well too.  Plus it hides the nature of the
internal signature because it looks like a regular, opaque encryption
message on the outside.

> To break that down: we hash Bob's public key so that Bob can't turn
> around and forge an arbitrary an arbitrary message from Alice to
> Charlie using signed K.  What Bob is left with is proof that Alice
> sent him a message, but no evidence of what the message body was.
>
> The approach generalises to multiple recipient's: either hash in all
> of the recipient public keys, or include signatures for each recipient
> -- the latter is probably preferable as then the recipient doesn't
> need all the other recipient's public keys to verify.

I don't think that works for multiple recipients, because any recipient
can recover K, alter the msg, and re-create an apparently valid message
that would be accepted by other recipients.  Alice's signature is only
on K and public keys so that part doesn't change when the msg does.


> Indeed.  One aspect of our proposal which may be good is that
> extracting a signature contained inside an encrypted message is
> already not directly supported.  So nothing _new_ has been added from
> the users perspective -- rather that feature has been
> cryptographically assured rather than just being an unimplemented
> implementation possibility.

Actually I think PGP 2.X did have the ability to strip off one layer
of PGP processing, so it could be used to turn a signed-and-encrypted
message into a signed one.  It would not be cleartext signed, it would use
literal packets, but it would be a legal signed message.  Perhaps GnuPG
has retained the ability to do this.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g3IJPZQ04375 for ietf-openpgp-bks; Thu, 18 Apr 2002 12:25:35 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IJPX704370 for <[e-mail]>; Thu, 18 Apr 2002 12:25:33 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (ppp36-182.hrz.uni-bielefeld.de [129.70.36.182]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]> for [e-mail]; Thu, 18 Apr 2002 21:25:33 +0200 (MET DST)
Date: Thu, 18 Apr 2002 19:35:21 +0200
From: Marc Mutz <[e-mail]>
Subject: Re: Clearsigning, MIME, etc.
In-reply-to: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 18 April 2002 18:31, [e-mail] wrote:
<snip>
> Use a header inside the PGP envelope to note the message's character set.
>      -----BEGIN PGP SIGNED MESSAGE-----
>      Hash: SHA2
>      Charset: ISO-8859-1-Windows-3.1-Latin-1
>
>      Message starts here...
> Now how many people are going to use the correct official name, when it's
> such a jawbreaker?  Look at the charset declaration in web pages, and very
> few get it right.  So, better make that clear.
<snip>

Which charset should this be? The official, preferred mime-name is 
"iso-8859-1", and nothing else should be used, though the recveiver should 
understand other common names.

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vwPZ3oWD+L2/6DgRAtzUAJ9ldFWxGPh0iM8/CmXShXTpcTGEfACg/jbQ
166yx32jHn7nHrjD5tm82qI=
=G0bO
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IJPXp04369 for ietf-openpgp-bks; Thu, 18 Apr 2002 12:25:33 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IJPV704362 for <[e-mail]>; Thu, 18 Apr 2002 12:25:32 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (ppp36-182.hrz.uni-bielefeld.de [129.70.36.182]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]> for [e-mail]; Thu, 18 Apr 2002 21:25:31 +0200 (MET DST)
Date: Thu, 18 Apr 2002 19:30:33 +0200
From: Marc Mutz <[e-mail]>
Subject: Re: What's left before a new RFC?
In-reply-to: <[e-mail]>
To: Marcel Waldvogel <[e-mail]>
Cc: Jon Callas <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
References: <p05101585b8e3abe7a80e@[192.168.1.97]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 18 April 2002 16:46, Marcel Waldvogel wrote:
<snip>
> >I don't see the how having UTF-8 inside _ASCII_ Armor can be justified.
> > The problem is that the ascii armor is going to be used in non-8but-clean
> > environments. Else, you'd use the binary format, no?
>
> One one side, we can consider cleartext signatures, which already can
> contain characters with the MSB set, and which are not necessarily
> armored for 8-bit cleanliness. Even there, the signature block is (among
> other things) ASCII-armored to not confuse the user (or his terminal)
> with weird chars.

Yes, but the problem is not clearsigning. The problem is armoured encryption 
and armoured keyrings. There also exist binary versions. Why do you think 
exist armoured ones? If the armoured format wasn't restricted to US-ASCII, 
then what right has the armoured format to exist anymore?

> There are multiple reasons for armoring non-7bit data:
> a) The transport does not allow arbitrary 8bit sequences
<snip>

SMTP falls into this category. That's what I'm mainly concerned with and 
that's where we ran into problems a few months ago. The PGP/MIME rfc3156 
defines all app/pgp-* mimetypes to be 7bit only. Allowing 8bit octets in 
ascii armour would break rfc3156 (and rfc1847, too, IIRC) for no apparent 
added value.

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vwK63oWD+L2/6DgRAqXlAKC5cLDJVbFYNjXQbZrirk8R6PCpXACg2zn4
njSeHYzN+c4Nlm0o2dpxKbY=
=Pcej
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id g3IIvgP01808 for ietf-openpgp-bks; Thu, 18 Apr 2002 11:57:42 -0700 (PDT)
Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IIvQ701767 for <[e-mail]>; Thu, 18 Apr 2002 11:57:27 -0700 (PDT)
Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 16yH7q-00AzfD-00; Thu, 18 Apr 2002 19:59:22 +0100
Date: Thu, 18 Apr 2002 19:57:12 +0100
From: Adam Back <[e-mail]>
To: Werner Koch <[e-mail]>
Cc: [e-mail]
Subject: Re: Whither comment packets?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Apr 18, 2002 at 07:53:04PM +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I don't find it makes a lot of sense either.

Key size reduction is anyway easy to do whatever the packet formats --
from the cryptography directly: generate weak key-pairs, or weak
symmetric keys, or trap-door weak keys (weak if you know some secret
strong otherwise) etc.  There have been a number of papers about how
to do this and how to do it well.

Adam

On Thu, Apr 18, 2002 at 07:53:04PM +0200, Werner Koch wrote:
> 
> On Thu, 18 Apr 2002 10:12:28 -0700, Jon Callas said:
> 
> > Yes, it was seen to be a security problem. An evil implementation could leak
> > things (like your keys) there, or use it as a way to do key-size reduction.
> 
> Not very convincing; I'd put it into the unhashed area of signature
> packets ;-)
> 
>   Werner
> 


Received: by above.proper.com (8.11.6/8.11.3) id g3IHpsi27143 for ietf-openpgp-bks; Thu, 18 Apr 2002 10:51:54 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IHppm27139 for <[e-mail]>; Thu, 18 Apr 2002 10:51:51 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16yGog-0006qw-00; Thu, 18 Apr 2002 20:39:34 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16yG5g-000080-00; Thu, 18 Apr 2002 19:53:04 +0200
To: [e-mail]
Subject: Re: Whither comment packets?
References: <[e-mail]>
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est.
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Thu, 18 Apr 2002 19:53:04 +0200
In-Reply-To: <[e-mail]> (Jon Callas's message of "Thu, 18 Apr 2002 10:12:28 -0700")
Message-ID: <[e-mail]>
Lines: 9
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 18 Apr 2002 10:12:28 -0700, Jon Callas said:

> Yes, it was seen to be a security problem. An evil implementation could leak
> things (like your keys) there, or use it as a way to do key-size reduction.

Not very convincing; I'd put it into the unhashed area of signature
packets ;-)

  Werner



Received: by above.proper.com (8.11.6/8.11.3) id g3IHHTA26200 for ietf-openpgp-bks; Thu, 18 Apr 2002 10:17:29 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IHHSm26196 for <[e-mail]>; Thu, 18 Apr 2002 10:17:28 -0700 (PDT)
Received: from [192.168.1.27] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Thu, 18 Apr 2002 10:17:13 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 18 Apr 2002 10:12:28 -0700
Subject: Re: Whither comment packets?
From: Jon Callas <[e-mail]>
To: David Shaw <[e-mail]>
CC: <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 4/18/2002 9:44 AM, "David Shaw" <[e-mail]> wrote:

> I understand that at some point in the past one of the OpenPGP drafts
> had a "comment packet" defined.  It seems to have been dropped
> somewhere along the way, and I was wondering if anyone recalled why?

Yes, it was seen to be a security problem. An evil implementation could leak
things (like your keys) there, or use it as a way to do key-size reduction.
The area directors were forceful and persuasive in their arguments.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IGj0622100 for ietf-openpgp-bks; Thu, 18 Apr 2002 09:45:00 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IGixm22093 for <[e-mail]>; Thu, 18 Apr 2002 09:44:59 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3IGin001633 for [e-mail]; Thu, 18 Apr 2002 12:44:49 -0400
Date: Thu, 18 Apr 2002 12:44:49 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Whither comment packets?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (31% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi everyone,

I understand that at some point in the past one of the OpenPGP drafts
had a "comment packet" defined.  It seems to have been dropped
somewhere along the way, and I was wondering if anyone recalled why?

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3IGVF921259 for ietf-openpgp-bks; Thu, 18 Apr 2002 09:31:15 -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 g3IGVDm21255 for <[e-mail]>; Thu, 18 Apr 2002 09:31:14 -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 g3IGVIJ00684; Thu, 18 Apr 2002 12:31:18 -0400 (EDT)
Subject: Re: Clearsigning, MIME, etc.
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Thu, 18 Apr 2002 11:31:08 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/18/2002 12:31:01 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

Re:
 - ASCII armor proper can be fixed by giving a clear specification of
   the character set issues involved: Either mandate UTF-8, or
   mandate tagging and use UTF-8 as the default.  The current
   language is considerably too fuzzy, and - I believe - mostly
   ignored.


Excellent report and summary--thanks for clearing everything up.

I'd like to make one point.  If ASCII-armor and PGP "stuff" inside the
readable text in general is for dealing with systems that don't have
meta-data for this, we can't mandate the use of a mail header.  If it's
stored in a txt file, it doesn't =have= a mail header!

Listing the charset info as clear-text would be helpful in general to the
human reader, too.  So you could put it in the PGP headers after the
-----BEGIN and before the blank line separator.

Or, it can be a flag in the "encoding", but the only encoded stuff in this
case is the signature block itself.  Why not both?  If you change the text
file, you can change the human-readable charset header to match, and when
you verify, the tool will see the mismatch and convert back to the format
that the sig was used on, or give a suitable error.

Or, the signature can "normalize" text by converting it to UTF-8
internally.  The verify would know to do the same, from whatever the file's
charset it.

Putting that together, I'd propose something like this:

Use a header inside the PGP envelope to note the message's character set.
     -----BEGIN PGP SIGNED MESSAGE-----
     Hash: SHA2
     Charset: ISO-8859-1-Windows-3.1-Latin-1

     Message starts here...
Now how many people are going to use the correct official name, when it's
such a jawbreaker?  Look at the charset declaration in web pages, and very
few get it right.  So, better make that clear.

Meanwhile, the signature itself (the base64-encoded packets) would contain
a flag that states that the normalization of the text included converting
to UTF-8.  Without that flag, it does what it does now, and takes whatever
bytes you give it unchanged except for rules about trailing whitespace and
linebreaks.

In summary, I think the idea of recording this information in two places
(the clear text and the sig) is valuable, and allows the text block to be
re-coded for display and still check the signature.  An existing MUA won't
know to change the Charset line, but between that value and the mail header
and your machine's configuration, you have enough information to figure out
just what it did!





Received: by above.proper.com (8.11.6/8.11.3) id g3IEkVE15632 for ietf-openpgp-bks; Thu, 18 Apr 2002 07:46:31 -0700 (PDT)
Received: from wanda.ch (adsl-73-116-basel1.tiscalinet.ch [212.254.73.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IEkTm15628 for <[e-mail]>; Thu, 18 Apr 2002 07:46:30 -0700 (PDT)
Received: from news.m.wanda.ch (pat.zurich.ibm.com [195.212.119.253]) by wanda.ch (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g3IEkMw14021; Thu, 18 Apr 2002 16:46:22 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 Apr 2002 16:46:21 +0200
From: Marcel Waldvogel <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: de, en
MIME-Version: 1.0
To: Marc Mutz <[e-mail]>
CC: Jon Callas <[e-mail]>, [e-mail]
Subject: Re: What's left before a new RFC?
References: <p05101585b8e3abe7a80e@[192.168.1.97]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Marc Mutz wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Thursday 18 April 2002 10:17, Marcel Waldvogel wrote:
><snip>
>
>>For the Version and Comment headers, I propose to state that they are
>>UTF-8, but for interoperability, implementations SHOULD restrict
>>themselves to generate ASCII characters.
>>
><snip>
>
>I don't see the how having UTF-8 inside _ASCII_ Armor can be justified. The 
>problem is that the ascii armor is going to be used in non-8but-clean 
>environments. Else, you'd use the binary format, no?
>

One one side, we can consider cleartext signatures, which already can 
contain characters with the MSB set, and which are not necessarily 
armored for 8-bit cleanliness. Even there, the signature block is (among 
other things) ASCII-armored to not confuse the user (or his terminal) 
with weird chars.

There are multiple reasons for armoring non-7bit data:
a) The transport does not allow arbitrary 8bit sequences
b) The transport does not allow arbitrary "line" lengths
c) The transport does charset recoding, probably forth and back.

The headers that use UTF-8 are mostly for human consumption (I presume), 
and most modern non-8bit transports are of the form (b) or (c), which 
(1) should not harm typical headers nor (2) cause any damage, if they 
are slightly mangled (IMHO).


BTW: Does the "Version" header contain the product and version used 
("User-Agent"), or the version of the standard ("MIME-Version")? bis04 
seems to indicate the latter, but usage seems to be the former.

-Marcel



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IDitJ12123 for ietf-openpgp-bks; Thu, 18 Apr 2002 06:44:55 -0700 (PDT)
Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IDism12119 for <[e-mail]>; Thu, 18 Apr 2002 06:44:55 -0700 (PDT)
Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 16yCFT-00Aw1f-00; Thu, 18 Apr 2002 14:46:55 +0100
Date: Thu, 18 Apr 2002 14:44:54 +0100
From: Adam Back <[e-mail]>
To: Hal Finney <[e-mail]>
Cc: [e-mail]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Apr 17, 2002 at 06:58:20PM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Apr 17, 2002 at 06:58:20PM -0700, Hal Finney wrote:
> 
> Adam Back writes:
> > The approach of signing encrypted key and using the key to MAC the
> > data is interesting.  It's very similar to what Ian and I proposed in:
> >
> > Non-Transferable Signatures using PGP, Usenix Annual Technical
> > Conference, 98, Ian Brown and Adam Back
> >
> > There's a short summary here:
> >
> > 	http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm
> 
> I haven't been able to get through to this site; I'll try again later.

(Seems to be reachable now.)  What we proposed is related.  Rather
than the normal encrypted signed message:

	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(msg)), msg)

we proposed:

	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)

with the additional restriction that the encryption mode should be one
of the MDC modes (ie appended MAC with K outside encryption, or
appended hash of msg inside encryption).

To break that down: we hash Bob's public key so that Bob can't turn
around and forge an arbitrary an arbitrary message from Alice to
Charlie using signed K.  What Bob is left with is proof that Alice
sent him a message, but no evidence of what the message body was.

The approach generalises to multiple recipient's: either hash in all
of the recipient public keys, or include signatures for each recipient
-- the latter is probably preferable as then the recipient doesn't
need all the other recipient's public keys to verify.

> > I don't think that so bad.  I think a reasonable approach for example
> > would be to by default non-transferably sign when messages are
> > encrypted and transferably sign when they are not (which makes sense
> > as it's probably what you want anyway as you described in a later
> > message, and with this particular scheme you can't sign without
> > encrypting).
> 
> Well, you can sign without encrypting the message by using the shared
> key to MAC the message rather than encrypt it, although you're right
> that there still has to be an element of encryption involved, and you
> do need to know who the recipient is.

Yes.  Needing to know who the recipient is was what made us feel a
natural place to put non-transferable sigantures was inside encryption
-- to avoid adding a confusing extra restriction and avoid causing
wide-ranging changes to the code, APIs and command line and GUI.

> My worry is more with the understanding on the part of the users as
> to what kinds of security guarantees they are getting.  Descriptions
> of digital signatures are widely available, and the motivated user
> has many sources he can go to in order to learn about how signatures
> work.
> 
> If we introduce these non-transferable signatures (good name btw) then
> there is more possibility for confusion.  

Indeed.  One aspect of our proposal which may be good is that
extracting a signature contained inside an encrypted message is
already not directly supported.  So nothing _new_ has been added from
the users perspective -- rather that feature has been
cryptographically assured rather than just being an unimplemented
implementation possibility.

You're right that it may confuse, but they won't be directly exposed
to it unless they dig under the hood.

Seems somewhat reasonable that people who are paranoid enough to not
want transferable signatures should also use encryption.  The kinds of
things they are worrying about -- eg off the record remark becoming on
the record and involved in a dispute -- are best also protected by
encryption as courts seem to view plaintext as evidence and
unauthenticated company and ISP mail logs things like that.

> Is there an extension of this to the multi-party case?  It doesn't
> work to use the simple idea of having Alice encrypt K to each recipient
> and sign those encryptions, then MAC (or encrypt) the message with K.
> The problem is that each recipient learns K, hence any of them might have
> created or altered the message body.  Each recipient is only convinced
> that the message came from Alice or someone on the recipient list.

Yes see above.

> Logically it seems to me that for this to work the message has to be one
> which was constructable either by the signer, or by the collective effort
> of all the recipients WORKING TOGETHER.  In this way, each recipient
> can know that, since he did not collude with the other recipients to
> make the message, it must have come from the claimed signer, making
> the signature convincing.  But outside parties cannot rule out the
> possibility that the recipients collectively "forged" the message,
> making the signature non-transferrable.
> 
> This concept can be applied pretty straightforwardly to the mathematical
> key-combining technique, I think (I figured out how to do it once) but
> I don't see how to use the simple hash/encrypt trick to accomplish this.

We also looked a bit at a group signature with a similar property to
the one you reference in Rivest et al's paper.  The reference I have
for it is:

Bernardo A. Huberman, Matt Franklin and Tad Hogg: Enhancing privacy
and trust inelectronic communities. ACM Conference on Electronic
Commerce, 1999, pp.78-86.

	http://citeseer.nj.nec.com/365811.html

however that paper also references some earlier work.

By combining the approach with these group signatures you reduce the
proof Bob ends up with.  Instead of a proof that Bob received a
message from Alice, but no proof of message content, Bob ends up with
a proof that either Alice sent him a message or he forged a message to
himself from Alice.

I agree with your collective effort argument for the generalized
version of this with multiple recipients.


It's all fairly related to forward secrecy also -- another form of
proof of authorship is for a court with a copy of a ciphertext to
demand appropriate private keys and verify for themselves.  This in
theory could have been forged, but they'll have mail headers and a
tendency to believe that Bob did not think ahead and forge a mail to
yourself pretending to be Alice.

Adam


Received: by above.proper.com (8.11.6/8.11.3) id g3IAq4X01698 for ietf-openpgp-bks; Thu, 18 Apr 2002 03:52:04 -0700 (PDT)
Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3IAq2m01694 for <[e-mail]>; Thu, 18 Apr 2002 03:52:02 -0700 (PDT)
Received: (cpmta 3652 invoked from network); 18 Apr 2002 03:51:57 -0700
Received: from 80.130.169.184 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.64) with SMTP; 18 Apr 2002 03:51:57 -0700
X-Sent: 18 Apr 2002 10:51:57 GMT
Content-Type: text/plain; charset="us-ascii"
From: Marc Mutz <[e-mail]>
Organization: KDE
To: Marcel Waldvogel <[e-mail]>, Jon Callas <[e-mail]>
Subject: Re: What's left before a new RFC?
Date: Thu, 18 Apr 2002 12:48:57 +0200
User-Agent: KMail/1.4.5
Cc: [e-mail]
References: <p05101585b8e3abe7a80e@[192.168.1.97]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3IAq3m01695
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 18 April 2002 10:17, Marcel Waldvogel wrote:
<snip>
> For the Version and Comment headers, I propose to state that they are
> UTF-8, but for interoperability, implementations SHOULD restrict
> themselves to generate ASCII characters.
<snip>

I don't see the how having UTF-8 inside _ASCII_ Armor can be justified. The 
problem is that the ascii armor is going to be used in non-8but-clean 
environments. Else, you'd use the binary format, no?

Because of that, I'm strongly in favour of stating that implementations MUST 
NOT emit armor headers with non-US-ACSII characters in them.

Re: UTF-7. I understand that UTF-7 could be a solution. Only UTF-7 is widely 
considered to be a big mistake, so it shouldn't be used anymore.

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vqSZ3oWD+L2/6DgRAvUFAJ9BG1s0Z8j+Ylmb17IpK/r7BsQE9ACfcJdz
kBG5Od9TA9P84a7Qnh+NMdk=
=TFvG
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3I8HO114718 for ietf-openpgp-bks; Thu, 18 Apr 2002 01:17:24 -0700 (PDT)
Received: from wanda.ch (adsl-73-116-basel1.tiscalinet.ch [212.254.73.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I8HMm14703 for <[e-mail]>; Thu, 18 Apr 2002 01:17:22 -0700 (PDT)
Received: from news.m.wanda.ch (pat.zurich.ibm.com [195.212.119.253]) by wanda.ch (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g3I8H8w12421; Thu, 18 Apr 2002 10:17:08 +0200
Message-ID: <[e-mail]>
Date: Thu, 18 Apr 2002 10:17:03 +0200
From: Marcel Waldvogel <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
X-Accept-Language: de, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: [e-mail]
Subject: Re: What's left before a new RFC?
References: <p05101585b8e3abe7a80e@[192.168.1.97]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon,

I agree with Thomas on the UTF-8 issue.

For the Version and Comment headers, I propose to state that they are 
UTF-8, but for interoperability, implementations SHOULD restrict 
themselves to generate ASCII characters. This phrase may be put in 
section 14 as a general comment.

-Marcel

Jon Callas wrote:

>When I sent out bis04, it had all previous changes and additions in it.
>
>Thomas Roessler is convincing me that I may need to tighten up the language
>about UTF-8. If anyone out there disagrees with him, speak up.
>
>I'm willing to put in a note to say that the Version and Comment headers in
>armor SHOULD or MUST be ASCII. I don't like it (I want everything to be
>UTF-8), but I'll do it. Is UTF-7 too grotesque?
>
>I know of no other desired changes. I would like bis-05 to be Penultimate
>Call. Does anyone object?
>
>	Jon
>



Received: by above.proper.com (8.11.6/8.11.3) id g3I2eMV14266 for ietf-openpgp-bks; Wed, 17 Apr 2002 19:40:22 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I2eLm14262 for <[e-mail]>; Wed, 17 Apr 2002 19:40:21 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3I2eEg01998; Wed, 17 Apr 2002 22:40:14 -0400
Date: Wed, 17 Apr 2002 22:40:14 -0400
From: David Shaw <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: bis04: revocation key nits
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, [e-mail]
References: <[e-mail]> <p0510158cb8e3cae4eb63@[192.168.1.97]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p0510158cb8e3cae4eb63@[192.168.1.97]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Apr 17, 2002 at 06:13:34PM -0700, Jon Callas wrote:
> 
> At 8:49 PM -0400 4/17/02, David Shaw wrote:
> 
> >The first item is that there is no way to revoke a 0x1F signature.
> >Since the designated revoker information is contained in an 0x1F
> >signature, this means that once a user designates a designated
> >revoker, the user cannot later undo the designation if circumstances
> >change.
> >
> >I'd like to request a new signature class to indicate a 0x1F
> >revocation or an expansion of the meaning of one of the existing
> >revocation signature classes to include 0x1F signatures.

[..]

> How do you revoke your key if the revocation can be revoked? If your key is
> compromised, the person who has it can do anything they want, including
> revoke your revoker. The designated revoker might as well not be there if
> it's not irrevocable. Now it's true, we also have an irrevocability
> subpacket. But nonetheless, it can't be revocable.

Ah, excellent point.  Do you think it is still worth (for
completeness, if not for the specific example of designated revokers)
having a way to revoke a 0x1F signature?

As for designated revokers in GnuPG, I'll do what PGP does and include
a nonrevocable subpacket with the 0x1F signature to remove any
ambiguity.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3I2ZQ814134 for ietf-openpgp-bks; Wed, 17 Apr 2002 19:35:26 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I2ZPm14130 for <[e-mail]>; Wed, 17 Apr 2002 19:35:25 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3I2QQA29627; Wed, 17 Apr 2002 19:26:26 -0700
Date: Wed, 17 Apr 2002 19:26:26 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

A correction: I wrote:
> If we introduce these non-transferable signatures (good name btw) then
> there is more possibility for confusion.  It's completely different from
> a regular signature; for one thing, Alice doesn't even have to type her
> passphrase, because her signature key is not used when she creates this
> kind of "signature"!  Imagine the paranoia that would trigger on the PGP
> user lists.  In general it's going to increase the explanatory burden
> for people who want to understand what the software is doing.

Sorry, I was confused when I wrote this.  Of course, Alice does have
to use her passphrase and private key, as she signs the encrypted key
block.  But I still think that the unique security properties of this
kind of signature would have to be explained, so that people can make
knowledgeable judgements about the security they are getting.

Hal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3I27PF13434 for ietf-openpgp-bks; Wed, 17 Apr 2002 19:07:25 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I27Om13430 for <[e-mail]>; Wed, 17 Apr 2002 19:07:24 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3I1wK729577; Wed, 17 Apr 2002 18:58:20 -0700
Date: Wed, 17 Apr 2002 18:58:20 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Adam Back writes:
> The approach of signing encrypted key and using the key to MAC the
> data is interesting.  It's very similar to what Ian and I proposed in:
>
> Non-Transferable Signatures using PGP, Usenix Annual Technical
> Conference, 98, Ian Brown and Adam Back
>
> There's a short summary here:
>
> 	http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm

I haven't been able to get through to this site; I'll try again later.

> I don't think that so bad.  I think a reasonable approach for example
> would be to by default non-transferably sign when messages are
> encrypted and transferably sign when they are not (which makes sense
> as it's probably what you want anyway as you described in a later
> message, and with this particular scheme you can't sign without
> encrypting).

Well, you can sign without encrypting the message by using the shared
key to MAC the message rather than encrypt it, although you're right
that there still has to be an element of encryption involved, and you
do need to know who the recipient is.

My main concern is not so much with the operational complexity; as you
say, the software could automatically create the right kind of signature
in most cases.  My worry is more with the understanding on the part
of the users as to what kinds of security guarantees they are getting.
Descriptions of digital signatures are widely available, and the motivated
user has many sources he can go to in order to learn about how signatures
work.

If we introduce these non-transferable signatures (good name btw) then
there is more possibility for confusion.  It's completely different from
a regular signature; for one thing, Alice doesn't even have to type her
passphrase, because her signature key is not used when she creates this
kind of "signature"!  Imagine the paranoia that would trigger on the PGP
user lists.  In general it's going to increase the explanatory burden
for people who want to understand what the software is doing.

I am also concerned about the security of this specific construction,
Sign_Alice(Encrypt_Bob(K)), MAC(K,Msg), Msg.  (Also applies to
Sign_Alice(Encrypt_Bob(K)), Encrypt(K, Msg).)  One attack I noticed is
that if Bob accidentally reveals K to an eavesdropper Eve, Eve can replay
the Sign_Alice(Encrypt_Bob(K)) block and replace the Msg with her own.
To defend against this either Bob could keep a list of recently used
K values (and perhaps include timestamps in the signed block).  Or of
course he could just be careful about leaking K, but it is an important
consideration for the designer.  It would be nice to see some security
proofs for this construction.

Is there an extension of this to the multi-party case?  It doesn't
work to use the simple idea of having Alice encrypt K to each recipient
and sign those encryptions, then MAC (or encrypt) the message with K.
The problem is that each recipient learns K, hence any of them might have
created or altered the message body.  Each recipient is only convinced
that the message came from Alice or someone on the recipient list.

Logically it seems to me that for this to work the message has to be one
which was constructable either by the signer, or by the collective effort
of all the recipients WORKING TOGETHER.  In this way, each recipient
can know that, since he did not collude with the other recipients to
make the message, it must have come from the claimed signer, making
the signature convincing.  But outside parties cannot rule out the
possibility that the recipients collectively "forged" the message,
making the signature non-transferrable.

This concept can be applied pretty straightforwardly to the mathematical
key-combining technique, I think (I figured out how to do it once) but
I don't see how to use the simple hash/encrypt trick to accomplish this.

BTW please do not forward this message elsewhere; by our company policy we
are supposed to restrict technical discussion of cryptography to research
oriented forums, and this list counts for that, but not most others.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g3I1Q6w12471 for ietf-openpgp-bks; Wed, 17 Apr 2002 18:26:06 -0700 (PDT)
Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I1Q5m12466 for <[e-mail]>; Wed, 17 Apr 2002 18:26:06 -0700 (PDT)
Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 16y0iL-00B2R2-00; Thu, 18 Apr 2002 02:27:57 +0100
Date: Thu, 18 Apr 2002 02:27:56 +0100
From: Adam Back <[e-mail]>
To: Hal Finney <[e-mail]>
Cc: [e-mail]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Apr 11, 2002 at 08:45:39AM -0700
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Only just saw this thread due to mailer config issue and Ian Brown
pointed it out to me.

The approach of signing encrypted key and using the key to MAC the
data is interesting.  It's very similar to what Ian and I proposed in:

Non-Transferable Signatures using PGP, Usenix Annual Technical
Conference, 98, Ian Brown and Adam Back

There's a short summary here:

	http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm

> Unfortunately I think that adding a new flavor of signature would tend
> to create confusion among users who at best barely understand public
> key cryptography.  The new kind of signature would have very different
> security properties and usage scenarios, so it would add additional
> complexity for people to deal with.

I don't think that so bad.  I think a reasonable approach for example
would be to by default non-transferably sign when messages are
encrypted and transferably sign when they are not (which makes sense
as it's probably what you want anyway as you described in a later
message, and with this particular scheme you can't sign without
encrypting).

btw We originally were going to put the non-transferable signature
stuff in the Forward Secrecy Extensions for PGP ID, but opted instead
to separate concerns and keep the ID simple.

	http://www.cypherspace.org/openpgp/pfs/openpgp-pfs.txt

Adam

On Thu, Apr 11, 2002 at 08:45:39AM -0700, Hal Finney wrote:
> I haven't read this RFC, but I had a long discussion with Wei Dai last
> year about ways to do this within the OpenPGP framework.  We came up with
> a couple of ideas.  These might be called "recipient-verifiable" signed
> messages, to distinguish them from the regular PGP signed messages which
> are "world-verifiable".  The general approach is to make the message such
> that the recipient could "forge" fake messages from the sender that look
> legitimate to third parties.  This prevents the real message from being
> shown around in a convincing way.
> 
> Wei suggested that the recipient-verifiable message from Alice to Bob
> could be as follows:
> 
> Sign_Alice( Encrypt_Bob( K ) ), MAC_K( Msg ), Msg.
> 
> The idea is that Alice chooses a MAC key K, encrypts it to Bob and then
> signs the encrypted packet.  She sends this, along with the MAC'd message,
> to Bob.  Bob can recover K from the encrypted packet, verifying the
> signature by Alice on that packet, and then verify the MAC.


Received: by above.proper.com (8.11.6/8.11.3) id g3I1IGC12347 for ietf-openpgp-bks; Wed, 17 Apr 2002 18:18:16 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I1IFm12343 for <[e-mail]>; Wed, 17 Apr 2002 18:18:15 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Wed, 17 Apr 2002 18:17:57 -0700
Mime-Version: 1.0
Message-Id: <p0510158cb8e3cae4eb63@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 17 Apr 2002 18:13:34 -0700
To: David Shaw <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: bis04: revocation key nits
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 8:49 PM -0400 4/17/02, David Shaw wrote:

>The first item is that there is no way to revoke a 0x1F signature.
>Since the designated revoker information is contained in an 0x1F
>signature, this means that once a user designates a designated
>revoker, the user cannot later undo the designation if circumstances
>change.
>
>I'd like to request a new signature class to indicate a 0x1F
>revocation or an expansion of the meaning of one of the existing
>revocation signature classes to include 0x1F signatures.

It is the intent of the designated revoker feature that it cannot be
revoked. Otherwise it's too hairy for words.

Here's a scenario: Suppose Alice is your designated revoker. You discover
that your key is being used by persons unknown for purposes you don't
approve of -- oh, like spending your money. Let's also assume that you no
longer have the secret key (let's say your laptop was stolen).

You visit Alice, explaining the problem, and she generates a revocation for
your certificate. After all, that's why she's your revoker. Alice sends it
to the world. Or you send it to the world for Alice.

The next day, a merchant cashes another bogus check. You call up the
merchant and ask, "What the heck are you doing? Didn't you see Alice's
revocation of that key." The merchant replies, "Yeah, but I also have a
revocation of Alice's revoker status dated April 1, 1999."

How do you revoke your key if the revocation can be revoked? If your key is
compromised, the person who has it can do anything they want, including
revoke your revoker. The designated revoker might as well not be there if
it's not irrevocable. Now it's true, we also have an irrevocability
subpacket. But nonetheless, it can't be revocable.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3I0qqS11830 for ietf-openpgp-bks; Wed, 17 Apr 2002 17:52:52 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I0qpm11826 for <[e-mail]>; Wed, 17 Apr 2002 17:52:51 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3I0qoo01154 for [e-mail]; Wed, 17 Apr 2002 20:52:50 -0400
Date: Wed, 17 Apr 2002 20:52:50 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Revocation target subpacket (Re: What's left before a new RFC?)
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <p05101585b8e3abe7a80e@[192.168.1.97]> <00d501c1e66e$e3deb920$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d501c1e66e$e3deb920$[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (24% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Apr 17, 2002 at 08:20:26PM -0400, Michael Young wrote:

> I still desire a "revocation target" subpacket to identify the
> specific signature being revoked:

[..]

> David Shaw also suggested including the timestamp from the revocation
> packet, to allow a blazingly fast comparison.  Again, I could live
> with or without this.

After further consideration of Jon's comments about hash comparison, I
don't see the need.

> Without the ability to revoke a specific signature, I strongly object
> to multiple self-signatures being interpreted "any way it sees fit".
> Yes, there's a RECOMMENDED behavior, and that may be the best we can
> hope for in old implementations.  It's sad to suggest that when
> conversing among new implementations, a key owner cannot update its
> self-signature in a clear and unambiguous way.  But a revocation
> target would satisfy my objection.  There may be other solutions to
> this specific problem, such as a "supercedes" subpacket, but I don't
> think they're as generally powerful or useful.
> 
> Note that I would not limit the use of this subpacket to self-signatures.
> I think it would be equally meaningful for ordinary certifications,
> to disambiguate between signatures with different subpackets (e.g.,
> notation, trust limits, policy) or classes (e.g., 0x10 through 0x13).

See also the mail I just sent about designated revokers - there is a
good potential use there as well.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3I0nL911769 for ietf-openpgp-bks; Wed, 17 Apr 2002 17:49:21 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I0nJm11764 for <[e-mail]>; Wed, 17 Apr 2002 17:49:20 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3I0nIK01129 for [e-mail]; Wed, 17 Apr 2002 20:49:18 -0400
Date: Wed, 17 Apr 2002 20:49:18 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: bis04: revocation key nits
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (21% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi everyone,

I'd like to raise two items for possible inclusion in bis05.  These
came up while implementing designated revoker functionality in GnuPG.

The first item is that there is no way to revoke a 0x1F signature.
Since the designated revoker information is contained in an 0x1F
signature, this means that once a user designates a designated
revoker, the user cannot later undo the designation if circumstances
change.

I'd like to request a new signature class to indicate a 0x1F
revocation or an expansion of the meaning of one of the existing
revocation signature classes to include 0x1F signatures.

The second item is one I raised in February.  Briefly, the draft
indicates that a designated revoker is allowed to issue three types of
revocations: key revocations (0x20), subkey revocations (0x28), and
certification revocations (0x30).  The problem happens if a user is
both a designated revoker for someone who has signed a given key, as
well as a regular signer for the same given key.  In this case, there
is no way to tell the difference between a certification revocation
issued by the user in his capacity as designated revoker, and a
certification revocation issued by the user in his capacity as
himself.

For example, take Alice, Bob, and Charlie.  Bob is Alice's designated
revoker.  Alice and Bob have both certified Charlie's key.  Now Alice
asks Bob to revoke her certification of Charlie's key.

Since both Alice and Bob have certified Charlie's key, and the format
of the certficate revocation (0x30) that Bob issues is the same
whether he is acting for himself or acting as Alice's designated
revoker, the OpenPGP program has no way to tell which certification is
being revoked: is it Bob's or is it Alice's?

I don't know what the best solution for this is.  Probably the
simplest solution is to only allow designated revokers to issue key
revocations (0x20 and possibly 0x28) and not 0x30 cerfication
revocations.  Michael Young suggested a "revocation target" signature
subpacket for use in revocations.  That would work as well.

For what it's worth, neither PGP or GnuPG currently allow designated
revokers to issue 0x28 subkey or 0x30 certification revocations.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g3I0MLr10993 for ietf-openpgp-bks; Wed, 17 Apr 2002 17:22:21 -0700 (PDT)
Received: from smtprelay7.dc2.adelphia.net (smtprelay7.dc2.adelphia.net [64.8.50.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3I0MKm10989 for <[e-mail]>; Wed, 17 Apr 2002 17:22:20 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay7.dc2.adelphia.net (Netscape Messaging Server 4.15 smtprelay7 Dec  7 2001 09:58:59) with SMTP id GUQMCW00.MP9 for <[e-mail]>; Wed, 17 Apr 2002 20:22:08 -0400 
Message-ID: <00d501c1e66e$e3deb920$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05101585b8e3abe7a80e@[192.168.1.97]>
Subject: Revocation target subpacket (Re: What's left before a new RFC?)
Date: Wed, 17 Apr 2002 20:20:26 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

From: "Jon Callas" <[e-mail]>
> I know of no other desired changes. I would like bis-05 to be Penultimate
> Call. Does anyone object?

I still desire a "revocation target" subpacket to identify the
specific signature being revoked:

    5.2.3.1. (add:)
       31 = revocation identification 

    5.2.3.25. Revocation identification
        (1 octet PK algorithm)
        (1 octet hash algorithm)
        (N octets hash)

where the N octets are the hash from the signature being revoked.

My original suggestion did not include the PK algorithm field.
Jon Callas added that in his revised sketch.  I don't feel a need
for it, but I won't object, either.

David Shaw also suggested including the timestamp from the revocation
packet, to allow a blazingly fast comparison.  Again, I could live
with or without this.

Without the ability to revoke a specific signature, I strongly object
to multiple self-signatures being interpreted "any way it sees fit".
Yes, there's a RECOMMENDED behavior, and that may be the best we can
hope for in old implementations.  It's sad to suggest that when
conversing among new implementations, a key owner cannot update its
self-signature in a clear and unambiguous way.  But a revocation
target would satisfy my objection.  There may be other solutions to
this specific problem, such as a "supercedes" subpacket, but I don't
think they're as generally powerful or useful.

Note that I would not limit the use of this subpacket to self-signatures.
I think it would be equally meaningful for ordinary certifications,
to disambiguate between signatures with different subpackets (e.g.,
notation, trust limits, policy) or classes (e.g., 0x10 through 0x13).

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPL4Q5FMkvpTT8vCGEQLtpgCglr4beWeYJ4dUnqUpJTaaAIVwz0wAoLDN
9xGG4JMBrlsTW6npVziHw3UC
=nwLd
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HNoQK10522 for ietf-openpgp-bks; Wed, 17 Apr 2002 16:50:26 -0700 (PDT)
Received: from mail.mediacompany.com ([e-mail] [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HNoOm10518 for <[e-mail]>; Wed, 17 Apr 2002 16:50:24 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [194.162.148.2]) by mail.mediacompany.com (Postfix) with ESMTP id 877574803; Thu, 18 Apr 2002 01:50:24 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id 542A32ED8F; Thu, 18 Apr 2002 01:46:45 +0200 (CEST)
Date: Thu, 18 Apr 2002 01:46:45 +0200
From: Thomas Roessler <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Clearsigning, MIME, etc.
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <p05101582b8e39c870d7d@[192.168.1.97]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <p05101582b8e39c870d7d@[192.168.1.97]>
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2002-04-17 15:46:51 -0700, Jon Callas wrote:

>>In order to verify a signature I make, I suppose he'd have to 
>>re-encode the data as presented to him from cp-1252 to utf-8. 
>>(He consistently reported that he could not verify the 
>>signatures I made.)

>Yes, and this is exactly the process that I insist implementers do.

... as opposed to users!

>UTF-8 is mandated to be the default. It always has been. All text 
>is UTF-8 unless there is a tag telling you it isn't. If the 
>handwaving I do in the Charset section of 6.2 is causing problems, 
>I will be happy to remove it. I will also be happy to explicitly 
>say all text is UTF-8.

The handwaving sends one message: "In theory, it's all utf-8.  In  
practice, forget about character sets." And that's, it seems, how  
things are implemented nowadays.

>I suppose we could just declare that text is UTF-8.

I'd certainly prefer that approach. Whatever is inside a type 't'  
literal packet is considered to be utf-8.

In that case, there's no need for a charset header, except with  
clearsigning, where it should indicate the character set in which  
the cleartext has been represented while the hash.  From a  
systematic point of view, it would be reasonable to assume utf-8  
unless stated otherwise.  From a practical point of view, conversion 
should only be done if an explicitly-given character set (Charset  
header) is different from the one used to represent the data (to be  
determined out-of-band, for instance by using  
nl_langinfo(CODESET)).  If no Charset header is given, no recoding  
should happen.

>>>construct OpenPGP headers,

>>Eh?  You don't need to construct any OpenPGP headers with PGP/MIME.

>Yes, I do. If I want to construct a clearsigned message from a 
>MIMEd message, I have to figure out the right spot to insert 
>"-----BEGIN PGP SIGNED MESSAGE-----" at the very least, and maybe 
>a "Hash: SHA1" header, and maybe a character set header. It's much 
>easier for me to not verify your signature. If it were 
>clearsigned, I can just copy it into a text file.

Don't do that.  Just save the first MIME part (in on-the-wire  
format, including headers; ups) to one file, the signature to a  
second one, and treat it as a detached signature.

>>The problem with getting anything implemented is that NAI does 
>>not support PGP any more.

>Well, my exercise shows it can work with no NAI involvement.

Of course.  However, that implementation is still around, and still  
the most widely used one on the most widely used platform, I'd 
guess.

-- 
Thomas Roessler                        <[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HMwJ007417 for ietf-openpgp-bks; Wed, 17 Apr 2002 15:58:19 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HMwIm07413 for <[e-mail]>; Wed, 17 Apr 2002 15:58:18 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1) for <[e-mail]>; Wed, 17 Apr 2002 15:57:58 -0700
Mime-Version: 1.0
Message-Id: <p05101585b8e3abe7a80e@[192.168.1.97]>
Date: Wed, 17 Apr 2002 15:54:01 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: What's left before a new RFC?
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

When I sent out bis04, it had all previous changes and additions in it.

Thomas Roessler is convincing me that I may need to tighten up the language
about UTF-8. If anyone out there disagrees with him, speak up.

I'm willing to put in a note to say that the Version and Comment headers in
armor SHOULD or MUST be ASCII. I don't like it (I want everything to be
UTF-8), but I'll do it. Is UTF-7 too grotesque?

I know of no other desired changes. I would like bis-05 to be Penultimate
Call. Does anyone object?

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HMmX407223 for ietf-openpgp-bks; Wed, 17 Apr 2002 15:48:33 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HMmWm07219 for <[e-mail]>; Wed, 17 Apr 2002 15:48:32 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Wed, 17 Apr 2002 15:48:18 -0700
Mime-Version: 1.0
Message-Id: <p05101582b8e39c870d7d@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 17 Apr 2002 15:46:51 -0700
To: Thomas Roessler <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Clearsigning, MIME, etc.
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 11:33 AM +0200 4/17/02, Thomas Roessler wrote:

>Congratulations.  That was the easy part.  I suppose we agree that I
>did things the right way with my message?
>

If I didn't, then there's something broken with signatures. :-)

>In order to verify a signature I make, I suppose he'd have to
>re-encode the data as presented to him from cp-1252 to utf-8.  (He
>consistently reported that he could not verify the signatures I
>made.)
>

Yes, and this is exactly the process that I insist implementers do.


>To wrap things up:
>
> - ASCII armor proper can be fixed by giving a clear specification of
>   the character set issues involved: Either mandate UTF-8, or
>   mandate tagging and use UTF-8 as the default.  The current
>   language is considerably too fuzzy, and - I believe - mostly
>   ignored.
>

UTF-8 is mandated to be the default. It always has been. All text is UTF-8
unless there is a tag telling you it isn't. If the handwaving I do in the
Charset section of 6.2 is causing problems, I will be happy to remove it. I
will also be happy to explicitly say all text is UTF-8.

My intent in any fuzziness in that language is because in the real world,
text is often tacitly tagged -- as you've mentioned in detail. The real
message is supposed to be, "go ahead and interpret it any way you want, but
you're on your own."

I suppose we could just declare that text is UTF-8. That doesn't solve the
problem completely, because there's always binary data, and if I send you
binary data that represents 8859-1, and you interpret it as 8859-15, we
still have a problem.

>>construct OpenPGP headers,
>
>Eh?  You don't need to construct any OpenPGP headers with PGP/MIME.

Yes, I do. If I want to construct a clearsigned message from a MIMEd
message, I have to figure out the right spot to insert "-----BEGIN PGP
SIGNED MESSAGE-----" at the very least, and maybe a "Hash: SHA1" header,
and maybe a character set header. It's much easier for me to not verify
your signature. If it were clearsigned, I can just copy it into a text file.


>The problem with getting anything implemented is that NAI does not
>support PGP any more.
>

Well, my exercise shows it can work with no NAI involvement.

>
>Finally, hard failures of clearsigning: You can only avoid these by
>making sure that no lossy recoding happens as the data travels from
>signer to verifier. Encouraging people to use utf-8 on the wire (so
>there is at least no lossy recoding on the sending side) may help,
>but you won't get rid of all the problems that way.
>
>
>Note that both kinds of clearsigning failures don't occur with
>PGP/MIME: The signed material is invariant under the transformations
>which can reasonably be expected to happen.

Sure. But my grumpiness with OpenPGP/MIME is that I have no software that
does it and don't see how I'm going to get any. It's purely practical.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id g3HLcLP05467 for ietf-openpgp-bks; Wed, 17 Apr 2002 14:38:21 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HLcKm05461 for <[e-mail]>; Wed, 17 Apr 2002 14:38:20 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Wed, 17 Apr 2002 14:37:59 -0700
Mime-Version: 1.0
Message-Id: <p05101581b8e39b5dc7b9@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 17 Apr 2002 14:37:25 -0700
To: Thomas Roessler <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: literal data packet tags - nit
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 11:15 AM +0200 4/17/02, Thomas Roessler wrote:
>	Earlier implementations also used a vlaue of 'l' as a
>	'local' mode for machine-local conversions.  In RFC 1991,
>	this value is (wrongly) given as 'ASCII 1'.  The use of
>	either of these literal data packet types is now deprecated.

Thanks. Here is what I put into bis-05:

Early versions of PGP also defined a value of 'l' as a 'local' mode for
machine-local conversions. RFC 1991 incorrectly stated this local mode flag
as '1' (ASCII numeral one). Both of these local modes are deprecated.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HKlIs01498 for ietf-openpgp-bks; Wed, 17 Apr 2002 13:47:18 -0700 (PDT)
Received: from mout1.freenet.de ([e-mail] [194.97.50.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HKlHm01494 for <[e-mail]>; Wed, 17 Apr 2002 13:47:17 -0700 (PDT)
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtp (Exim 3.33 #4) id 16xwKf-000703-00 for [e-mail]; Wed, 17 Apr 2002 22:47:13 +0200
Received: from a61f2.pppool.de ([213.6.97.242] helo=daredevil) by mx2.freenet.de with esmtp (Exim 3.33 #4) id 16xwKf-0001qi-00 for [e-mail]; Wed, 17 Apr 2002 22:47:13 +0200
Received: from twoaday by daredevil with local (Exim 3.33 #1 (Debian)) id 16xwLB-0002A3-00 for <[e-mail]>; Wed, 17 Apr 2002 22:47:45 +0200
Date: Wed, 17 Apr 2002 22:47:45 +0200
From: Timo Schulz <[e-mail]>
To: [e-mail]
Subject: Re: sha-1 protected test key
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.0i
X-PGP-KeyID: BF3DF9B4
X-PGP-Request: lynx -source http://www.winpt.org/twoaday.asc
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed Apr 17 2002; 21:52, Imad R. Faiad wrote:

> Can you please advise what do you mean by
> "sha-1 protected key"?  As I see no such
> term anywhere in RFC440-bis04.

In section 5.5.3. Secret Key Packet Formats

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



        Timo


Received: by above.proper.com (8.11.6/8.11.3) id g3HK2Ih28586 for ietf-openpgp-bks; Wed, 17 Apr 2002 13:02:18 -0700 (PDT)
Received: from pacific.terra.net.lb (pacific.terra.net.lb [212.98.130.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HK2Em28578 for <[e-mail]>; Wed, 17 Apr 2002 13:02:15 -0700 (PDT)
Received: from irf2 ([212.98.154.225]) by pacific.terra.net.lb (InterMail vK.4.03.03.00 201-232-128 license 20eea39b78605e6864d58825b8a469a8) with SMTP id <20020417200149.BTIW9985.pacific@irf2> for <[e-mail]>; Wed, 17 Apr 2002 23:01:49 +0300
From: "Imad R. Faiad" <[e-mail]>
To: [e-mail]
Subject: Re: sha-1 protected test key
Date: Wed, 17 Apr 2002 21:52:30 +0200
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Mailer: Forte Agent 1.91/32.564
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3HK2Hm28579
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Can you please advise what do you mean by
"sha-1 protected key"?  As I see no such
term anywhere in RFC440-bis04.

TIA

Imad R. Faiad

On Wed, 17 Apr 2002 17:57:15 +0200, you wrote:

>Hi!
>
>I implemented the new SHA-1 checksum for secret keys.  2 files
>protected with this new method are attached: Romeo uses CAST5 and
>Sierra AES.  The passphrase for both is "test". 
>
>Note, that the keys are the regular GnuPG demo keys, so take care if
>you are already using these keys.
>
>  Werner

-----BEGIN PGP SIGNATURE-----

iQEVAwUBPL22U7zDFxiDPxutAQLb3AgAmDA5ggBWs1z2pLC+TR+PdcO2gfSCCpDC
Y3PVv4SjY2UzVWhlTZTTdiZW9KED16pg1TWwpYmJ4IvQElamAtqqZk6/3elQKL+r
BdfRu6x1quxRxL6PKOI5xHukWHgnk3v36vaLOxwpjPrUVTPSBjsFgZ1esWMfA99U
h4nU42j8vSN+sJIuXlGofOJ0/Yn9XbEfoSSYRTg+Lu1SOS+snsuZhCFZne6FupvO
R9u7EJdnXG7+3A3fNOp5WCng1GlbYCzjiCCaRRRGtIL2b/7Tsq0gPhofWhyw7nB4
pSf5n6BRcKt3XkEQElrmk8kBCeOV99/auF9+cGQq33YERAj9I5q6cQ==
=88Cp
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HFtxr13071 for ietf-openpgp-bks; Wed, 17 Apr 2002 08:55:59 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HFtvm13062 for <[e-mail]>; Wed, 17 Apr 2002 08:55:57 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16xsWe-0002lx-00; Wed, 17 Apr 2002 18:43:20 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16xro3-0003ru-00; Wed, 17 Apr 2002 17:57:15 +0200
To: [e-mail]
Subject: sha-1 protected test key
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est.
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Wed, 17 Apr 2002 17:57:15 +0200
Message-ID: <[e-mail]>
Lines: 15
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-=-=

Hi!

I implemented the new SHA-1 checksum for secret keys.  2 files
protected with this new method are attached: Romeo uses CAST5 and
Sierra AES.  The passphrase for both is "test". 

Note, that the keys are the regular GnuPG demo keys, so take care if
you are already using these keys.

  Werner


--=-=-=
Content-Disposition: attachment; filename=romeo.asc
Content-Description: test key Romeo

-----BEGIN PGP PRIVATE KEY BLOCK-----
Version: GnuPG v1.0.6e-cvs (GNU/Linux)

lQHhBDbjrjgRBACU0OjVoC32Kh/dUjXPdN6HIusEhHheYpFIzYHHTYJmFBEjBj9C
wrpYGjGUmp+BS2wFS59zO2MlpQGLGrmo+YGBdio338Hwdm8baeScd2Koqu+oWkCo
BMm2VxxbS3M8kq0ppNu2Q5EEO/qGywVrVpfBM3siM3mcsjVaHyWy+T1IqwCg/lng
gNIr+Yz2HoU9GwCwBi9331kD/jRTBAuXTq7vAG2bGpJ0X/zqSMLSRZfwnZj28hx6
I0SIT0yZU1xggrAgzSbB24XnQSSxWMR2BZQmupPdHO0l8xPn5KCbYo4C+9+Zsprx
EXg09KtVcMOsV6qTq40NPSOdRRNAVhOOTg/GD0qX5r9ztB57qpefmp4Nfy5tmo3S
ehfRA/9jkdKCLrZRsE/kH57kGoT5kt4nvJW2X3T03BMKvspVm3WjdlrR0Ji0yiw9
P05sCMJqeFKe4RZreG6i606CitZpRIRbpjfMEq838zgUDv7VGF7zqCedYu36sepf
kzxj/slNyu6A21HTgMWxiBrkDXoIuxMPFKYzZGC+nCHXgW2uof4DAwLyji1Xfy9P
iWDPL5uLWU2PDuRD0mbdg2Qdh39W5uTESUAJIid3a4TCd4V+TpsqzW39+EO98GjE
ycNd17QpUm9tZW8gVGVzdCAoZGVtbyBrZXkpIDxyb21lb0BleGFtcGxlLm5ldD6I
VQQTEQIAFQUCNuOuOAMLCgMDFQMCAxYCAQIXgAAKCRA72+2xd3++06vgAJ9dFoyZ
gDHJ9aQRcBNvHiKrVM+W7ACgqDYu6GvxxVUGUcqSke0goY3s/dKdAbgENuOuZhAE
AInmt6zi1dFmPfqzs/gplZR/RgLya0vHF40Rd7lyQC2fyAx9xJAngx6Lg7UQG+sp
n0PPbwSa/QWYN3roNR3jJtEiTU83yRavL1S4YsB/9UECQwjJeFgIScHvBGw2PiQX
kOFiLK16nbB6Q+hxk7YYBSgjJjbIw1vabaDYrxScrZAHAAMFA/4jGKHej776LTZf
CLjA57tqujbFJ4GYf1vycRony/xFUtE7QCChHgYvMp5M5+/nsVTjy2VjuzG2HoU7
F4lpCRLWcPUtGlvcZQNmvuoz/I4ZinRaF1GAZb5zR5hrfaDlqOrbOff4fUvjKuZF
JkzieZnlld72KOQazRQ1iqaLSAFjGv4DAwLyji1Xfy9PiWBpPXdVAeognbHWj3BB
DbrG/ZBQIEE33f4c+ZJm+KNvWiIHSA5y42etV044/uLtS4nF71SJyci94b2PZYH8
SP+TBy+kTynaa/vkk5RsnUlHKaR6RmUdBqGLY+4PwnX4O+BWKBS0drfhV7wMY24X
i/ejH0lmS7F1g1H1nKBsmJI5tdsbxA0/V9meWoAWSgZcB1pVVWQ+SosLS3PVBBq1
QohGBBgRAgAGBQI2465mAAoJEDvb7bF3f77TSdEAoJC9HJC3mk2hZumPxu1+oYrT
SOk4AKCNIhMbMI1RGMc8I8QEA+qA5UOHgA==
=Xus7
-----END PGP PRIVATE KEY BLOCK-----

--=-=-=
Content-Disposition: attachment; filename=sierra.asc
Content-Description: test key Sierra

-----BEGIN PGP PRIVATE KEY BLOCK-----
Version: GnuPG v1.0.6e-cvs (GNU/Linux)

lQHpBDbjrwQRBADFLZOACYlz942iqSIW4twe90tkmeu6yswZInI3pacFpOi53bAq
2y7CFrA3/HzbYodK/QLPtmq3wKZDZcLghqtWZTxhhhH9fDqj8Rb54IVRGw3XKLD+
GyJt5OhtrIBWzJevMQBp07ZEuRn8+N7k7s5z83WZxmyIz9LgZj32ZOhluwCg4YuI
bbsa92PrnfZcdW1jPSqlLQMEAIkWB5utOUWVQZHc5X2MdSMIJ/5fAoatzLD63wTL
JWqQZ6tWp9v5xED5riHXvQugCzdbdNwx6SqJ8dl4I2Fc/KYLcthVO7cUkpthBPve
+XV6d6L+E3w9SsZLDpe+9DwM4sS3zYT1tauANnBK7hoDu+KhF9/3wGtSdJ0Sg4Jg
P5oGA/9k0mSgmhR6HNyB0J5MoJhs82TaVWVdvtZCAfGdoTaPVfNT2Kc5WFfEpRud
Wo1tRt3j3LYuyTiD+jKrjVG2EeEzs2ctQ6uPlaqmQgenzniCi+NCCigKDDA2BTS6
fc3E/rOvug0zx9u3hNVhLfjUIwYK9qHwv+IgFP55gGJqOMZ+2P4HAwIhgJF4snTD
KWDtN4bjHmCZtz6R2oRrd/us5Y2LzP7AgdOut8lMhuTaGw32ny3KdUl34Gz1uYwJ
SogAMIhKSkotxkcKtCtTaWVycmEgVGVzdCAoZGVtbyBrZXkpIDxzaWVycmFAZXhh
bXBsZS5uZXQ+iFUEExECABUFAjbjrwQDCwoDAxUDAgMWAgECF4AACgkQpeZ/f6Ou
PqGvfwCgmiW4+LHNewi8DDrrxVXo5OJsFEEAn3K6UBmaMfewetDIEEbP8JJUhFVn
nQHABDbjr4AQBAC4cckdPiWgQNkGvAm3q8FxzRLog68/jffvj8Mvt++XQ4NikO0V
J8ezYkVd+vG3v5RoHTISynmMWZZjT56aFDSDZPOkQs2G0qZgAEgTpzCUBdlnUC8Z
rHSTSQjCn7HtR2cpYCCUBliPtatDvS3Me1XdRfBhXib04TB0ci6DrzFQkwADBQQA
je0R1INm9GkZKAzTECi+lVei7wbXkn4JF6n9r1KL5oULVF8aGHNEJ1Twj7kuq2ka
cYjc/Di4KdESRTZN9szlZnNruvAd9JKHIgbeysene3yRhy+YFaqXm1MtWCdwwaDi
DoHDASpl55RtuCKxz6uW77qhrZ8E6GRDrhI92R88Dbn+BwMCIYCReLJ0wylgTRBt
VE4l4DEdP+v/E4umHUJKH17E4LhXnQ+99hSsX8sHKA6zXtu2v301WmlN3siZF/UA
VVZzYteNrlYMC+l933zJ1hk26vfZAeYWo1fzTSnZa1YrlY9+/9a4COpKnvXcZUBX
gGNDjr2nJQmt+b+3s77g2yli988kwVEVmQ8Xk/vSwoxM9mosrk73PaQpg7WY3OwE
sD89B8etjHrRk6IuYnCqS9y2dIhGBBgRAgAGBQI246+BAAoJEKXmf3+jrj6hMx8A
oKN37r3LagUdczPpRoorWgnKER/fAKDNombBtqtcolNzHm1Fg8XDworkTA==
=cqxT
-----END PGP PRIVATE KEY BLOCK-----

--=-=-=--



Received: by above.proper.com (8.11.6/8.11.3) id g3HDGZV03126 for ietf-openpgp-bks; Wed, 17 Apr 2002 06:16:35 -0700 (PDT)
Received: from mail.mediacompany.com ([e-mail] [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HDGXm03122 for <[e-mail]>; Wed, 17 Apr 2002 06:16:33 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [194.162.149.4]) by mail.mediacompany.com (Postfix) with ESMTP id 217644803 for <[e-mail]>; Wed, 17 Apr 2002 15:16:33 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id 397452ED13; Wed, 17 Apr 2002 15:13:15 +0200 (CEST)
Date: Wed, 17 Apr 2002 15:13:15 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Re: bis04: Armor headers w/ non-us-ascii values
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2002-04-17 14:28:03 +0200, Marc Mutz wrote:

>I'm missing a clear note that Armor Headers SHOULD (or even MUST) be US-ASCII 
>only (key and esp. value). 

MUST.

-- 
Thomas Roessler                        <[e-mail]>


Received: by above.proper.com (8.11.6/8.11.3) id g3HD1D002473 for ietf-openpgp-bks; Wed, 17 Apr 2002 06:01:13 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HD1Bm02469 for <[e-mail]>; Wed, 17 Apr 2002 06:01:11 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (ppp36-137.hrz.uni-bielefeld.de [129.70.36.137]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]> for [e-mail]; Wed, 17 Apr 2002 15:01:06 +0200 (MET DST)
Date: Wed, 17 Apr 2002 14:28:03 +0200
From: Marc Mutz <[e-mail]>
Subject: bis04: Armor headers w/ non-us-ascii values
To: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I'm missing a clear note that Armor Headers SHOULD (or even MUST) be US-ASCII 
only (key and esp. value). We discussed the problem a few months ago. Non 
US-ASCII header values conflict with the intend of ascii armoring and with 
rfc3156, which states that application/pgp* always are 7bit. 
app/pgp-signature and app/pgp-keys are the ones that are actually affected.

Problematic headers include "Comment" (which e.g. gnupg allows the user to 
specify) and "Version" (where localized).

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vWpU3oWD+L2/6DgRAlJpAJ93NbFWIdoHKoiReh6+znutPAXk0wCg7LX2
W6aRY/myB8cclJmAUwV1Dy4=
=5wzx
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3H9ZBk16467 for ietf-openpgp-bks; Wed, 17 Apr 2002 02:35:11 -0700 (PDT)
Received: from mail.mediacompany.com ([e-mail] [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H9Z8m16456 for <[e-mail]>; Wed, 17 Apr 2002 02:35:09 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [62.144.244.114]) by mail.mediacompany.com (Postfix) with ESMTP id 960AB4809; Wed, 17 Apr 2002 11:34:55 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id 102EF2ED90; Wed, 17 Apr 2002 11:33:58 +0200 (CEST)
Date: Wed, 17 Apr 2002 11:33:57 +0200
From: Thomas Roessler <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Clearsigning, MIME, etc.
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2002-04-16 18:05:51 -0700, Jon Callas wrote:

>Clearsigning is not armoring. They are different. If I hear  
>armoring, and you talk about clearsigning, we're going to talk at  
>cross purposes. I understand your comments on clearsigning, but  
>lets's take them one step at a time.

I'm sorry for the confusion.  With armoring proper (everything  
except clearsigning) the only problem is that an implementation  
needs to know, somehow, what character set the cleartext is in.

That can easily be solved by making the Charset header mandatory,  
and specifying that text without a charset header is to be assumed  
utf-8 under all circumstances.  I'll cover that in another message.

The only question in this context is if the charset information  
shouldn't be part of the text packet, i.e., inside the  
cryptographical envelope.  I suppose that would be cleaner; also, it 
would solve tagging when ASCII armor is not used.  Alternatively,  
get rid of the Charset header and make utf-8 mandatory for text.

But back to clearsigning.

>[Note: There are unicode characters below.]

... which show up as question marks, because I'm not (yet ;-)  
operating in a full utf-8 environment - in fact, most things are  
just running in a iso-8859-15 locale, where the characters you used  
just can't be displayed.  But that's actually a fine example: Just  
cutting & pasting what's displayed (which may be needed with some  
systems) would be impossible in this case, because a lossy encoding  
had to take place.

>??? Your message displays properly under Entourage X on my Mac.  
>Yay! It also displays correctly with Mail.app, which ships with  
>OSX. It does not display correctly under Eudora for OSX. Boo (?).  
>If I take said message, paste it into BBEdit, it displays  
>correctly. Yay! If I save out said message in UTF8 with DOS line  
>ends (another ? for BBEdit), it verifies correctly with GPG 1.06.  
>Another yay!

That's not so unexpected, isn't it?  After all, no lossy 
re-encodings were involved, and you ultimately saved the message in 
its original character set.

>I have a mail client and text editor that both displays UTF-8 and  
>verifies your clearsigned message. It even works in spite of the  
>fact that your message has trailing whitespace on its lines. So  
>this *is* possible to do! Just get a Mac. Failing that, convince  
>some MUA developers to do the right thing on Windows and Linux.

Congratulations.  That was the easy part.  I suppose we agree that I 
did things the right way with my message?  


In this case, I'd suggest you tell this to vedaal who used PGP 6.5.8 
[ckt] with outlook like many, many others do.

In order to verify the signature under the message he sent to the  
list yesterday, you'll have to second-guess that his computer uses  
cp-1252 as the local character set.  You then have to explicitly  
recode the text to that character set in order to get the signature 
verified.

In order to verify a signature I make, I suppose he'd have to  
re-encode the data as presented to him from cp-1252 to utf-8.  (He  
consistently reported that he could not verify the signatures I  
made.)


Another member of this list who uses Lotus Notes 4.5 on NT4 also  
reported that the signature verification failed, but the message  
displayed (mostly) correctly.  Of course, he's quite close to MUA  
hell, so in that case I suppose verifying _some_ signatures already  
counts as a success.  (Thanks for your help!)

>This exercise I went through proves my point, to my mind. With a 
>clearsigned message, I can see the intended characters as well 
>verify the message's signature. In short, the system works. 

The system works as long as everyone and everything involved uses  
the same charset, which is the case in our example.  I never  
disputed that.  

The problem is that the system breaks as soon as _different_ 
character set worlds are involved.

It breaks "softly" in the windows case, where things become unusable 
for the average user, and cumbersome for someone who kind of knows  
what he is doing.

It breaks the hard way as soon as lossy recodings are involved,  
since these will ruin signatures.

>More to the point, if the message were not clearsigned, if it were 
>MIMEd, I would be unable to easily go to the trouble of verifying 
>the message using a text editor and GPG. I would have had to pry 
>open MIME parts, 

Yes.

>construct OpenPGP headers, 

Eh?  You don't need to construct any OpenPGP headers with PGP/MIME.

>Nonetheless, I'd love to hear what you have to say about 8859-1 
>and 8859-15. I've gone and looked up 8859-15 (which I'd never 
>heard of before), and would like to hear your insights.

iso-8859-15 is the replacement for iso-8859-1 with the Euro sign  
added (instead of the currency symbol), and with some characters  
such as "LATIN {CAPITAL,SMALL} LETTER S WITH CARON", "LATIN  
{CAPITAL,SMALL} LETTER Z WITH CARON" added instead of "ACUTE  
ACCENT", "CEDILLA", "BROKEN BAR", "DIAERESIS".  (I think there are  
some more changes, but these are the ones I immediately recall.)

Obviously, the transformation between the two can't be guaranteed to 
be loss-free.  That is, as soon as you (have to) recode between 
these, a signature may be broken.



To wrap things up:

 - ASCII armor proper can be fixed by giving a clear specification of 
   the character set issues involved: Either mandate UTF-8, or  
   mandate tagging and use UTF-8 as the default.  The current  
   language is considerably too fuzzy, and - I believe - mostly  
   ignored.

 - With clearsigning, the "soft" failures (I suppose these are the  
   more common ones) can be avoided by either mandating that the 
   signed material is to be recoded from the local representation 
   (which must be known out-of-band) to utf-8 before signing and 
   verifying, or by mandating that the character set used when 
   generating the signature is indicated in an appropriate tag.


The problem with tagging is that implementations are encouraged to  
use proprietary character sets.  Probably, a note about being  
conservatives about the character sets used should be added.

The problem with getting anything implemented is that NAI does not 
support PGP any more.


Finally, hard failures of clearsigning: You can only avoid these by  
making sure that no lossy recoding happens as the data travels from  
signer to verifier. Encouraging people to use utf-8 on the wire (so  
there is at least no lossy recoding on the sending side) may help,  
but you won't get rid of all the problems that way.


Note that both kinds of clearsigning failures don't occur with  
PGP/MIME: The signed material is invariant under the transformations 
which can reasonably be expected to happen.  



-- 
Thomas Roessler                        <[e-mail]>


Received: by above.proper.com (8.11.6/8.11.3) id g3H9Yxh16423 for ietf-openpgp-bks; Wed, 17 Apr 2002 02:34:59 -0700 (PDT)
Received: from mail.mediacompany.com (postfix@[195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H9Yvm16412 for <[e-mail]>; Wed, 17 Apr 2002 02:34:57 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [62.144.244.114]) by mail.mediacompany.com (Postfix) with ESMTP id 871B44803 for <[e-mail]>; Wed, 17 Apr 2002 11:34:54 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id 04F7F2ED8F; Wed, 17 Apr 2002 11:15:58 +0200 (CEST)
Date: Wed, 17 Apr 2002 11:15:58 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: literal data packet tags - nit
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

(Section 5.9)

The language about the "l" tag in the current draft correctly  
describes the implementation in PGP-2.6.  However, it does not  
describe what is in RFC 1991, which has "ASCII 1" instead - whatever 
that's supposed to mean.

Suggestion:  Instead of "RFC 1991 ... deprecated", use the following 
language:

	Earlier implementations also used a vlaue of 'l' as a  
	'local' mode for machine-local conversions.  In RFC 1991,  
	this value is (wrongly) given as 'ASCII 1'.  The use of  
	either of these literal data packet types is now deprecated.

(This is independent of any other changes we may wish to make to  
that section.)
-- 
Thomas Roessler                        <[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3H16AK04111 for ietf-openpgp-bks; Tue, 16 Apr 2002 18:06:10 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H169m04106 for <[e-mail]>; Tue, 16 Apr 2002 18:06:09 -0700 (PDT)
Received: from [192.168.1.27] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1) for <[e-mail]>; Tue, 16 Apr 2002 18:05:58 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Tue, 16 Apr 2002 18:05:51 -0700
Subject: Clearsigning, MIME, etc.
From: Jon Callas <[e-mail]>
To: <[e-mail]>
Message-ID: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3H16Am04107
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 9:16 AM +0200 4/16/02, Thomas Roessler wrote:

>With all due respect, OpenPGP with armoring gets you into all kinds
>of hell as soon as you want to sign more than just us-ascii text,
>and as soon as you want to verify the signature on a system
>different from the one the signature was created on.  This is, in
>particular, the case when users have to feed PGP with a recoded
>version of the message.  Such recoding may be necessary in order to
>properly display the message to you.

I understand, Thomas. But I have some comments on your last message.

Clearsigning is not armoring. They are different. If I hear armoring, and
you talk about clearsigning, we're going to talk at cross purposes. I
understand your comments on clearsigning, but lets's take them one step at a
time.

[Note: There are unicode characters below.]

☞ Your message displays properly under Entourage X on my Mac. Yay! It also
displays correctly with Mail.app, which ships with OSX. It does not display
correctly under Eudora for OSX. Boo (?). If I take said message, paste it
into BBEdit, it displays correctly. Yay! If I save out said message in UTF8
with DOS line ends (another ? for BBEdit), it verifies correctly with GPG
1.06. Another yay!

[The previous paragraph contains a right-pointing hand (\u261e), a
skull-and-crossbones (\u2620), and a smiley face (\u263a). The next
paragraphs lead with the hand.]

☞ I know that you said "Windows" and I'm on a Mac. But it works. I have a
mail client and text editor that both displays UTF-8 and verifies your
clearsigned message. It even works in spite of the fact that your message
has trailing whitespace on its lines. So this *is* possible to do! Just get
a Mac. Failing that, convince some MUA developers to do the right thing on
Windows and Linux.

☞ This exercise I went through proves my point, to my mind. With a
clearsigned message, I can see the intended characters as well verify the
message's signature. In short, the system works. Some group of people have
all implemented unicode, OpenPGP, and mail handling and it all worked. To my
mind, this makes it *not* a standards issue. It is a software implementation
issue.

☞ More to the point, if the message were not clearsigned, if it were MIMEd,
I would be unable to easily go to the trouble of verifying the message using
a text editor and GPG. I would have had to pry open MIME parts, construct
OpenPGP headers, and hope I got it all right. The clearsigned message just
plain worked, even with unicode in it. I have no MIME-encoding tools. Yeah.
I could use Mutt. I know. And you could go get a Mac.

Nonetheless, I'd love to hear what you have to say about 8859-1 and 8859-15.
I've gone and looked up 8859-15 (which I'd never heard of before), and would
like to hear your insights.

    Jon






Received: by above.proper.com (8.11.6/8.11.3) id g3GHFxU10200 for ietf-openpgp-bks; Tue, 16 Apr 2002 10:15:59 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GHFwm10194 for <[e-mail]>; Tue, 16 Apr 2002 10:15:58 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3GHFje02267 for [e-mail]; Tue, 16 Apr 2002 13:15:45 -0400
Date: Tue, 16 Apr 2002 13:15:45 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: bis04
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (14% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Apr 16, 2002 at 11:01:57AM -0500, [e-mail] wrote:
> 
> 
> From: John Dlugosz
> 
> I agree that the wording doesn't belong in this document. "this is the
> format document".  If it is going to subsume the other, why not just make
> one document?  I see a similar situation with deflation vs. zipfile format.
> 
> A forward cross-reference might not be out of line, though.  Perhaps a "see
> also", as opposed to anything that could be misunderstood as a subsumation.

There is a see also in section 7 (Cleartext signature framework).  It
reads "Note that RFC 3156 defines another way to clear sign messages
for environments that support MIME."

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GG1tR03931 for ietf-openpgp-bks; Tue, 16 Apr 2002 09:01:55 -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 g3GG1rm03927 for <[e-mail]>; Tue, 16 Apr 2002 09:01:53 -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 g3GG28C18632; Tue, 16 Apr 2002 12:02:08 -0400 (EDT)
Subject: Re: bis04
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Tue, 16 Apr 2002 11:01:57 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/16/2002 12:01:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

I agree that the wording doesn't belong in this document. "this is the
format document".  If it is going to subsume the other, why not just make
one document?  I see a similar situation with deflation vs. zipfile format.

A forward cross-reference might not be out of line, though.  Perhaps a "see
also", as opposed to anything that could be misunderstood as a subsumation.

--John





Jon Callas <[e-mail]>@mail.imc.org on 04-15-2002 07:38:13 PM

Sent by:  [e-mail]


To:   Werner Koch <[e-mail]>, [e-mail]
cc:
Subject:  Re: bis04



At 4:35 PM +0200 4/15/02, Werner Koch wrote:
>Hi!
>
>Removing this requirement is a bad thing because a reader might get
>the impression that PGP/MIME had been consired to be a failed idea.
>This is definitely not the case and can't stress enough how important
>PGP/MIME is.  The fact that some mail clients are not able to support
>it is a pitty but not a reason to drop PGP/MIME.
>

I wrote a grumpy note earlier this year about this issue.

The reason I dropped it is because some implementers claim that base
OpenPGP with armoring is deprecated. This is *not* the case.

I support OpenPGP/MIME. I think it's a great idea. But I am sick of not
being able to verify messages because some implementers think that
OpenPGP/MIME is the only way to go.

I support anyone who puts in MIME encoding as an *option*. It isn't
mandatory.

The problem is that some people don't understand the difference between
SHOULD-implement and SHOULD require all users to use. Our illustrious area
directors have gone on long dissertations about the difference between
implementing and forcing users to use.

If an implementer who politically wants to support the cause of security
multiparts chooses to do so, more power to them. But when the implementer
responds to people who want to do armoring with, "Hey, don't complain to
me, complain to the standards guys who *FORCE* me to do it" (which someone
has said to me and other people), then we part company. And since I'm the
aforementioned standards guy who allegedly is holding a gun to said
developer's head, I can do something about it.

I thought long and hard about just the right thing to say that would say
"I'm okay, you're okay" and couldn't come up with one. So I thought nothing
was the best thing to say. After all, this is the *format* document. It
lays out the bits. If an implementer wants to receive 3DES but never emit
anything but AES, that's their choice. Similarly, if an implementer wants
to always emit OpenPGP/MIME, that's their choice. But I don't want to be
holding the bag for either of them.

If you can come up with wording that says MIME is great, but so is
armoring, send it and I'll look at it.

>Thanks for releasing the draft, Jon.

You're welcome.

     Jon






Received: by above.proper.com (8.11.6/8.11.3) id g3GDluM26139 for ietf-openpgp-bks; Tue, 16 Apr 2002 06:47:56 -0700 (PDT)
Received: from mail.mediacompany.com ([e-mail] [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GDlsm26132 for <[e-mail]>; Tue, 16 Apr 2002 06:47:54 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [62.144.252.253]) by mail.mediacompany.com (Postfix) with ESMTP id C63EB4803; Tue, 16 Apr 2002 15:47:53 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id D9E362ED13; Tue, 16 Apr 2002 15:47:51 +0200 (CEST)
Date: Tue, 16 Apr 2002 15:47:51 +0200
From: Thomas Roessler <[e-mail]>
To: vedaal <[e-mail]>
Cc: [e-mail]
Subject: Re: bis04
Message-ID: <[e-mail]>
Mail-Followup-To: vedaal <[e-mail]>, [e-mail]
References: <[e-mail]> <p05101569b8e11f70b514@[192.168.1.97]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB"
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--2/5bycvrmDh4d1IB
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2002-04-16 09:31:21 -0400, vedaal wrote:

>the above message was done in OE 5.5, displayed the special=20
>characters, and verified the signature vedaal

Well, I was, however, unable to verify your signature, using mutt.

--=20
Thomas Roessler                        <[e-mail]>

--2/5bycvrmDh4d1IB
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBPLwrh9ImKUTOasbBAQIBhQgAhdxhYNnejQ+DBSL0ItosvacrgayKi4PE
RdPhWedKL6vCVYMPyqyJhFEToC/xxOBC7BbVbE89T5HQtWYdSjwmIC4/78s3QROd
+HAmHh65nV5kakfXvq/mGsGFPZtI5qiplAkmhdawdWpZFDsY11IREoftvvfp6VMH
OLvQQoqSNMeYhOg+67d8wXDASXfovheiOXi4q+E+3LZ1upmkOWDhPX81LJ1/wsPy
6fcgnSEkQXxwgLaJETuutPjgZ+3Btpty1UTDrIf6Ram+7eHsnAOA6U/TNX/HWyAg
/oHWjHkXjVTledMUADShNoFy9tlu3YsvsEMHs33T3XTAyPG3yZlpDg==
=bkt4
-----END PGP SIGNATURE-----

--2/5bycvrmDh4d1IB--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GDinm25682 for ietf-openpgp-bks; Tue, 16 Apr 2002 06:44:49 -0700 (PDT)
Received: from mail.mediacompany.com ([e-mail] [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GDilm25677 for <[e-mail]>; Tue, 16 Apr 2002 06:44:47 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [62.144.252.253]) by mail.mediacompany.com (Postfix) with ESMTP id 219254803 for <[e-mail]>; Tue, 16 Apr 2002 15:44:43 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id 5B12B2ED13; Tue, 16 Apr 2002 15:43:50 +0200 (CEST)
Date: Tue, 16 Apr 2002 15:43:50 +0200
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Subject: Clearsigning considered harmful.
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed
Content-Disposition: inline
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 From draft-04, section 6.2:

>"Charset", a description of the character set that the plaintext is 
>in. Please note that OpenPGP defines text to be in UTF-8 by default. 
>An implementation will get best results by translating into and out 
>of UTF-8. However, there are many instances where this is easier 
>said than done. Also, there are communities of users who have no 
>need for UTF-8 because they are all happy with a character set like 
>ISO Latin-5 or a Japanese character set. In such instances, an 
>implementation MAY override the UTF-8 default by using this header 
>key. An implementation MAY implement this key and any translations 
>it cares to; an implementation MAY ignore it and assume all text is 
>UTF-8.

I believe that this part of the specification is a recipe for  
interoperability desasters of the most interesting kind.

First of all, the specification makes no guarantee about the kind of 
character set used for generating a cleartext signature.  This  
character set MAY be indicated by the Charset header, but it doesn't 
have to.  Implementations MAY also ignore the header.

Pretending that this header is not there is not a problem as long as 
the cleartext's character set is not changed in any way between  
signature creation and verification.

However, this assumption won't hold in reality.  Different systems  
are using different character sets; in order to properly display an  
e-mail message, you will have to recode it.  Just think about the 
different ways to add the Euro symbol to character sets, or think 
about using utf-8 for messages.

All this is getting particularly bad in the context of cleartext  
signatures: In this case, people will frequently use cut & paste in  
order to pass the signature and signed material to the verification  
service.  In order to correctly verify a signature, the verification 
service would have to re-encode it, and hope that the original  
signed material is restored.  In order to do this, implementations  
need to know what encoding was used when the original signature was  
generated.  I.e., they will have to generate _and_ respect a  
Charset header.

(Note, however, that re-encodings in a way which assures correct  
signature verification may not be possible if the encoding for  
display purposes was lossy. For instance, you cannot recode  
loss-free between iso-8859-1 and iso-8859-15 in all cases.  Both  
character sets are being used in the European Union, with, it seems, 
iso-8859-15 gaining momentum.)


My suggestion is that we either introduce mandatory rules for the  
character set issues, or add clear language which indicates that  
clearsigned signatures impose cnsiderable interoperability risks  
when used outside closed environments with homogeneous software  
istallations.

- -- 
Thomas Roessler                        <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iQEVAwUBPLwqltImKUTOasbBAQImrwf/dj5l/XKh2dF6pTvKE9d8+gi4YjV5xRyf
bJBa87gCSMaTAz67tDTYsLWifyvvNtjkQTXhJtL4T015fSbQwJwcML1CCBtygIm6
yNaYrsJRjUMr0vzXJT14p0E1ZoETGFzXx13sxZJfad5i6ccrEeveVGZpnabf8QY9
XGNpQSOAeK9yU/jMPFJRRcCpKdE8upOji6Uu+2tT5ZWDul4MpGfM3Ez4CxDFhZo6
zd1oEE9MMbEH30+FGlhkQM/n879E6LX0hz+1QdUHUWX8wQDW/GDSJbbtOYrMeVnX
ADfFZnc8SdlN0ue4+5Jp886vu9onqwgx9WdHDGzzJtixb72Vv2UMww==
=OpCe
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GDX9P24245 for ietf-openpgp-bks; Tue, 16 Apr 2002 06:33:09 -0700 (PDT)
Received: from hotmail.com (oe65.law3.hotmail.com [209.185.240.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GDX8m24241 for <[e-mail]>; Tue, 16 Apr 2002 06:33:08 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 06:32:59 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <p05101569b8e11f70b514@[192.168.1.97]> <[e-mail]>
Subject: Re: bis04
Date: Tue, 16 Apr 2002 09:31:21 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Apr 2002 13:32:59.0463 (UTC) FILETIME=[39979D70:01C1E54B]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

- ----- Original Message -----
From: "Thomas Roessler" <[e-mail]>
To: "Jon Callas" <[e-mail]>
Cc: "Werner Koch" <[e-mail]>; <[e-mail]>
Sent: Tuesday, April 16, 2002 3:16 AM
Subject: Re: bis04
...
> Here's a test - this message is encoded in utf-8, it's clearsigned,
> and here is a number of special characters: € ä ö ü æ ç
>
> Using widespread Windows software, can you find a messaging program
> which (1) verifies the signature AND (2) correctly displays the
> special characters (Euro symbol, a-umlaut, o-umlaut, u-umlaut, ae
> ligature, c-cedilla)?  Please tell us.
...
could not verify your signature, but could see the special characters,
have been able to both verify signatures and display special characters,
using the very common
OE 5.5 set to allow utf-8 encoding

vedaal

-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt   build 7      http://www.ipgpp.com/
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  D9AE 02FD A711 97BA

iQEVAwUBPLwnP2oFoLeFMG0lAQNOJggAtK746tjFd4J39FpXpbkdjVA66yoJHT5U
SU3zscdYdbeDsl91GLn1JG+wYoXQJtrYXPsiBjRRArg0BQh7hRRuvuHKtMUREHpL
wH5jucrthi1T1dedgYC6cNkTAnAECoKDR+rxwMxmJRmmXwK1pR1CNH/DuFxkNdJ0
zBhrC53f6zUz+zKm2/jD+KGtBHSbUBp/kjGznk0RAsVynahuzl0vFc9cPRBaZFNu
xT/Buy6JtQv5uDrzHaFoQpGex1MY2eNh7gQo2cmwfH6cqgFwJMmnD4wd8vNFOfZT
uyGgR05T673wi38TwcFcp9baDm8RRwwJ0YLNapVYNz51W9IE9Embjw==
=Yuvv
-----END PGP SIGNATURE-----
n.b.
the above message was done in OE 5.5, displayed the special characters, and
verified the signature
vedaal


Received: by above.proper.com (8.11.6/8.11.3) id g3G7M7502682 for ietf-openpgp-bks; Tue, 16 Apr 2002 00:22:07 -0700 (PDT)
Received: from mail.mediacompany.com ([e-mail] [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G7M5m02677 for <[e-mail]>; Tue, 16 Apr 2002 00:22:05 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [62.144.252.28]) by mail.mediacompany.com (Postfix) with ESMTP id 1FA6F4803; Tue, 16 Apr 2002 09:21:36 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id 0CC992ED13; Tue, 16 Apr 2002 09:16:38 +0200 (CEST)
Date: Tue, 16 Apr 2002 09:16:38 +0200
From: Thomas Roessler <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: Werner Koch <[e-mail]>, [e-mail]
Subject: Re: bis04
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, Werner Koch <[e-mail]>, [e-mail]
References: <[e-mail]> <p05101569b8e11f70b514@[192.168.1.97]>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; x-action=pgp-signed
Content-Disposition: inline
In-Reply-To: <p05101569b8e11f70b514@[192.168.1.97]>
User-Agent: Mutt/1.5.0i
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3G7M6m02678
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2002-04-15 17:38:13 -0700, Jon Callas wrote:

>The reason I dropped it is because some implementers claim that 
>base OpenPGP with armoring is deprecated. This is *not* the case.

With all due respect, OpenPGP with armoring gets you into all kinds  
of hell as soon as you want to sign more than just us-ascii text,  
and as soon as you want to verify the signature on a system  
different from the one the signature was created on.  This is, in  
particular, the case when users have to feed PGP with a recoded 
version of the message.  Such recoding may be necessary in order to 
properly display the message to you.

Here's a test - this message is encoded in utf-8, it's clearsigned,  
and here is a number of special characters: € ä ö ü æ ç

Using widespread Windows software, can you find a messaging program 
which (1) verifies the signature AND (2) correctly displays the 
special characters (Euro symbol, a-umlaut, o-umlaut, u-umlaut, ae 
ligature, c-cedilla)?  Please tell us.

>If you can come up with wording that says MIME is great, but so is 
>armoring, send it and I'll look at it.

How about this?

	Note: A specification for using MIME to encapsulate OpenPGP  
	signed or encrypted messages, and for signing and encrypting 
	complex MIME objects with OpenPGP, can be found in RFC 3156.

I'll send a separate message with somewhat more on the character
set issues later today.

- -- 
Thomas Roessler                        <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iQEVAwUBPLvP1dImKUTOasbBAQKr6wgAwHjiE9UzYcSvhQjmFyj4Fq34S54UmOKR
RrF70Ecuofy77GrLapkqybhMdKlxobrncoTVE3QLnXwhvaaHD+9JIycUeu07h2nI
ce1KBZei1CJDq0J8LY81lLAIcrOQFtkporpBKITqNdaN/AUTKOfTD+5pT+D8PWq7
EaAP8ZXyvr4Ydswx1u1cPNM5Y79bZCsmnpaJuwqPSM8XMo6+x8FFS6lKtiZuVazP
eoKcE1PF+UU4/hEh/FB3ypivgmykwSIAOJmSaztZr/Rrf8OWaUxodZTL6Y1lz0aJ
FoOmlZDEsiUcvw2VOA+Nh5sM+Fc+EcSVm1SGNrQs1V70ZbZJK5yqZw==
=LZ1m
-----END PGP SIGNATURE-----


Received: by above.proper.com (8.11.6/8.11.3) id g3G0nJN08732 for ietf-openpgp-bks; Mon, 15 Apr 2002 17:49:19 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G0nHm08728 for <[e-mail]>; Mon, 15 Apr 2002 17:49:18 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Mon, 15 Apr 2002 17:49:01 -0700
Mime-Version: 1.0
Message-Id: <p05101569b8e11f70b514@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 15 Apr 2002 17:38:13 -0700
To: Werner Koch <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: bis04
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 4:35 PM +0200 4/15/02, Werner Koch wrote:
>Hi!
>
>Removing this requirement is a bad thing because a reader might get
>the impression that PGP/MIME had been consired to be a failed idea.
>This is definitely not the case and can't stress enough how important
>PGP/MIME is.  The fact that some mail clients are not able to support
>it is a pitty but not a reason to drop PGP/MIME.
>

I wrote a grumpy note earlier this year about this issue.

The reason I dropped it is because some implementers claim that base
OpenPGP with armoring is deprecated. This is *not* the case.

I support OpenPGP/MIME. I think it's a great idea. But I am sick of not
being able to verify messages because some implementers think that
OpenPGP/MIME is the only way to go.

I support anyone who puts in MIME encoding as an *option*. It isn't mandatory.

The problem is that some people don't understand the difference between
SHOULD-implement and SHOULD require all users to use. Our illustrious area
directors have gone on long dissertations about the difference between
implementing and forcing users to use.

If an implementer who politically wants to support the cause of security
multiparts chooses to do so, more power to them. But when the implementer
responds to people who want to do armoring with, "Hey, don't complain to
me, complain to the standards guys who *FORCE* me to do it" (which someone
has said to me and other people), then we part company. And since I'm the
aforementioned standards guy who allegedly is holding a gun to said
developer's head, I can do something about it.

I thought long and hard about just the right thing to say that would say
"I'm okay, you're okay" and couldn't come up with one. So I thought nothing
was the best thing to say. After all, this is the *format* document. It
lays out the bits. If an implementer wants to receive 3DES but never emit
anything but AES, that's their choice. Similarly, if an implementer wants
to always emit OpenPGP/MIME, that's their choice. But I don't want to be
holding the bag for either of them.

If you can come up with wording that says MIME is great, but so is
armoring, send it and I'll look at it.

>Thanks for releasing the draft, Jon.

You're welcome.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G0PPA08171 for ietf-openpgp-bks; Mon, 15 Apr 2002 17:25:25 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G0POm08166 for <[e-mail]>; Mon, 15 Apr 2002 17:25:24 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Mon, 15 Apr 2002 17:25:03 -0700
Mime-Version: 1.0
Message-Id: <p05101568b8e11f3ea923@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 15 Apr 2002 17:22:55 -0700
To: [e-mail], [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: bis04
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 11:04 AM -0500 4/15/02, [e-mail] wrote:
>From: John Dlugosz
>
>The date in the headers reads April 15, 2001.

Sigh. At least it says it expires in 2002. Sorry about that.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FIgbV01094 for ietf-openpgp-bks; Mon, 15 Apr 2002 11:42:37 -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 g3FIgam01090 for <[e-mail]>; Mon, 15 Apr 2002 11:42:36 -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 g3FIgrd18872 for <[e-mail]>; Mon, 15 Apr 2002 14:42:53 -0400 (EDT)
Subject: Re: Recipient-verifiable messages
To: [e-mail]
From: [e-mail]
Date: Mon, 15 Apr 2002 13:42:43 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/15/2002 02:42:36 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

>> Anyway, both undeniable and designated confirmer signatures are patented
by Chaum, so they would probably not be suitable for use in a protocol
like OpenPGP.

In most cases, I think you can build anything out of anything else (if you
allow more round-trips), so a few primitives are all you need.  OpenPGP
provides public key encryption and ordinary signatures, as well as symetric
encryption and HMAC.  Those can be used as part of a protocol to do just
about anything.

A higher standard would say "here is how you use OpenPGP to do email" etc.
and specify such a protocol.  So, I don't think it is necessary to add any
new stuff to PGP, just to use what we have in some new way.

--John




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FGrUD28017 for ietf-openpgp-bks; Mon, 15 Apr 2002 09:53:30 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FGrTm28012 for <[e-mail]>; Mon, 15 Apr 2002 09:53:29 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3FGiPi20120; Mon, 15 Apr 2002 09:44:25 -0700
Date: Mon, 15 Apr 2002 09:44:25 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Recipient-verifiable messages
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

John Dlugosz writes:

> I just noticed this in a book I'm reading.  Section 4.3 in "Applied
> Cryptography, 2nd ed." by Bruce Schneier is on this exact subject.

Actually 4.3 is on Chaum's undeniable signatures, which are not quite the
same as what we are talking about.  An undeniable signature requires the
aid of the signer to verify the signature.  If Alice sends an undeniable
signature to Bob, he has to then run a protocol with Alice in order to
determine if the signature is good or not.  We would not want that with
PGP, as we don't assume a bidirectional channel exists between signer
and verifier.

Somewhat closer is section 4.4, the designated confirmer signature, also
by Chaum.  I seem to recall that this is what he presented to us at the
meeting in the PGP offices several years ago.  But I don't see that this
achieves the goal either.  It is basically like an undeniable signature,
where a third party is able to replace the signer as the verifier.
So Alice could sign a message and send it to Bob, and he could only
verify it with Carol's assistance.

Maybe the idea was to use the designated confirmer signature, but to
make the designated confirmer in this case be Bob himself?  Then he
could verify the signature all by himself, but no one else could verify
it without his help.  Hmmm, that doesn't seem quite right, because Alice
really doesn't want Bob to be able to verifiably show her signature to
a third party, and this use of the designated confirmer signature seems
to allow that.  So I'm not sure any more exactly what his idea was.

Anyway, both undeniable and designated confirmer signatures are patented
by Chaum, so they would probably not be suitable for use in a protocol
like OpenPGP.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g3FG4gG25400 for ietf-openpgp-bks; Mon, 15 Apr 2002 09:04:42 -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 g3FG4dm25394 for <[e-mail]>; Mon, 15 Apr 2002 09:04:40 -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 g3FG4ud22014 for <[e-mail]>; Mon, 15 Apr 2002 12:04:56 -0400 (EDT)
Subject: Re: bis04
To: [e-mail]
From: [e-mail]
Date: Mon, 15 Apr 2002 11:04:46 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/15/2002 12:04:39 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

The date in the headers reads April 15, 2001.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FFVZK20626 for ietf-openpgp-bks; Mon, 15 Apr 2002 08:31:35 -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 g3FFVYm20621 for <[e-mail]>; Mon, 15 Apr 2002 08:31:34 -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 g3FFVjd10654 for <[e-mail]>; Mon, 15 Apr 2002 11:31:45 -0400 (EDT)
Subject: Re: Recipient-verifiable messages
To: [e-mail]
From: [e-mail]
Date: Mon, 15 Apr 2002 10:31:33 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/15/2002 11:31:28 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

I just noticed this in a book I'm reading.  Section 4.3 in "Applied
Cryptography, 2nd ed." by Bruce Schneier is on this exact subject.

--John



Received: by above.proper.com (8.11.6/8.11.3) id g3FEZmM19208 for ietf-openpgp-bks; Mon, 15 Apr 2002 07:35:48 -0700 (PDT)
Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FEZjm19204 for <[e-mail]>; Mon, 15 Apr 2002 07:35:45 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16x8Ja-0003bw-00; Mon, 15 Apr 2002 17:22:46 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16x7bM-0007vP-00; Mon, 15 Apr 2002 16:37:04 +0200
To: [e-mail]
Subject: bis04
From: Werner Koch <[e-mail]>
X-PGP-KeyID:   621CC013
X-Request-PGP: finger://[e-mail]
X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est.
X-FSFE-Info:  http://fsfeurope.org
Organisation: g10 Code GmbH
Date: Mon, 15 Apr 2002 16:35:02 +0200
Message-ID: <[e-mail]>
Lines: 29
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi!

The latest draft dropped a paragraph from 2.4:

  Note that many applications, particularly messaging applications,
  will want more advanced features as described in the OpenPGP-MIME
  document, RFC2015. An application that implements OpenPGP for
  messaging SHOULD implement OpenPGP-MIME.

I might have missed it but I can't remember that we agreed on this.  I
don't want to repeat the pros and cons here as we discussed this far
too often.  

Removing this requirement is a bad thing because a reader might get
the impression that PGP/MIME had been consired to be a failed idea.
This is definitely not the case and can't stress enough how important
PGP/MIME is.  The fact that some mail clients are not able to support
it is a pitty but not a reason to drop PGP/MIME.

U.S. centric programmers didn't care about 8 bit cleanness for many
many years and users all over the rest of the world had to suffer with
this problem.  Don't let this happen again by suggesting the use of
PGP-armor.

Thanks for releasing the draft, Jon.

  Werner








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FBTId14730 for ietf-openpgp-bks; Mon, 15 Apr 2002 04:29:18 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FBTHm14726 for <[e-mail]>; Mon, 15 Apr 2002 04:29:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13009; Mon, 15 Apr 2002 07:29:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-04.txt
Date: Mon, 15 Apr 2002 07:29:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-04.txt
	Pages		: 70
	Date		: 12-Apr-02
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g3E4bwK16725 for ietf-openpgp-bks; Sat, 13 Apr 2002 21:37:58 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3E4bvm16721 for <[e-mail]>; Sat, 13 Apr 2002 21:37:57 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3E4SrZ17559; Sat, 13 Apr 2002 21:28:53 -0700
Date: Sat, 13 Apr 2002 21:28:53 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: quasi-deniable signing
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

John Kane writes:
> Call me silly, but I don't think the OpenPGP protocol really
> needs either of these modes as part of the standard.

Why is that?  What do you think of the argument that in most cases
(aside from public postings), this is the kind of signature that you
would actually prefer?  It lets your recipient verify that you sent it,
but keeps you from being possibly hurt by having your signed message
shown to someone else.

Hal Finney


Received: by above.proper.com (8.11.6/8.11.3) id g3DK1GV07289 for ietf-openpgp-bks; Sat, 13 Apr 2002 13:01:16 -0700 (PDT)
Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3DK1Fm07285 for <[e-mail]>; Sat, 13 Apr 2002 13:01:15 -0700 (PDT)
Received: from softhome.net ([209.6.136.254]) (AUTH: PLAIN [e-mail]) by softhome.net with esmtp; Sat, 13 Apr 2002 14:01:00 -0600
Message-ID: <[e-mail]>
Date: Sat, 13 Apr 2002 10:59:33 -0400
From: John Kane <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: quasi-deniable signing
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Think of the MAC scheme as one example of a 'volatile' sig.
It might be a little easier to follow in this variant:

Suppose someone anonymously publishes
  symmetric_encrypt( K, msg )    [K is a session key]
  encrypt_Bob( sign_Alice( encrypt_Bob(K) ))

Then Bob 'knows' that only he and Alice initially have K,
and since K decrypts the message, Alice is the only one
who could have encrypted it.  Bob can disclose 'msg' to
others, and can disclose K to demonstrate that he was a
recipient of the anonymously-posted message, but that's it.

Unless Bob reveals his private decryption key, he can't prove
that Alice had any knowledge of K, or of 'msg'.  Even if he
does that, he can only show Alice sent him K, and it might
have been Bob himself who 'forged' sym(K,msg).  The essence
of this scheme is that Alice never signs anything derived
from the message content, and only authenticates a shared
secret.  Anyone can generate sym(K,msg), and the signature
is not bound to the message.

(Alice can't send a message with sign_Alice(encrypt_EVE(K))
and sign_Alice(encrypt_Bob(K)) safely, because it allows Eve
to forge sym( K, msg-2 ), intercept Bob's copy of the message,
and impersonate Alice. This scheme's not appropriate for general
multiple-recipient situations.)

 ** ** **

In the other 1-of-N "how to leak a secret" scheme, Alice
needs N-1 other people's public keys to *generate* the
signature, but the resulting signature is public and can
be verified at any time by any person who knows the N
public keys.  Applying the N public keys to the N-part
signature gives the hash of the message, so the signature
is bound to the message in the normal non-volatile way.

Call me silly, but I don't think the OpenPGP protocol really
needs either of these modes as part of the standard.




Received: by above.proper.com (8.11.6/8.11.3) id g3CMiXm25718 for ietf-openpgp-bks; Fri, 12 Apr 2002 15:44:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CMiUm25714 for <[e-mail]>; Fri, 12 Apr 2002 15:44:30 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g3CMhrX18609 for <[e-mail]>; Fri, 12 Apr 2002 18:43:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 12 Apr 2002 18:44:58 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Recipient-verifiable messages
References: <[e-mail]> <p0510153cb8dbc0a982fc@[192.168.1.97]> <[e-mail]> <p0510153fb8dbd86e1539@[192.168.1.97]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> The obvious difference is this:
> 
> If the shared secret (shared by, say, Alice and Bob) used to generate a MAC
> is leaked -- suppose Charlie learns it -- then anyone, Alice, Bob, or
> Charlie can rewrite the MAC undetectably.
> 
> On the other hand if Alice generates one of these signatures and sends it
> to Bob, a third party, Teresa can verify the signature but:
> 
>  * not be able to create one of her own and
>  * cannot tell from the signature itself whether Alice or Bob made it.
> 
> I'm not sure how useful it is in the real world, but it's a fascinating thing.
> 
> I could sign a message to this list combining a dozen keys and thus create
> a presumption that I made it without explicit demonstration of it.


Thanks, Jon.  I'm still missing something though.

If the algorithm requires 1 private key and n-1 public keys to verify
(so that only the recipients can verify it), then Teresa, not being a
recipient of the original encrypted message but having a forwarded copy
of the decrypt, would not be able to verify it.

Thus by elimination you are talking about an algorithm that requires n
public keys to verify, and anyone can verify that one of n people
generated it without being able to tell which one. 
"Recipient-verifiable" seems like a misnomer for something that
recipients and not-recipients alike can verify.

Now assume that Alice gives something to Charlie, or a bug in her
software allows him to steal it.  Your job is to figure out whether
Charlie got hold of Alice's private key or the shared secret that Alice
derived from her private key and Bob's public key.

There are two possible algorithms: a
"signature-algorithm-that-is-not-a-MAC" that Teresa can verify, and a
MAC function whose key input is derived from Alice's private key and n-1
public keys.  What is the difference between those two algorithms with
respect to what they tell you about what Charlie got from Alice?  (Or
what they tell you about any other question you care to ask?)

In other words, the algorithm is a black box.  You can't see it, you can
only see the g'zoutas and you can do whatever you want with the
g'zintas.  Does the algorithm use a MAC or not?

If it walks like a MAC and it quacks like a MAC, then ...


Received: by above.proper.com (8.11.6/8.11.3) id g3C0cGu29418 for ietf-openpgp-bks; Thu, 11 Apr 2002 17:38:16 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3C0cEm29413 for <[e-mail]>; Thu, 11 Apr 2002 17:38:14 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Thu, 11 Apr 2002 17:38:05 -0700
Mime-Version: 1.0
Message-Id: <p0510153fb8dbd86e1539@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p0510153cb8dbc0a982fc@[192.168.1.97]> <[e-mail]>
Date: Thu, 11 Apr 2002 17:29:42 -0700
To: "David P. Kemp" <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Recipient-verifiable messages
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 8:06 PM -0400 4/11/02, David P. Kemp wrote:

>What is the difference between a "recipient-verifiable signature" and
>a MAC?
>
>One of the properties of a digital signature mechanism is that it
>is computationally infeasible for any entity other than the signer
>to find, for any message, a signature value that is valid for that
>message.  [HAC, p.23]
>
>Thus it would seem that a "signature" that can't be bound later
>to the signer is an oxymoron.  Why not just call it an authentication
>code, where it is accepted that anyone who can verify a MAC has
>the information necessary to create it.

The obvious difference is this:

If the shared secret (shared by, say, Alice and Bob) used to generate a MAC
is leaked -- suppose Charlie learns it -- then anyone, Alice, Bob, or
Charlie can rewrite the MAC undetectably.

On the other hand if Alice generates one of these signatures and sends it
to Bob, a third party, Teresa can verify the signature but:

 * not be able to create one of her own and
 * cannot tell from the signature itself whether Alice or Bob made it.

I'm not sure how useful it is in the real world, but it's a fascinating thing.

I could sign a message to this list combining a dozen keys and thus create
a presumption that I made it without explicit demonstration of it.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id g3C064k28643 for ietf-openpgp-bks; Thu, 11 Apr 2002 17:06:04 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3C063m28638 for <[e-mail]>; Thu, 11 Apr 2002 17:06:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g3C05Ws13763 for <[e-mail]>; Thu, 11 Apr 2002 20:05:32 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 11 Apr 2002 20:06:33 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Recipient-verifiable messages
References: <[e-mail]> <p0510153cb8dbc0a982fc@[192.168.1.97]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> 
> >David Chaum has a patent on a variation on this idea, and he gave a talk
> >at PGP several years ago in which he advocated that recipient-verifiable
> >signatures are very useful, and in fact ought to be the default for
> >an email encryption system like PGP.  As others in this thread have
> >commented, often you don't want to sign something such that you can
> >be bound by it later, but you do want to assure the recipient that the
> >message is authentic.  Only rarely do you want to make a signature that
> >anyone can read.
> >
> >Unfortunately I think that adding a new flavor of signature would tend
> >to create confusion among users who at best barely understand public
> >key cryptography.  The new kind of signature would have very different
> >security properties and usage scenarios, so it would add additional
> >complexity for people to deal with.
> 
> Could we do something both simple and useful, however?
> 
> For example, if I send a message to Alice, the signature could be made
> safely as a combo of my key and Alice's key. It would not be a
> misrepresentation in Alice's MUA for it to assume I signed it. You'd have
> to be careful in the UI, but I think it could be done. It might be able to
> be extended to multiple recipients, but with two it might be an easy
> hand-wave.


What is the difference between a "recipient-verifiable signature" and
a MAC?

One of the properties of a digital signature mechanism is that it
is computationally infeasible for any entity other than the signer
to find, for any message, a signature value that is valid for that
message.  [HAC, p.23]

Thus it would seem that a "signature" that can't be bound later
to the signer is an oxymoron.  Why not just call it an authentication
code, where it is accepted that anyone who can verify a MAC has
the information necessary to create it.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BMiVO25692 for ietf-openpgp-bks; Thu, 11 Apr 2002 15:44:31 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BMiUm25688 for <[e-mail]>; Thu, 11 Apr 2002 15:44:30 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Thu, 11 Apr 2002 15:44:17 -0700
Mime-Version: 1.0
Message-Id: <p0510153cb8dbc0a982fc@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 11 Apr 2002 15:42:02 -0700
To: "Hal Finney" <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Recipient-verifiable messages
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>David Chaum has a patent on a variation on this idea, and he gave a talk
>at PGP several years ago in which he advocated that recipient-verifiable
>signatures are very useful, and in fact ought to be the default for
>an email encryption system like PGP.  As others in this thread have
>commented, often you don't want to sign something such that you can
>be bound by it later, but you do want to assure the recipient that the
>message is authentic.  Only rarely do you want to make a signature that
>anyone can read.
>
>Unfortunately I think that adding a new flavor of signature would tend
>to create confusion among users who at best barely understand public
>key cryptography.  The new kind of signature would have very different
>security properties and usage scenarios, so it would add additional
>complexity for people to deal with.

Could we do something both simple and useful, however?

For example, if I send a message to Alice, the signature could be made
safely as a combo of my key and Alice's key. It would not be a
misrepresentation in Alice's MUA for it to assume I signed it. You'd have
to be careful in the UI, but I think it could be done. It might be able to
be extended to multiple recipients, but with two it might be an easy
hand-wave.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id g3BMAiL24218 for ietf-openpgp-bks; Thu, 11 Apr 2002 15:10:44 -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 g3BMAhm24214 for <[e-mail]>; Thu, 11 Apr 2002 15:10:43 -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 g3BMAvp03166; Thu, 11 Apr 2002 18:10:57 -0400 (EDT)
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Thu, 11 Apr 2002 17:10:47 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/11/2002 06:10:41 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

Vedaal writes, "no new signature type is needed.
this can be done now with a split key setup, for either an RSA or DH key:"


I think this would work without the split feature.  For example, when I
enter into a conspiracy with Bob, I make a new signing key for the purpose.
Send Bob the key including the private half (export it, and note the
passphrase in the message).  Encrypt that TO Bob and send it to him, and
also post it somewhere in public so Bob can't say he never got it.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BM1rF23904 for ietf-openpgp-bks; Thu, 11 Apr 2002 15:01:53 -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 g3BM1qm23900 for <[e-mail]>; Thu, 11 Apr 2002 15:01:52 -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 g3BM25p01639; Thu, 11 Apr 2002 18:02:05 -0400 (EDT)
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Thu, 11 Apr 2002 17:01:57 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/11/2002 06:01:50 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

Beautiful.

A split isn't necessary, though.  Just make a key and have the private part
known to both.





"vedaal" <[e-mail]>@mail.imc.org on 04-11-2002 03:43:56 PM

Sent by:  [e-mail]


To:   <[e-mail]>
cc:
Subject:  Re: Recipient-verifiable messages, was: forwarding an encrypted
      PGP message is useless




----- Original Message -----
From: "Hal Finney" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, April 11, 2002 11:45 AM
Subject: Recipient-verifiable messages, was: forwarding an encrypted PGP
message is useless
...

> I proposed a different method, which basic idea is expressed in a paper
> by Rivest, Shamir and Tauman, "How to Leak a Secret", available from
> http://theory.lcs.mit.edu:80/~rivest/publications.html.  This paper shows
> how to produce a signature which can be verified to be from a specific
> list of keys, but you can't tell which key on the list made the
signature.
> It is very simple and efficient for RSA keys.  I think extensions are
> possible for discrete log keys, but the paper doesn't cover that.
>
> For the recipient-verifiable signature, Alice would create one of these
> multiple-signer signatures based on exactly two keys, Bob's and hers.
> Anyone can verify that the resulting message has been signed by Alice or
> Bob, but there is no way to tell which.  Alice then sends the message
> to Bob.  He knows that he didn't sign it, so it must have been Alice.
> But if he shows it to someone else, all they can see is that either
> Bob or Alice signed it, so Bob could have created a signature like this
> for any message he wanted.  Again there is no way for Bob to show the
> message convincingly to a third party, and Alice is protected.
...
> Unfortunately I think that adding a new flavor of signature would tend
> to create confusion among users who at best barely understand public
> key cryptography.  The new kind of signature would have very different
> security properties and usage scenarios, so it would add additional
> complexity for people to deal with.
...

no new signature type is needed.
this can be done now with a split key setup, for either an RSA or DH key:

Alice or Bob produces a new key  'Alice&Bob'

the share is set for 1, and the 'Alice&Bob' key is split with a share to
Alice's key, and a share to Bob's key,

either Alice or Bob can now sign with the 'Alice&Bob' key, without anyone
being able to detect whether it was Alice or Bob,
and  it will verify as a good signature from the 'Alice&Bob' key.

the 'Alice&Bob' split key can be imported into gnupg and the signatures
verified,
but gnupg cannot (yet) rejoin, sign or decrypt with a split shared system


if this is worthwhile/necessary, perhaps it could be considered for
addition
to the gnupg system.


hth,
vedaal






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BKuhN21961 for ietf-openpgp-bks; Thu, 11 Apr 2002 13:56:43 -0700 (PDT)
Received: from hotmail.com (oe17.law3.hotmail.com [209.185.240.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BKugm21954 for <[e-mail]>; Thu, 11 Apr 2002 13:56:42 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Apr 2002 13:45:32 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Date: Thu, 11 Apr 2002 16:43:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 11 Apr 2002 20:45:32.0196 (UTC) FILETIME=[D28FA640:01C1E199]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

----- Original Message -----
From: "Hal Finney" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, April 11, 2002 11:45 AM
Subject: Recipient-verifiable messages, was: forwarding an encrypted PGP
message is useless
...

> I proposed a different method, which basic idea is expressed in a paper
> by Rivest, Shamir and Tauman, "How to Leak a Secret", available from
> http://theory.lcs.mit.edu:80/~rivest/publications.html.  This paper shows
> how to produce a signature which can be verified to be from a specific
> list of keys, but you can't tell which key on the list made the signature.
> It is very simple and efficient for RSA keys.  I think extensions are
> possible for discrete log keys, but the paper doesn't cover that.
>
> For the recipient-verifiable signature, Alice would create one of these
> multiple-signer signatures based on exactly two keys, Bob's and hers.
> Anyone can verify that the resulting message has been signed by Alice or
> Bob, but there is no way to tell which.  Alice then sends the message
> to Bob.  He knows that he didn't sign it, so it must have been Alice.
> But if he shows it to someone else, all they can see is that either
> Bob or Alice signed it, so Bob could have created a signature like this
> for any message he wanted.  Again there is no way for Bob to show the
> message convincingly to a third party, and Alice is protected.
...
> Unfortunately I think that adding a new flavor of signature would tend
> to create confusion among users who at best barely understand public
> key cryptography.  The new kind of signature would have very different
> security properties and usage scenarios, so it would add additional
> complexity for people to deal with.
...

no new signature type is needed.
this can be done now with a split key setup, for either an RSA or DH key:

Alice or Bob produces a new key  'Alice&Bob'

the share is set for 1, and the 'Alice&Bob' key is split with a share to
Alice's key, and a share to Bob's key,

either Alice or Bob can now sign with the 'Alice&Bob' key, without anyone
being able to detect whether it was Alice or Bob,
and  it will verify as a good signature from the 'Alice&Bob' key.

the 'Alice&Bob' split key can be imported into gnupg and the signatures
verified,
but gnupg cannot (yet) rejoin, sign or decrypt with a split shared system


if this is worthwhile/necessary, perhaps it could be considered for addition
to the gnupg system.


hth,
vedaal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BFsm205586 for ietf-openpgp-bks; Thu, 11 Apr 2002 08:54:48 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BFslm05579 for <[e-mail]>; Thu, 11 Apr 2002 08:54:47 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g3BFjdw11622 for [e-mail]; Thu, 11 Apr 2002 08:45:39 -0700
Date: Thu, 11 Apr 2002 08:45:39 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

[Redirected to just OpenPGP list.  I guess this was a Mozilla bug
discussion that someone copied here?]

Sam Roberts <[e-mail]> writes:
> S/MIME only uses the signed and enveloped types from CMS, but RFC2630
> specifies authenticated as well. Its not well described there, but it is a
> way of "signing" something using a key agreement algorithm, such that the
> signature can ONLY be verified by using the sender or the receiver's
> private key.

I haven't read this RFC, but I had a long discussion with Wei Dai last
year about ways to do this within the OpenPGP framework.  We came up with
a couple of ideas.  These might be called "recipient-verifiable" signed
messages, to distinguish them from the regular PGP signed messages which
are "world-verifiable".  The general approach is to make the message such
that the recipient could "forge" fake messages from the sender that look
legitimate to third parties.  This prevents the real message from being
shown around in a convincing way.

Wei suggested that the recipient-verifiable message from Alice to Bob
could be as follows:

Sign_Alice( Encrypt_Bob( K ) ), MAC_K( Msg ), Msg.

The idea is that Alice chooses a MAC key K, encrypts it to Bob and then
signs the encrypted packet.  She sends this, along with the MAC'd message,
to Bob.  Bob can recover K from the encrypted packet, verifying the
signature by Alice on that packet, and then verify the MAC.

But if Bob shows this to someone else, although he may be able to convince
them that K was signed by Alice, he can't show that Msg is what she sent.
Given K, Bob could have MAC'd any message with that K and replaced Msg
with that.  So there is no evidence that Msg is what Alice actually
signed, hence she is not bound by it.

A subtlety is that if you did Encrypt_Bob( Sign_Alice( K ) ) instead,
this would let Bob remove his encryption envelope and then re-encrypt
for someone else, making them think that Alice had directed the message
to them and letting them verify the signature.  So the reverse ordering
is important.

I proposed a different method, which basic idea is expressed in a paper
by Rivest, Shamir and Tauman, "How to Leak a Secret", available from
http://theory.lcs.mit.edu:80/~rivest/publications.html.  This paper shows
how to produce a signature which can be verified to be from a specific
list of keys, but you can't tell which key on the list made the signature.
It is very simple and efficient for RSA keys.  I think extensions are
possible for discrete log keys, but the paper doesn't cover that.

For the recipient-verifiable signature, Alice would create one of these
multiple-signer signatures based on exactly two keys, Bob's and hers.
Anyone can verify that the resulting message has been signed by Alice or
Bob, but there is no way to tell which.  Alice then sends the message
to Bob.  He knows that he didn't sign it, so it must have been Alice.
But if he shows it to someone else, all they can see is that either
Bob or Alice signed it, so Bob could have created a signature like this
for any message he wanted.  Again there is no way for Bob to show the
message convincingly to a third party, and Alice is protected.

David Chaum has a patent on a variation on this idea, and he gave a talk
at PGP several years ago in which he advocated that recipient-verifiable
signatures are very useful, and in fact ought to be the default for
an email encryption system like PGP.  As others in this thread have
commented, often you don't want to sign something such that you can
be bound by it later, but you do want to assure the recipient that the
message is authentic.  Only rarely do you want to make a signature that
anyone can read.

Unfortunately I think that adding a new flavor of signature would tend
to create confusion among users who at best barely understand public
key cryptography.  The new kind of signature would have very different
security properties and usage scenarios, so it would add additional
complexity for people to deal with.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g3B6Nko15707 for ietf-openpgp-bks; Wed, 10 Apr 2002 23:23:46 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3B6Ngm15681; Wed, 10 Apr 2002 23:23:43 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3B6NaXv017048; Thu, 11 Apr 2002 18:23:36 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA409290; Thu, 11 Apr 2002 18:23:34 +1200 (NZST) (sender [e-mail])
Date: Thu, 11 Apr 2002 18:23:34 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Sam Roberts <[e-mail]> writes:

>S/MIME only uses the signed and enveloped types from CMS, but RFC2630
>specifies authenticated as well. Its not well described there, but it is a
>way of "signing" something using a key agreement algorithm, such that the
>signature can ONLY be verified by using the sender or the receiver's
>private key.

Hmm, are you sure you're not interpreting a bit too much into this
data type?  The intent is to allow MAC'ing of data, and to do that you
need to share a key with the other side, which is why you need a key
exchange to precede it.  One of those happens to be X9.42.  There are
two issues with this:

1. The only implementation which is known to support X9.42 in any
   useful manner is the SFL.
2. There don't seem to be any implementations which support
   authenticatedData, or at least that was the case when I asked on 
   the S/MIME list a while back for someone to do some interop testing 
   with.

(Oh, and the obvious third point: If you're doing a PKC operation for
 the key exchange anyway, you may as well just sign the thing directly.
 At best, you can claim that this gives you a signature capability
 using an encryption-only key).

I've always seen the only real use for this data type as password-
based integrity protection for data you're carrying around, using in
conjunction with passwordRecipientInfo.

>What this gives you is repudiation. If I authenticate something to
>you, you know I authenticated it. But if you forward it somebody
>else, they can't verify the signature, they have no way of knowing
>for sure that I authenticated it, and I can deny it. Even if the
>recipients private key is compromised, they still can't prove
>that *I* authenticated it, since either one of us can create the
>"signature", all they know is one of us made the authenticated data.

Well, only if you use some of the obscure X9.42 options which don't
identify sender and receiver.  The default is to list both, although
there are a pile of optional parameters and with only one known
implementation who knows what will happen in real life.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g3B6Ei814141 for ietf-openpgp-bks; Wed, 10 Apr 2002 23:14:44 -0700 (PDT)
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3B6ENm14038; Wed, 10 Apr 2002 23:14:23 -0700 (PDT)
Received: from fwd04.sul.t-online.de  by mailout07.sul.t-online.com with smtp  id 16vXfO-0004FD-07; Thu, 11 Apr 2002 08:02:42 +0200
Received: from webclient (510028335386-0001@[217.84.21.219]) by fmrl04.sul.t-online.com with esmtp id 16vXfH-28b9BQC; Thu, 11 Apr 2002 08:02:35 +0200
Content-Type: text/plain; charset="iso-8859-15"
From: Volker Augustin <[e-mail]>
To: [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Thu, 11 Apr 2002 06:58:04 +0200
X-Mailer: KMail [version 1.4.5]
Cc: [e-mail], [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <[e-mail]>
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Am Thursday 11 April 2002 03:34:03 schrieb Keith Moore 
> > But - for me - replying should only go back to the original sender and
> > not to someone else.
>
> I don't think you'll find much widespread support for that view.
> There are too many real world cases where you want to change the
> set of recipients to whom a reply is sent.

Of course not. The point was only that the name of an action describes
a "general" action contract, i.e. in case of the "Reply To" you expect
that you can reply to a message. You would be badly shaken if you 
could only reply to the sender.
The same should be true for forwarding. The general action contract is
to forward something you received to someone else. It should be up to
the person who is forwarding to decide whether to forward the whole
message or only parts of it.

Volker Augustin


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3B2xs505631 for ietf-openpgp-bks; Wed, 10 Apr 2002 19:59:54 -0700 (PDT)
Received: from tomts11-srv.bellnexxia.net (tomts11.bellnexxia.net [209.226.175.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3B2xdm05618; Wed, 10 Apr 2002 19:59:39 -0700 (PDT)
Received: from localhost ([64.229.86.40]) by tomts11-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020411025942.CYEQ10141.tomts11-srv.bellnexxia.net@localhost>; Wed, 10 Apr 2002 22:59:42 -0400
Received: (nullmailer pid 453824565 invoked by uid 100); Thu, 11 Apr 2002 02:59:01 -0000
Date: Wed, 10 Apr 2002 22:59:01 -0400
From: Sam Roberts <[e-mail]>
To: [e-mail]
Cc: Paul Shields <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Message-ID: <20020410225900.B442736687@localhost>
Mail-Followup-To: [e-mail], Paul Shields <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.16i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Apr 10, 2002 at 06:06:51PM +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

There actually is a cryptographically sound technique that helps
here, I was talking about it with a cryptographer at work last
week while reading RFC 2630, and not getting the difference
between authenticated and signed data.

S/MIME only uses the signed and enveloped types from CMS, but RFC2630
specifies authenticated as well. Its not well described there, but it is a
way of "signing" something using a key agreement algorithm, such that the
signature can ONLY be verified by using the sender or the receiver's
private key.

Now, since the receiver knows he didn't authenticate it, he knows the
sender must have.

What this gives you is repudiation. If I authenticate something to
you, you know I authenticated it. But if you forward it somebody
else, they can't verify the signature, they have no way of knowing
for sure that I authenticated it, and I can deny it. Even if the
recipients private key is compromised, they still can't prove
that *I* authenticated it, since either one of us can create the
"signature", all they know is one of us made the authenticated data.

I hope my explanation was clear, its easier on a white board!

This CMS authenticated data is only possible with key agreement
algorithms, i.e., you can't do it with RSA. I could be wrong
about it not being a defined payload for S/MIME, but I don't
think so. Too bad. It also has a very odd "feature" or "bug" when you
authenticate the same content to multiple receivers in the CMS message.
I'll explain if anybody is interested.

Sam

Quoteing [e-mail], on Wed, Apr 10, 2002 at 06:06:51PM +0200:
> On 2002-04-10 10:46:26 -0400, Paul Shields wrote:
> 
> >Should we have a selectable option on sign-encrypt that specifies 
> >that the signature must be removed from the plaintext after 
> >verifying it?
> 
> What, precisely, prevents the recipient's implementation from 
> ignoring that flag?
> 
> In the suggestions circulated in this thread, some folks are making 
> the same basic design error all over the place: You want to place 
> trust in software which is under the complete control of an 
> individual you don't trust.  Don't do it.  It's impossible.
> 
> The features which are being suggested _may_ help against 
> unintentional errors the recipient may make (like, storing, by 
> accident, the wrong love letters on the wrong hard drive, which [I 
> seem to recall] was the original reasoning behind the "for your eyes 
> only" [or whatever it was called] function of pgp 2).
> 
> They don't, however, help against malicious behavior on the 
> recipient's side.
> 
> -- 
> Thomas Roessler                        <[e-mail]>

-- 
Sam Roberts <[e-mail]> (Vivez sans temps mort!)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3B1YWw03755 for ietf-openpgp-bks; Wed, 10 Apr 2002 18:34:32 -0700 (PDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3B1YUm03751; Wed, 10 Apr 2002 18:34:30 -0700 (PDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3B1YTZ03240; Wed, 10 Apr 2002 21:34:29 -0400 (EDT)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Volker Augustin <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless 
In-reply-to: (Your message of "Wed, 10 Apr 2002 21:56:52 +0200.")  <[e-mail]> 
Date: Wed, 10 Apr 2002 21:34:28 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> But - for me - replying should only go back to the original sender and not
> to someone else. 

I don't think you'll find much widespread support for that view.
There are too many real world cases where you want to change the
set of recipients to whom a reply is sent.


Received: by above.proper.com (8.11.6/8.11.3) id g3AL8gn23268 for ietf-openpgp-bks; Wed, 10 Apr 2002 14:08:42 -0700 (PDT)
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AL8Rm23251; Wed, 10 Apr 2002 14:08:27 -0700 (PDT)
Received: from fwd11.sul.t-online.de  by mailout01.sul.t-online.com with smtp  id 16vPDd-0007SL-0B; Wed, 10 Apr 2002 23:01:29 +0200
Received: from webclient (510028335386-0001@[217.229.169.32]) by fmrl11.sul.t-online.com with esmtp id 16vPDU-0BKIuOC; Wed, 10 Apr 2002 23:01:20 +0200
Content-Type: text/plain; charset="iso-8859-1"
From: Volker Augustin <[e-mail]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 21:56:52 +0200
X-Mailer: KMail [version 1.4.5]
To: [e-mail]
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <[e-mail]>
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> Why I am sceptic about allowing forwarding formerly encrypted mails
> unencryptedly or after re-encryption is that - for me - forwarding
> shouldn't change the original message.

As we already saw different people associate different actions with
 "forward".

> If you want to change the message, reply to it and edit the recipients.

But - for me - replying should only go back to the original sender and not
to someone else. So, from my point of view you should not even be able
to change the recipient field after selecting the reply action. Different
people, different views again.

> If you forward, you actually want to annotate the original message with
> a few lines of notes, then send the stuff on the the recipient, much like
> sticking these yellow post-it strips to a folder and write "you do that!"
> on them before telling the secretary to carry it to the next room.

Actually, in your interpretation you would stick the folder in a box with a
padlock for which you know that the recipient does not have a key, then
tell the secretary to carry it to the next room.

IMO there need to be two different forward actions. Actually we already have
them: Forward and Forward as Attachment. Their interpretation should be
applied only to the content and not the envelope. The encryption is the en-
velope here, but the signature belongs to the content.
Of course you could name them "Forward annotated" and "Forward" instead.

Volker



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AJsH819320 for ietf-openpgp-bks; Wed, 10 Apr 2002 12:54:17 -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 g3AJsGm19313 for <[e-mail]>; Wed, 10 Apr 2002 12:54:16 -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 g3AJsQg15412 for <[e-mail]>; Wed, 10 Apr 2002 15:54:26 -0400 (EDT)
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: [e-mail]
From: [e-mail]
Date: Wed, 10 Apr 2002 14:54:17 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/10/2002 03:54:12 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

Here's another way to make sure that someone doesn't strip away the
encryption envelope but leave the signature and forward the signed
document:  By analogy with the "Dear Sue" content to prevent authenticated
message re-use, you can do this on the application level.

Include in the signed text a statement that the intended recipient still
wants to keep secret.  now he will have to excerpt the main message of
interest (and lose your signature) or act against his own interest, which
may be different from the interest context of the main message.

--John



Received: by above.proper.com (8.11.6/8.11.3) id g3AJEYn15299 for ietf-openpgp-bks; Wed, 10 Apr 2002 12:14:34 -0700 (PDT)
Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3AJEVm15290 for <[e-mail]>; Wed, 10 Apr 2002 12:14:31 -0700 (PDT)
Received: (cpmta 15184 invoked from network); 10 Apr 2002 12:14:22 -0700
Received: from 217.82.85.10 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.72) with SMTP; 10 Apr 2002 12:14:22 -0700
X-Sent: 10 Apr 2002 19:14:22 GMT
Content-Type: text/plain; charset="us-ascii"
From: Marc Mutz <[e-mail]>
Organization: KDE
To: Marcel Waldvogel <[e-mail]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 21:12:39 +0200
User-Agent: KMail/1.4.5
Cc: [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3AJEVm15292
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 10 April 2002 20:39, Marcel Waldvogel wrote:
<snip>
> I like bringing up the secretary/post-it metaphor. But assume the letter
> was encrypted, or, in "real-world terms", written in Suaheli, a language
> which nobody else in your office speaks. Putting a "you do that!"
> post-it on the letter won't be useful to your secretary,
<snip>

You don't know my boss. He recently forwarded me a Windows Virus infected mail 
because he couldn't print the attachment (a audio/x-wav labelled .doc.pif 
file). Thank God he works under Linux ;-)

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8tI6o3oWD+L2/6DgRAilsAJ0ZtnjNIwBOWy+tOsrdN/Px8aYthQCgl196
+Dmz7BVnC1/dwgseUWxXdyg=
=tomX
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AICUR12636 for ietf-openpgp-bks; Wed, 10 Apr 2002 11:12:30 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AICTm12631 for <[e-mail]>; Wed, 10 Apr 2002 11:12:29 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g3AICPN02482 for [e-mail]; Wed, 10 Apr 2002 14:12:25 -0400
Date: Wed, 10 Apr 2002 14:12:25 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: forwarding an encrypted message
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waning Crescent (4% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, Apr 10, 2002 at 11:01:47AM -0500, [e-mail] wrote:

> What is the "throw-keyid" switch?

"throw-keyid" is what GnuPG calls using the wildcard or speculative
keyid.  Basically it means that a sender can specify the recepient key
id as zero, which tells the receiving program to try all possible
secret keys.  It helps resist traffic analysis as a snooper cannot
easily tell who the message is intended for.  See RFC2440, section 5.1
for more details.  I don't see how this would help with the message
forwarding problem being discussed though.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AHq4410696 for ietf-openpgp-bks; Wed, 10 Apr 2002 10:52:04 -0700 (PDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AHq3m10688; Wed, 10 Apr 2002 10:52:03 -0700 (PDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3AHq0Z01617; Wed, 10 Apr 2002 13:52:00 -0400 (EDT)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Marc Mutz <[e-mail]>
cc: [e-mail], Keith Moore <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless 
In-reply-to: (Your message of "Wed, 10 Apr 2002 19:33:17 +0200.")  <[e-mail]> 
Date: Wed, 10 Apr 2002 13:52:00 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> Why I am sceptic about allowing forwarding formerly encrypted mails
> unencryptedly or after re-encryption is that - for me - forwarding shouldn't
> change the original message. 

I agree with this much.  A UA that claims to be forwarding a message shouldn't
misrepresent the message's content.  If the subject message is encrypted, the 
corresponding content of the forwarded message should also be encrypted.
It would be fair for the UA to refuse to forward such a message to someone  
who wasn't a recipient - or at least to warn the forwarder that the recipient
probably won't be able to read it.

OTOH if only part of the message is forwarded, say the body or an attachment,
the original encryption has to be removed anyway.  

It seems like the issue here is really one of how the forwarded message is
represented to the ultimate recipient - does it look just like any other
forwarded message, or can the recipient tell that it's been altered?

Have we ever defined exactly what a forwarded message should look like anyway?

Keith


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AHgfV09347 for ietf-openpgp-bks; Wed, 10 Apr 2002 10:42:41 -0700 (PDT)
Received: from hotmail.com (oe19.law3.hotmail.com [209.185.240.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AHgdm09343 for <[e-mail]>; Wed, 10 Apr 2002 10:42:39 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Apr 2002 10:42:36 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: forwarding an encrypted message
Date: Wed, 10 Apr 2002 13:40:50 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 10 Apr 2002 17:42:36.0940 (UTC) FILETIME=[1A62BCC0:01C1E0B7]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

- ----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, April 10, 2002 12:01 PM
Subject: re: forwarding an encrypted message
...

> What is the "throw-keyid" switch?
...

the throw-keyid switch is an option in GnuPG, and also in Disastry's
2.6.31a-multi 5, {but not available in any other PGP implementation}

the throw-keyid option allows for replacing the key id that a message was
encrypted to, with a 'blank' one, {indicating that
the sender wishes the recipients (and the sender as well, if also encrypted
to self by default) to remain anonymous.

the recipient must try 'all secret keys' , and if the appropriate secret
key is on the recipient's keyring, the message will decrypt
upon entry of the correct passphrase.
there is no other indication of which key or keys the message was encrypted
to, and the default encryption to the sender's 
key is also not detectable, even after successful decryption by the
recipient.

there is 'sort of' a way to prevent a signed message from being forwarded,
without changing any requirements, and without
any ways around it:

[1] encrypt, but do not sign,  the original message, 
[2] then, sign and encrypt the first encrypted message

the recipient verifies the signature, and knows that the  unsigned
encrypted message was sent by the reciever and intended
for the recipient.

nothing can prevent the recipient from forwarding the 'content' of the
message,
but unless the recipient wants to decrypt in front of witnesses, there is
no other way to link the plaintext to the sender's signature.

all the best,
vedaal

-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt   build 7      http://www.ipgpp.com/
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  D9AE 02FD A711 97BA

iQEVAwUBPLR5H2oFoLeFMG0lAQNohQf+MXdDsb0DxxnIO9NhB5BDZJ/uuTYdmmjY
gZoK0L5R+iPVQzChlLsbEr9xLlhP5at8KcRKu3soEFNdEQqdJ60yfB7hzJg82utX
dTMsxZWvidqvZcVZn9IQJmqANszKg060zEMXLYMTcu+D3imHSjOEyxv1XnaJZji7
metCyVf04Nyl2LU7tJsgSJXlYnkYR10m4uYv9EPtu+uzf8vsUMzS9+1BAryLYvmc
NOqn/bhA3eM7scf5u7HRL6hPa8zT9zUU2GWAk55Lf0qaR3kDG0DxShEmLnLc/Wg5
Ls03q40W12YXz8Smvo2exUa97VEgSwCjY4M2wIeUHJNg50jbv26nfw==
=Ld9Q
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AHZ7q08935 for ietf-openpgp-bks; Wed, 10 Apr 2002 10:35:07 -0700 (PDT)
Received: from c000.snv.cp.net (h001.c000.snv.cp.net [209.228.32.65]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3AHZ5m08927 for <[e-mail]>; Wed, 10 Apr 2002 10:35:05 -0700 (PDT)
Received: (cpmta 15431 invoked from network); 10 Apr 2002 10:35:00 -0700
Received: from 217.82.85.10 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.65) with SMTP; 10 Apr 2002 10:35:00 -0700
X-Sent: 10 Apr 2002 17:35:00 GMT
Content-Type: text/plain; charset="us-ascii"
From: Marc Mutz <[e-mail]>
Organization: KDE
To: [e-mail], Keith Moore <[e-mail]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 19:33:17 +0200
User-Agent: KMail/1.4.5
Cc: [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3AHZ5m08929
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 10 April 2002 18:10, [e-mail] wrote:
<snip>
> > Nor is it clear that this is a "problem".    At least, there appear to be
> > more "problems" associated with mechanisms that do purport to control
> > what a recipient can do with a message than mechanisms that merely
> > provide protection against interception of a message in transit from
> > sender to recipient.
>
> Exactly. This entire problem space has a character similar to that of copy
> protection, digital rights management and all that. There are also lessons
> to be learned from the Multics work on environments that try to support
> multiple levels of secrecy and integrity simultaneously. (Some of the
> stories told by the folks who worked on things like text editors for mixed
> level data are particularly amusing.)
<snip>
> You can't win. And given how much this pisses off users, making them even
> less receptive to following whatever rules they're supposed to be
> following, you shouldn't even try.
<snip>

Actually, we already knew this ;-)
Both camps here agree that you can't stop the receiver from sending the 
formerly encrypted message wherever she wants - in the clear.

Why I am sceptic about allowing forwarding formerly encrypted mails 
unencryptedly or after re-encryption is that - for me - forwarding shouldn't 
change the original message. If you want to change the message, reply to it 
and edit the recipients. If you forward, you actually want to annotate the 
original message with a few lines of notes, then send the stuff on the the 
recipient, much like sticking these yellow post-it strips to a folder and 
write "you do that!" on them before telling the secretary to carry it to the 
next room.

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8tHdd3oWD+L2/6DgRAtKjAKC+04nF2zJwBSj2KA8Z/PJQ/OcDvQCeN2tV
VjBmr0dJLgL8881VBD8zHTM=
=MSCU
-----END PGP SIGNATURE-----



Received: by above.proper.com (8.11.6/8.11.3) id g3AHGWi08133 for ietf-openpgp-bks; Wed, 10 Apr 2002 10:16:32 -0700 (PDT)
Received: from mail.passportnewmedia.ca (66-163-2-247.mail.passportnewmedia.ca [66.163.2.247] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AHGQm08097; Wed, 10 Apr 2002 10:16:26 -0700 (PDT)
Received: from passport.ca (66-163-2-225.ip.tor.radiant.net [66.163.2.225]) by mail.passportnewmedia.ca (Postfix) with ESMTP id 2EF6D14F8A2; Wed, 10 Apr 2002 13:12:00 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 13:16:28 -0400
From: Paul Shields <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek wants this to be enforced or not to have it at all.
Ned points out that users will be angry if you try to enforce it.

All I wanted was friendly handling instructions, a convenience
feature just like 'eyes-only'.  It won't try to prohibit
forwarding, it is simply a request that the receiver remove the
signature after decrypt+verify.

Yes, Derek will be able to get around it unless someone figures out
how to tie the signature to the encryption. Yes, it
won't be supported by some implementations. But does it make matters
worse than they are now?  Is it something that
has value ONLY if it is enforceable?

- --Paul.

Derek Atkins wrote:

  Paul Shields <[e-mail]> writes:

  > Should we have a selectable option on sign-encrypt that specifies
  > that the signature must be
  > removed from the plaintext after verifying it?

  How would you enforce this?  This is just like the
"for-her-eyes-only"
  flag on literal text.  It's a notation to keep the good guy honest,
  but wont protect you from someone who really wants to get around
it.

[e-mail] wrote:

  All of this stuff falls down at some point because you just can't
  compartmentalize people's brains. Prohibit forwarding of content
and people
  will save stuff to files and then mail the files. Prohibit saving
to files and
  people will cut and paste. Prohibit cut and paste and people will
type what one
  window says into another. Prohibit people from having mutiple
windows up at the
  same time for this purpose and they will write stuff down on paper
(which
  introduces its own set of problems). Prohibit writing stuff down
(good luck)
  and people will try and remember it, and then enter it incorrectly
later.

  You can't win. And given how much this pisses off users, making
them even less
  receptive to following whatever rules they're supposed to be
following, you
  shouldn't even try.

                                  Ned



-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPLRzWG+NxmuGaxjwEQKVdwCfZ0MkAxiNo2tRjvqUxjCBm6yzc1EAniLe
CrGXkZ/BefCMb+RJNnvnzJj4
=w1lH
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id g3AGTwb06264 for ietf-openpgp-bks; Wed, 10 Apr 2002 09:29:58 -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 g3AGTnm06250 for <[e-mail]>; Wed, 10 Apr 2002 09:29:57 -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 g3AGTxg21352 for <[e-mail]>; Wed, 10 Apr 2002 12:29:59 -0400 (EDT)
Subject: Re: forwarding an encrypted message
To: [e-mail]
From: [e-mail]
Date: Wed, 10 Apr 2002 11:29:47 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/10/2002 12:29:46 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

I agree with the way this is going.  Tools are made to help us, to do our
bidding.  Guns are made with safety switches, not (usually) locks.  The
microwave oven shuts off if I open the door, as does the refridgerator
light, but I -could- use a piece of tape over the button to defeat that.
The tools are acting to help me, but don't go to heroic lengths to be
tamper-proof.

I may trust someone in the sense that he keeps my interests in mind, but
not trust him with technical things.  So having flags that are understood
by the tools, not =only= human messages to explain allowed dispositions, is
a good thing.





Ben Laurie <[e-mail]>@mail.imc.org on 04-10-2002 08:41:50 AM

Sent by:  [e-mail]


To:   Matthew Byng-Maddick <[e-mail]>
cc:   [e-mail]
Subject:  Re: forwarding an encrypted message



Matthew Byng-Maddick wrote:
> On Tue, Apr 09, 2002 at 04:26:55PM -0400, vedaal wrote:
> > both of which can be 'denied' by the original sender, and can be proved
by
> > the forwarder, only by having someone witness the decryption.
>
> I've never put very much faith in the screen eyes-only thing for that
> reason. What is the point? If you don't trust the person, don't send the
> document to them. Once they have it it's their choice who they forward
to,
> and it's now out of your control. Tough.

I believe the original explanation - that it was requested by someone
having an
affair, who didn't trust the recipient not to _accidentally_ save to disk
and
get them caught.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGOSZ06168 for ietf-openpgp-bks; Wed, 10 Apr 2002 09:24:28 -0700 (PDT)
Received: from mail.mediacompany.com (postfix@[195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGOOm06156; Wed, 10 Apr 2002 09:24:24 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [194.162.149.130]) by mail.mediacompany.com (Postfix) with ESMTP id 0FBBE4802; Wed, 10 Apr 2002 18:24:11 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id 62DAF2ED15; Wed, 10 Apr 2002 18:06:51 +0200 (CEST)
Date: Wed, 10 Apr 2002 18:06:51 +0200
From: Thomas Roessler <[e-mail]>
To: Paul Shields <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Message-ID: <[e-mail]>
Mail-Followup-To: Paul Shields <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2002-04-10 10:46:26 -0400, Paul Shields wrote:

>Should we have a selectable option on sign-encrypt that specifies 
>that the signature must be removed from the plaintext after 
>verifying it?

What, precisely, prevents the recipient's implementation from 
ignoring that flag?

In the suggestions circulated in this thread, some folks are making 
the same basic design error all over the place: You want to place 
trust in software which is under the complete control of an 
individual you don't trust.  Don't do it.  It's impossible.

The features which are being suggested _may_ help against 
unintentional errors the recipient may make (like, storing, by 
accident, the wrong love letters on the wrong hard drive, which [I 
seem to recall] was the original reasoning behind the "for your eyes 
only" [or whatever it was called] function of pgp 2).

They don't, however, help against malicious behavior on the 
recipient's side.

-- 
Thomas Roessler                        <[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGMBv06051 for ietf-openpgp-bks; Wed, 10 Apr 2002 09:22:11 -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 g3AGMAm06047 for <[e-mail]>; Wed, 10 Apr 2002 09:22:10 -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 g3AGMKg18882; Wed, 10 Apr 2002 12:22:20 -0400 (EDT)
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Wed, 10 Apr 2002 11:22:11 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/10/2002 12:22:06 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

>> I'm not quite that extreme, but I don't sign anything that I wouldn't
sign
if it were on paper, not on bits.

I'm a bit more mellow.  When talking to someone on the phone, you can
authenticate who you are talking to, from the voice.  In hand-written
letters, you can see the handwriting.  Electronic text has =no=
personalization to it, so the signature takes the place.


>> OpenPGP specifies that the signature goes inside the envelope. The
reason

I understand the reasons why encrypt-then-sign is better.  But I think it
could be even better yet.  Mathematically combining the two operations into
one, or, to reuse existing primitives, jump through hoops.  For example,
take a nonce and logically append both half its plaintext and ciphertext to
the original plaintext that will be signed.  Now, you can't verify the
signature without also being able to verify that the included nonce
decrypts, as well.

Hmm, a simpler way would be to use a keyed hash to make the digest, with
the key encrypted "to" the recipient.  Yea, I like that.  Let me further
refine... A subpacket contains the HMAC key and a block of random numbers
the same size as the hash (e.g. 160 bits), encrypted to the recipient.  The
recipient decrypts the key, repeats the hash, and then XOR's in the random
number.  The result is sent to the basic signature algorithm.  Now, if he
chooses to reveal the contents of this inner packet without providing the
means to decrypt it himself, then it's trivial to forge because you can
adjust the random number to make the hash match that of a tampered message.
Result, you can't verify the signature without being able to decode the
inner envelope.  The inner envelope is signed by itself, and would contain
a plain hash of the main message, to tie it together.









Jon Callas <[e-mail]> on 04-09-2002 04:27:04 PM

To:   [e-mail], [e-mail]
cc:   [e-mail], [e-mail], [e-mail]
Subject:  Re: Bug#40394: forwarding an encrypted PGP message is useless


At 3:33 PM -0500 4/9/02, [e-mail] wrote:

>But I think PGP uses "sign, then encrypt" which means software could
>decrypt but leave the signature intact.  As I recall, this was thought to
>be a non-problem with respect to re-targeting, because you can put the
>recipient's name in the message at the application level.  e.g. "Dear
Sue,"
>is part of the message, so it can't be mistaken as a message to Joan.  But
>that doesn't handle the issue of private information in the message.  It's
>possible for Sue to reveal the signed message to someone else, who can
>verify the signature, without needing Sue's key.  I would prefer if that
>were impossible--without Sue's key, the message can't be authenticated
>either.

OpenPGP specifies that the signature goes inside the envelope. The reason
for this is that if the signature is outside the envelope, then the
attacker knows both the source and destination of the message. In short, it
provides cryptographically enhanced traffic analysis.

Yes, you're right, someone can decrypt a signed message and then send on
the signed, decrypted message. They can also take a screenshot of the
screen and send the image on to someone else. I know many people who do not
sign messages for this very reason. We added a non-signature integrity
check to OpenPGP messages so you'd have some way of knowing you got the
message intact without requiring the sender to sign it.

There are security risks to signing messages. A good friend of mine is of
the opinion that you should never sign anything that you aren't willing to
forward on to City Hall for inclusion in the public record. He never signed
anyone ele's key for this reason, let alone a message. I'll add that this
guy was an VP at an investment bank, not a cypherpunk with outlaw
fantasies.

I'm not quite that extreme, but I don't sign anything that I wouldn't sign
if it were on paper, not on bits.

Mathematics cannot solve real-world security problems. If you're confessing
secrets to someone who gossips, you have security problems. If you send
signed, encrypted messages to someone who will decrypt them and send them
(or send a screenshot of your messagae) on, then you have the same security
problem.

A trusted channel to an untrustworthy person is not secure. And to
paraphrase Laotse, you cannot create trust with cryptography, no matter how
much cryptography you use.

     Jon







Received: by above.proper.com (8.11.6/8.11.3) id g3AGLgM06018 for ietf-openpgp-bks; Wed, 10 Apr 2002 09:21:42 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGLem06009 for <[e-mail]>; Wed, 10 Apr 2002 09:21:40 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 10 Apr 2002 09:21:38 -0700 (PDT)
Date: Wed, 10 Apr 2002 09:10:21 -0700 (PDT)
From: [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
In-reply-to: "Your message dated Wed, 10 Apr 2002 09:50:50 -0400" <[e-mail]>
To: Keith Moore <[e-mail]>
Cc: Marc Mutz <[e-mail]>, [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> > What if, in a mail user agent, the user wants to forward an encrypted message?
> > Allow it? Deny it?
> > Re-encrypt or remove encryption?
> > The problem is, of course, that the original sender might not like his
> > encrypted text being sent out in the clear again...

> I don't think this is something we can control.  If you encrypt something with
> a recipient's public key, you're implicitly giving the recipient the ability
> to decrypt that message and redistribute it to his heart's content.  You can
> issue instructions to the recipient about redistribution of the messgae, but
> you can't control whether the recipient follows those instructions.

> Nor is it clear that this is a "problem".    At least, there appear to be
> more "problems" associated with mechanisms that do purport to control what
> a recipient can do with a message than mechanisms that merely provide
> protection against interception of a message in transit from sender to
> recipient.

Exactly. This entire problem space has a character similar to that of copy
protection, digital rights management and all that. There are also lessons to
be learned from the Multics work on environments that try to support multiple
levels of secrecy and integrity simultaneously. (Some of the stories told by
the folks who worked on things like text editors for mixed level data are
particularly amusing.)

All of this stuff falls down at some point because you just can't
compartmentalize people's brains. Prohibit forwarding of content and people
will save stuff to files and then mail the files. Prohibit saving to files and
people will cut and paste. Prohibit cut and paste and people will type what one
window says into another. Prohibit people from having mutiple windows up at the
same time for this purpose and they will write stuff down on paper (which
introduces its own set of problems). Prohibit writing stuff down (good luck)
and people will try and remember it, and then enter it incorrectly later.

You can't win. And given how much this pisses off users, making them even less
receptive to following whatever rules they're supposed to be following, you
shouldn't even try.

				Ned



Received: by above.proper.com (8.11.6/8.11.3) id g3AG1sL04524 for ietf-openpgp-bks; Wed, 10 Apr 2002 09:01:54 -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 g3AG1nm04506 for <[e-mail]>; Wed, 10 Apr 2002 09:01:49 -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 g3AG1vg12971; Wed, 10 Apr 2002 12:01:57 -0400 (EDT)
Subject: re: forwarding an encrypted message
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Wed, 10 Apr 2002 11:01:47 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/10/2002 12:01:43 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What is the "throw-keyid" switch?

Not all implementations are compelled to support the "your eyes only"
flag.  Someone could run a Perl script on the saved message, for
example, even if he normally uses a GUI that works in the same manner
as NAI's.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPLRh0uOdgXmV1Gj8EQL2jgCgn5qhcvyftlU9NhaKkAk1vHMcWTwAoJeb
maLqCw1+ht6+o3XNODdHi/xf
=PIqI
-----END PGP SIGNATURE-----





"vedaal" <[e-mail]>@mail.imc.org on 04-09-2002 03:26:55 PM

Sent by:  [e-mail]


To:   <[e-mail]>
cc:
Subject:  re: forwarding an encrypted message



-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

- ----- Original Message -----
From: "Simon Josefsson" <[e-mail]>
To: "Marc Mutz" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, April 09, 2002 3:32 PM
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless


>
> Marc Mutz <[e-mail]> writes:
>
> > What if, in a mail user agent, the user wants to forward an encrypted
> > message? Allow it? Deny it?
> > Re-encrypt or remove encryption?
> >
> > The problem is, of course, that the original sender might not like his
> > encrypted text being sent out in the clear again...
>
> Then the original sender should not send the text to someone who will
> do that.
>
> I don't see how the standard could prevent the user from doing
> this. If it is prevented, then it is only the applications' doing, so
> it wouldn't be difficult to override it.
...
a way to do it, would be to send the original encrypted message using the
throw- keyid switch,

any re-sending of the message would not be able to identify the original
sender,

moreover, the message could also be sent using the option of 'screen
viewing only' so that the plaintext could not be saved,
except tediously by saving a screen shot, or re-typing the message,
both of which can be 'denied' by the original sender, and can be proved by
the forwarder, only by having someone witness the decryption.

hth,

vedaal

-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt   build 7      http://www.ipgpp.com/
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  D9AE 02FD A711 97BA

iQEVAwUBPLNNBGoFoLeFMG0lAQNFHgf+OmEDLzkChGzImWKeTK7Ma7sojVqGxUtJ
pGCtwK/SEjhxeiX0p+6ejFalP0FTN0xUNMhJ+P+oOW20BEUiSJEGiYOPDnrhThyq
nmg+jC2vgjEzGjdOo/CQ56XUh6ATQ1RRi2U5eahwftpzLQSPgSVrut9H4bmYT5OL
7Hk2MNQj5K1+9IwgjSrajs1DWv0Pbfx7ytrAAB2tnvx+KW6Qb5xQN8qMotbEI744
7q91c8VjMgu4w/L3TlkFigx1d4TJO/ZkFYclTgD43PbiYL3OcYE380MlYXxaD/rm
2JHdyD3jewyhkx+BAxiwaj/po7S45MVeoX5Ke8v7jF//eEBh8qCARQ==
=AT2F
-----END PGP SIGNATURE-----








Received: by above.proper.com (8.11.6/8.11.3) id g3AFq4502848 for ietf-openpgp-bks; Wed, 10 Apr 2002 08:52:04 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AFpfm02773; Wed, 10 Apr 2002 08:51:41 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA10568; Wed, 10 Apr 2002 11:51:42 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA19519; Wed, 10 Apr 2002 11:51:41 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08813; Wed, 10 Apr 2002 11:51:38 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA06184; Wed, 10 Apr 2002 11:51:38 -0400 (EDT)
To: Paul Shields <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
References: <[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 10 Apr 2002 11:51:38 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 25
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Paul Shields <[e-mail]> writes:

> Should we have a selectable option on sign-encrypt that specifies
> that the signature must be
> removed from the plaintext after verifying it?

How would you enforce this?  This is just like the "for-her-eyes-only"
flag on literal text.  It's a notation to keep the good guy honest,
but wont protect you from someone who really wants to get around it.

For example, many a time I've used 'pgp -fm input.asc >& output.txt'
to get around the for-her-eyes-only "bug".

The only way to really enforce this is to mathematically tie the
signature to the encryption.  This would require a whole new line of
mathematics (assuming you want to continue to hide the sender's
identity to non-recipients).

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AEkVX27782 for ietf-openpgp-bks; Wed, 10 Apr 2002 07:46:31 -0700 (PDT)
Received: from mail.passportnewmedia.ca (66-163-2-247.mail.passportnewmedia.ca [66.163.2.247] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AEkQm27770; Wed, 10 Apr 2002 07:46:26 -0700 (PDT)
Received: from passport.ca (66-163-2-225.ip.tor.radiant.net [66.163.2.225]) by mail.passportnewmedia.ca (Postfix) with ESMTP id DAB9A14F8A2; Wed, 10 Apr 2002 10:41:58 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 10:46:26 -0400
From: Paul Shields <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Without handling instructions that cause the signature to be removed,
someone forwarding the
message could cause trouble for the original sender.

I raised this as an issue a few years back on the PGP MIME list, but
the folks there were
unconvinced. It seems they wanted to be able to keep the signature
after decryption.

Should we have a selectable option on sign-encrypt that specifies
that the signature must be
removed from the plaintext after verifying it?

- --
Paul Shields


[e-mail] wrote:

  From: John Dlugosz

  IMO,

  If forwarding the decrypted plaintext also removed the signature,
there
  would be less trouble.  The content could be reputiated, since it
can't be
  distinguised from the forwarder just making it up.

  But I think PGP uses "sign, then encrypt" which means software
could
  decrypt but leave the signature intact.  As I recall, this was
thought to
  be a non-problem with respect to re-targeting, because you can put
the
  recipient's name in the message at the application level.  e.g.
"Dear Sue,"
  is part of the message, so it can't be mistaken as a message to
Joan.  But
  that doesn't handle the issue of private information in the
message.  It's
  possible for Sue to reveal the signed message to someone else, who
can
  verify the signature, without needing Sue's key.  I would prefer if
that
  were impossible--without Sue's key, the message can't be
authenticated
  either.



-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1

iQA/AwUBPLRQP2+NxmuGaxjwEQIumwCgzWVFUM0ZXZwcR9ghx1Y2co1sFEoAn1Xb
hK3bxFqmPwBbDQnny+QjBZHi
=SG0f
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id g3ADou525157 for ietf-openpgp-bks; Wed, 10 Apr 2002 06:50:56 -0700 (PDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ADosm25153; Wed, 10 Apr 2002 06:50:54 -0700 (PDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g3ADooZ05267; Wed, 10 Apr 2002 09:50:51 -0400 (EDT)
Message-Id: <[e-mail]>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Marc Mutz <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless 
In-reply-to: (Your message of "Tue, 09 Apr 2002 19:47:01 +0200.")  <[e-mail]> 
Date: Wed, 10 Apr 2002 09:50:50 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> What if, in a mail user agent, the user wants to forward an encrypted message?
> Allow it? Deny it?
> Re-encrypt or remove encryption?
> The problem is, of course, that the original sender might not like his
> encrypted text being sent out in the clear again...

I don't think this is something we can control.  If you encrypt something with
a recipient's public key, you're implicitly giving the recipient the ability
to decrypt that message and redistribute it to his heart's content.  You can
issue instructions to the recipient about redistribution of the messgae, but 
you can't control whether the recipient follows those instructions.

Nor is it clear that this is a "problem".    At least, there appear to be
more "problems" associated with mechanisms that do purport to control what
a recipient can do with a message than mechanisms that merely provide 
protection against interception of a message in transit from sender to
recipient.

Keith


Received: by above.proper.com (8.11.6/8.11.3) id g3ADfwJ24881 for ietf-openpgp-bks; Wed, 10 Apr 2002 06:41:58 -0700 (PDT)
Received: from scuzzy.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ADfvm24877 for <[e-mail]>; Wed, 10 Apr 2002 06:41:57 -0700 (PDT)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 29DCD2E9CB; Wed, 10 Apr 2002 13:41:48 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 14:41:50 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Byng-Maddick <[e-mail]>
Cc: [e-mail]
Subject: Re: forwarding an encrypted message
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Matthew Byng-Maddick wrote:
> On Tue, Apr 09, 2002 at 04:26:55PM -0400, vedaal wrote:
> > both of which can be 'denied' by the original sender, and can be proved by
> > the forwarder, only by having someone witness the decryption.
> 
> I've never put very much faith in the screen eyes-only thing for that
> reason. What is the point? If you don't trust the person, don't send the
> document to them. Once they have it it's their choice who they forward to,
> and it's now out of your control. Tough.

I believe the original explanation - that it was requested by someone having an
affair, who didn't trust the recipient not to _accidentally_ save to disk and
get them caught.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Received: by above.proper.com (8.11.6/8.11.3) id g3A9IUX07757 for ietf-openpgp-bks; Wed, 10 Apr 2002 02:18:30 -0700 (PDT)
Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A9ITm07749; Wed, 10 Apr 2002 02:18:29 -0700 (PDT)
Received: from GK-VAIO.ninebynine.org (dyn94-32.sftm-212-159.plus.net [212.159.32.94]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g3AGxi411487; Wed, 10 Apr 2002 09:59:44 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 10 Apr 2002 10:19:19 +0100
To: Jon Callas <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Cc: [e-mail], [e-mail]
In-Reply-To: <p05101507b8d906c4b9c4@[192.168.1.97]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 02:27 PM 4/9/02 -0700, Jon Callas wrote:
>A trusted channel to an untrustworthy person is not secure. And to
>paraphrase Laotse, you cannot create trust with cryptography, no matter how
>much cryptography you use.

Excellent!!

This is the first time I've been aware of a cryptosystems person make this 
point.

#g


-------------------
Graham Klyne
<[e-mail]>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3A8Xbc01729 for ietf-openpgp-bks; Wed, 10 Apr 2002 01:33:37 -0700 (PDT)
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A8Xam01720 for <[e-mail]>; Wed, 10 Apr 2002 01:33:36 -0700 (PDT)
Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 16vDXo-0008Pr-00 for [e-mail]; Wed, 10 Apr 2002 10:33:32 +0200
Received: from [217.81.186.207] (helo=there) by mrvdom00.kundenserver.de with smtp (Exim 2.12 #2) id 16vDXo-0007NL-00 for [e-mail]; Wed, 10 Apr 2002 10:33:32 +0200
Content-Type: text/plain; charset="iso-8859-15"
From: Magnus von Koeller <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 10:33:30 +0200
X-Mailer: KMail [version 1.3.2]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3A8Xam01723
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 09 April 2002 19:47, Marc Mutz wrote:
> Allow it? Deny it?
> Re-encrypt or remove encryption?
>
> The problem is, of course, that the original sender might not like
> his encrypted text being sent out in the clear again...

I'll just state my opinion on this matter because I want to give
Volker some support ...

I say: Allow forwarding. Remove encryption if you do inline
forwarding (forward as attachment shouldn't alter the source at all).
If possible, re-encrypt (i.e. the 'encrypt message' button should be
activated by default but you should be able to turn it off). You
should probably display a warning with a 'Dont show me again'
checkbox, too.

Reasoning: If KMail doesn't let you do this, then you can still just
copy&paste. So all you do is annoy the user. If the sender of an
encrypted email _really_ doesn't want you to forward that message to
others or doesn't want it forwarded in unencrypted form then he has
to tell you explicitely in his message. He'll have to do this anyway
because he can't assume that all mailers handle this the way KMail
does and because the user could still do copy&paste. It would be a
good idea to make the user aware of the implications, though, so
that's why I'm in favor of the warning message.

- --
- -M

- ---  Magnus von Koeller ---
email:    [e-mail]
address:  Georg-Westermann-Allee 76
          D-38104 Braunschweig / Germany
phone:    [phone]
mobile:   [phone]
web:      http://www.vonkoeller.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8s/jdUIvM6e6BgFARApOnAJ9+lKHHNfj9TMp3l+bgjz+OMwrsFgCcCeoI
Q7x/bi+trAm9ohTXAjHqxtg=
=HB/N
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3A86I027352 for ietf-openpgp-bks; Wed, 10 Apr 2002 01:06:18 -0700 (PDT)
Received: from colon.colondot.net ([e-mail] [212.135.138.209]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A86Hm27339 for <[e-mail]>; Wed, 10 Apr 2002 01:06:17 -0700 (PDT)
Received: from mbm by colon.colondot.net with local (Exim 3.33 #1) id 16vD7Q-000CYD-00 for [e-mail]; Wed, 10 Apr 2002 09:06:16 +0100
Date: Wed, 10 Apr 2002 09:06:16 +0100
From: Matthew Byng-Maddick <[e-mail]>
To: [e-mail]
Subject: Re: forwarding an encrypted message
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Apr 09, 2002 at 04:26:55PM -0400
Organization: Colondot.net
Mail-Copies-To: never
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Apr 09, 2002 at 04:26:55PM -0400, vedaal wrote:
> moreover, the message could also be sent using the option of 'screen
> viewing only' so that the plaintext could not be saved,
> except tediously by saving a screen shot, or re-typing the message,

or, less tediously, altering the source code to make that a noop.

> both of which can be 'denied' by the original sender, and can be proved by
> the forwarder, only by having someone witness the decryption.

I've never put very much faith in the screen eyes-only thing for that
reason. What is the point? If you don't trust the person, don't send the
document to them. Once they have it it's their choice who they forward to,
and it's now out of your control. Tough.

MBM

-- 
Matthew Byng-Maddick         <[e-mail]>           http://colondot.net/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39LU2b13861 for ietf-openpgp-bks; Tue, 9 Apr 2002 14:30:02 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39LTsm13831; Tue, 9 Apr 2002 14:29:54 -0700 (PDT)
Received: from [192.168.1.97] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.1); Tue, 9 Apr 2002 14:29:23 -0700
Mime-Version: 1.0
Message-Id: <p05101507b8d906c4b9c4@[192.168.1.97]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 9 Apr 2002 14:27:04 -0700
To: [e-mail], [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 3:33 PM -0500 4/9/02, [e-mail] wrote:

>But I think PGP uses "sign, then encrypt" which means software could
>decrypt but leave the signature intact.  As I recall, this was thought to
>be a non-problem with respect to re-targeting, because you can put the
>recipient's name in the message at the application level.  e.g. "Dear Sue,"
>is part of the message, so it can't be mistaken as a message to Joan.  But
>that doesn't handle the issue of private information in the message.  It's
>possible for Sue to reveal the signed message to someone else, who can
>verify the signature, without needing Sue's key.  I would prefer if that
>were impossible--without Sue's key, the message can't be authenticated
>either.

OpenPGP specifies that the signature goes inside the envelope. The reason
for this is that if the signature is outside the envelope, then the
attacker knows both the source and destination of the message. In short, it
provides cryptographically enhanced traffic analysis.

Yes, you're right, someone can decrypt a signed message and then send on
the signed, decrypted message. They can also take a screenshot of the
screen and send the image on to someone else. I know many people who do not
sign messages for this very reason. We added a non-signature integrity
check to OpenPGP messages so you'd have some way of knowing you got the
message intact without requiring the sender to sign it.

There are security risks to signing messages. A good friend of mine is of
the opinion that you should never sign anything that you aren't willing to
forward on to City Hall for inclusion in the public record. He never signed
anyone ele's key for this reason, let alone a message. I'll add that this
guy was an VP at an investment bank, not a cypherpunk with outlaw fantasies.

I'm not quite that extreme, but I don't sign anything that I wouldn't sign
if it were on paper, not on bits.

Mathematics cannot solve real-world security problems. If you're confessing
secrets to someone who gossips, you have security problems. If you send
signed, encrypted messages to someone who will decrypt them and send them
(or send a screenshot of your messagae) on, then you have the same security
problem.

A trusted channel to an untrustworthy person is not secure. And to
paraphrase Laotse, you cannot create trust with cryptography, no matter how
much cryptography you use.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id g39L8CN12938 for ietf-openpgp-bks; Tue, 9 Apr 2002 14:08:12 -0700 (PDT)
Received: from dfw.nationwide.net (dfw.nationwide.net [198.175.15.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39L8Bm12933; Tue, 9 Apr 2002 14:08:11 -0700 (PDT)
Received: from ppp-65-90-216-224.mclass.broadwing.net (ppp-65-90-216-224.mclass.broadwing.net [65.90.216.224]) by dfw.nationwide.net (8.9.3/8.9.3) with ESMTP id QAA03809; Tue, 9 Apr 2002 16:14:57 -0500 (CDT)
Date: Tue, 9 Apr 2002 16:08:03 -0500
From: "Clinton E. Troutman" <[e-mail]>
X-Mailer: The Bat! (v1.53bis) Personal
Reply-To: "Clinton E. Troutman" <[e-mail]>
Organization: CeTro
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Simon Josefsson <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re[2]: Bug#40394: forwarding an encrypted PGP message is useless
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --- Reply created Tuesday, 09 April 2002, 15:59:49 ---



- ------- Original Message --------
On Tuesday, 09 April 2002, 14:32, you wrote:

SJ> Then the original sender should not send the text to someone who
will
SJ> do that.

SJ> I don't see how the standard could prevent the user from doing
SJ> this. If it is prevented, then it is only the applications'
doing, so
SJ> it wouldn't be difficult to override it.  This isn't a technical
SJ> problem. Whenever you introduce encryption between two parties
you
SJ> have this issue.

SJ> Whether to re-encrypt or remove encryption is up to the user
SJ> forwarding the message.  What the defaults should be probably
depend
SJ> too much on the application to give any generic recomendation on.

SJ> Just my two cents.


- ------- End Original Message --------

Absolutely agreed.

Not a technical problem.

It is a problem of data released "to the wild" and what another party
may "do" with that data once released.

The allowable disposition of the data beyond the party of first
release should be specifically stated to prevent "missteps" by that
party.

And, if you are concerned that the data *not* be released beyond that
first party, perhaps you should consider either:
- - another method of release, or
- - your relationship with the party to whom you are releasing the
data,
or
- - don't release that data in the first place.

(Interesting how this seems to parallel the current debates on
copyright...)

- -----
Clinton E. Troutman
mailto:[e-mail]
- -----
"You can tell the Mafia is running the cockfight if the duck wins." -
Anon.
ÀFÿ\„
$%

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5i

iQA/AwUBPLNYPZlJBEe9GL9yEQJipQCgklKCtoYtpgpwKM7VZ1ynWP5IiecAoKY8
qPR93LgEEMtSRsma9VgWBwbr
=+Snr
-----END PGP SIGNATURE-----



Received: by above.proper.com (8.11.6/8.11.3) id g39KdnO11892 for ietf-openpgp-bks; Tue, 9 Apr 2002 13:39:49 -0700 (PDT)
Received: from hotmail.com (oe57.law3.hotmail.com [209.185.240.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Kdmm11887 for <[e-mail]>; Tue, 9 Apr 2002 13:39:48 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Apr 2002 13:28:35 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
Subject: re: forwarding an encrypted message
Date: Tue, 9 Apr 2002 16:26:55 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 09 Apr 2002 20:28:35.0398 (UTC) FILETIME=[1FAD1660:01C1E005]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

- ----- Original Message ----- 
From: "Simon Josefsson" <[e-mail]>
To: "Marc Mutz" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, April 09, 2002 3:32 PM
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless


> 
> Marc Mutz <[e-mail]> writes:
> 
> > What if, in a mail user agent, the user wants to forward an encrypted
> > message? Allow it? Deny it?
> > Re-encrypt or remove encryption?
> >
> > The problem is, of course, that the original sender might not like his
> > encrypted text being sent out in the clear again...
> 
> Then the original sender should not send the text to someone who will
> do that.
> 
> I don't see how the standard could prevent the user from doing
> this. If it is prevented, then it is only the applications' doing, so
> it wouldn't be difficult to override it.  
...
a way to do it, would be to send the original encrypted message using the
throw- keyid switch,

any re-sending of the message would not be able to identify the original
sender,

moreover, the message could also be sent using the option of 'screen
viewing only' so that the plaintext could not be saved,
except tediously by saving a screen shot, or re-typing the message,
both of which can be 'denied' by the original sender, and can be proved by
the forwarder, only by having someone witness the decryption.

hth,

vedaal

-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt   build 7      http://www.ipgpp.com/
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  D9AE 02FD A711 97BA

iQEVAwUBPLNNBGoFoLeFMG0lAQNFHgf+OmEDLzkChGzImWKeTK7Ma7sojVqGxUtJ
pGCtwK/SEjhxeiX0p+6ejFalP0FTN0xUNMhJ+P+oOW20BEUiSJEGiYOPDnrhThyq
nmg+jC2vgjEzGjdOo/CQ56XUh6ATQ1RRi2U5eahwftpzLQSPgSVrut9H4bmYT5OL
7Hk2MNQj5K1+9IwgjSrajs1DWv0Pbfx7ytrAAB2tnvx+KW6Qb5xQN8qMotbEI744
7q91c8VjMgu4w/L3TlkFigx1d4TJO/ZkFYclTgD43PbiYL3OcYE380MlYXxaD/rm
2JHdyD3jewyhkx+BAxiwaj/po7S45MVeoX5Ke8v7jF//eEBh8qCARQ==
=AT2F
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39KXVB11147 for ietf-openpgp-bks; Tue, 9 Apr 2002 13:33:31 -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 g39KXUm11140; Tue, 9 Apr 2002 13:33:30 -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 g39KXh910576; Tue, 9 Apr 2002 16:33:43 -0400 (EDT)
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
From: [e-mail]
Date: Tue, 9 Apr 2002 15:33:34 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/09/2002 04:33:29 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

IMO,

If forwarding the decrypted plaintext also removed the signature, there
would be less trouble.  The content could be reputiated, since it can't be
distinguised from the forwarder just making it up.

But I think PGP uses "sign, then encrypt" which means software could
decrypt but leave the signature intact.  As I recall, this was thought to
be a non-problem with respect to re-targeting, because you can put the
recipient's name in the message at the application level.  e.g. "Dear Sue,"
is part of the message, so it can't be mistaken as a message to Joan.  But
that doesn't handle the issue of private information in the message.  It's
possible for Sue to reveal the signed message to someone else, who can
verify the signature, without needing Sue's key.  I would prefer if that
were impossible--without Sue's key, the message can't be authenticated
either.





Marc Mutz <[e-mail]>@mail.imc.org on 04-09-2002 12:47:01 PM

Sent by:  [e-mail]


To:   [e-mail]
cc:   [e-mail], [e-mail]
Subject:  Re: Bug#40394: forwarding an encrypted PGP message is useless



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[ OK, I put this where it belongs: this touches OpenPGP and Internet
messages,
 so I'm forwarding this to the ietf lists ]

We have a problem and we think we are not alone with it (see the mozilla
link
below):

What if, in a mail user agent, the user wants to forward an encrypted
message?
Allow it? Deny it?
Re-encrypt or remove encryption?

The problem is, of course, that the original sender might not like his
encrypted text being sent out in the clear again...

Was this discussed here already? What was the consensus reached, if any?

Marc

On Tuesday 09 April 2002 13:01, Volker Augustin wrote:
> > Peronally, I think the best way is to ask the user
> > what to do when forwarding (inlined) an encrypted message. We cannot
> > prevent that he/she will forward the plaintext using a workaround. So
we
> > better delegate the resposibility for this action to the user itself.
> >
> > There is still the question, what should be the default way. Another
way
> > would to set the default to the last recently used way. Hm, I'm sure
> > you'll find a good solution.
>
> That might be a good solution. When trying for forward bring up a dialog
> asking whether to allow forwarding just this time or also for the future.
>
> I just did an intensive search via google. Here are some of my findings:
>
> 1. Some mail programs have an option to prevent forwarding of encrypted
>     messages. I could not find a single one explicitely preventing it.
> Some commercial application however give the system administrator the
> possibility to enforce this option system-wide.
>
> 2. RFC 1421 about PEM states (http://www.freesoft.org/CIE/RFC/1421/55.htm
)
>
>    "Some level of support for generating and processing nested and
> annotated PEM messages (for forwarding purposes) is to be provided, and
an
> implementation should be able to reduce ENCRYPTED messages to MIC-ONLY or
> MIC-CLEAR for forwarding."
>
> 3. There is an IETF draft about "Intended Recipients Attribute for the
>    Cryptographic Message Syntax (CMS)"
>    (http://www.ietf.org/internet-drafts/draft-ietf-smime-ira-00.txt)
saying
>
>     "The problem of intent that as expressed in [MALFWD] is beyond the
>     control of S/MIME protocol or its implementers.  The use of the
digital
>     signatures and encryption is correctly in the hands of the user.
> However, the intended recipients attribute offers a mechanism to reduce
the
> likelihood of undetected malicious forwarding."
>
> 4. The mozilla team has the same problem:
>     http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html
>
>     "open issues:
>     1) forwarding an encrypted message?
>     2) standards for content type S/MIME. PGP. GPG. OpenPGP.
>     3) Eudora and Outlook, etc. what do we need to do to support reading
> encrypted message from other clients? "
>
> Regards,
> Volker
> _______________________________________________
> KMail Developers mailing list
> [e-mail]
> http://mail.kde.org/mailman/listinfo/kmail

- --
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8sykV3oWD+L2/6DgRAqdGAJwNcRmGWoJScgyldtF8oRuZdkhJgwCgqSHS
EVIhVDaYSbaBNwblKUbAu9Q=
=Krt0
-----END PGP SIGNATURE-----







Received: by above.proper.com (8.11.6/8.11.3) id g39JX4c07882 for ietf-openpgp-bks; Tue, 9 Apr 2002 12:33:04 -0700 (PDT)
Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39JWvm07866; Tue, 9 Apr 2002 12:32:58 -0700 (PDT)
Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.2/8.12.2) with ESMTP id g39JWoKY017344; Tue, 9 Apr 2002 21:32:52 +0200
To: Marc Mutz <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]> (Marc Mutz's message of "Tue, 09 Apr 2002 19:47:01 +0200")
From: Simon Josefsson <[e-mail]>
Date: Tue, 09 Apr 2002 21:32:00 +0200
Message-ID: <[e-mail]>
Lines: 23
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Marc Mutz <[e-mail]> writes:

> What if, in a mail user agent, the user wants to forward an encrypted message?
> Allow it? Deny it?
> Re-encrypt or remove encryption?
>
> The problem is, of course, that the original sender might not like his 
> encrypted text being sent out in the clear again...

Then the original sender should not send the text to someone who will
do that.

I don't see how the standard could prevent the user from doing
this. If it is prevented, then it is only the applications' doing, so
it wouldn't be difficult to override it.  This isn't a technical
problem. Whenever you introduce encryption between two parties you
have this issue.

Whether to re-encrypt or remove encryption is up to the user
forwarding the message.  What the defaults should be probably depend
too much on the application to give any generic recomendation on.

Just my two cents.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39J8gX05646 for ietf-openpgp-bks; Tue, 9 Apr 2002 12:08:42 -0700 (PDT)
Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39J8em05642; Tue, 9 Apr 2002 12:08:40 -0700 (PDT)
Received: from pc5211wxptfm (cp92837-a.dbsch1.nb.nl.home.com [217.120.34.92]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with SMTP id g39J8UnT027337; Tue, 9 Apr 2002 21:08:35 +0200 (CEST)
From: "Leon Kuunders" <[e-mail]>
To: "Marc Mutz" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Bug#40394: forwarding an encrypted PGP message is useless
Date: Tue, 9 Apr 2002 21:08:28 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I don't know if this was discussed, but for me this is not a question of
encryption, but of trust. If you don't like someone else to forward your
messages, send them on paper. With a company logo, a watermark and a unique
number.

It is the risc of living :)

-Leon.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Marc Mutz
> Sent: 09 April 2002 19:47
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [ OK, I put this where it belongs: this touches OpenPGP and
> Internet messages,
>  so I'm forwarding this to the ietf lists ]
>
> We have a problem and we think we are not alone with it (see the
> mozilla link
> below):
>
> What if, in a mail user agent, the user wants to forward an
> encrypted message?
> Allow it? Deny it?
> Re-encrypt or remove encryption?
>
> The problem is, of course, that the original sender might not like his
> encrypted text being sent out in the clear again...
>
> Was this discussed here already? What was the consensus reached, if any?
>
> Marc
>
> On Tuesday 09 April 2002 13:01, Volker Augustin wrote:
> > > Peronally, I think the best way is to ask the user
> > > what to do when forwarding (inlined) an encrypted message. We cannot
> > > prevent that he/she will forward the plaintext using a
> workaround. So we
> > > better delegate the resposibility for this action to the user itself.
> > >
> > > There is still the question, what should be the default way.
> Another way
> > > would to set the default to the last recently used way. Hm, I'm sure
> > > you'll find a good solution.
> >
> > That might be a good solution. When trying for forward bring up a dialog
> > asking whether to allow forwarding just this time or also for
> the future.
> >
> > I just did an intensive search via google. Here are some of my findings:
> >
> > 1. Some mail programs have an option to prevent forwarding of encrypted
> >     messages. I could not find a single one explicitely preventing it.
> > Some commercial application however give the system administrator the
> > possibility to enforce this option system-wide.
> >
> > 2. RFC 1421 about PEM states
(http://www.freesoft.org/CIE/RFC/1421/55.htm)
>
>    "Some level of support for generating and processing nested and
> annotated PEM messages (for forwarding purposes) is to be provided, and an
> implementation should be able to reduce ENCRYPTED messages to MIC-ONLY or
> MIC-CLEAR for forwarding."
>
> 3. There is an IETF draft about "Intended Recipients Attribute for the
>    Cryptographic Message Syntax (CMS)"
>    (http://www.ietf.org/internet-drafts/draft-ietf-smime-ira-00.txt)
saying
>
>     "The problem of intent that as expressed in [MALFWD] is beyond the
>     control of S/MIME protocol or its implementers.  The use of the
digital
>     signatures and encryption is correctly in the hands of the user.
> However, the intended recipients attribute offers a mechanism to reduce
the
> likelihood of undetected malicious forwarding."
>
> 4. The mozilla team has the same problem:
>     http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html
>
>     "open issues:
>     1) forwarding an encrypted message?
>     2) standards for content type S/MIME. PGP. GPG. OpenPGP.
>     3) Eudora and Outlook, etc. what do we need to do to support reading
> encrypted message from other clients? "
>
> Regards,
> Volker
> _______________________________________________
> KMail Developers mailing list
> [e-mail]
> http://mail.kde.org/mailman/listinfo/kmail

- --
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8sykV3oWD+L2/6DgRAqdGAJwNcRmGWoJScgyldtF8oRuZdkhJgwCgqSHS
EVIhVDaYSbaBNwblKUbAu9Q=
=Krt0
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id g39IdfJ04937 for ietf-openpgp-bks; Tue, 9 Apr 2002 11:39:41 -0700 (PDT)
Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Iddm04933; Tue, 9 Apr 2002 11:39:39 -0700 (PDT)
Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g39IdtR01308; Tue, 9 Apr 2002 20:39:55 +0200
Date: Tue, 9 Apr 2002 20:39:55 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Marc Mutz <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Marc Mutz <[e-mail]>
> The problem is, of course, that the original sender might not like his 
> encrypted text being sent out in the clear again...

The original sender might not his text being sent out at all. He sent it
to you; you're showing it to some third party.

Personally, I suggest using as much encryption as reasonably possible. In
general, and naturally also in this particular case.

--Arnt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39IGtj03919 for ietf-openpgp-bks; Tue, 9 Apr 2002 11:16:55 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39IGom03908; Tue, 9 Apr 2002 11:16:50 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (ppp36-205.hrz.uni-bielefeld.de [129.70.36.205]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]>; Tue, 9 Apr 2002 20:16:50 +0200 (MET DST)
Date: Tue, 09 Apr 2002 19:47:01 +0200
From: Marc Mutz <[e-mail]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
In-reply-to: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[ OK, I put this where it belongs: this touches OpenPGP and Internet messages,
 so I'm forwarding this to the ietf lists ]

We have a problem and we think we are not alone with it (see the mozilla link 
below):

What if, in a mail user agent, the user wants to forward an encrypted message?
Allow it? Deny it?
Re-encrypt or remove encryption?

The problem is, of course, that the original sender might not like his 
encrypted text being sent out in the clear again...

Was this discussed here already? What was the consensus reached, if any?

Marc

On Tuesday 09 April 2002 13:01, Volker Augustin wrote:
> > Peronally, I think the best way is to ask the user
> > what to do when forwarding (inlined) an encrypted message. We cannot
> > prevent that he/she will forward the plaintext using a workaround. So we
> > better delegate the resposibility for this action to the user itself.
> >
> > There is still the question, what should be the default way. Another way
> > would to set the default to the last recently used way. Hm, I'm sure
> > you'll find a good solution.
>
> That might be a good solution. When trying for forward bring up a dialog
> asking whether to allow forwarding just this time or also for the future.
>
> I just did an intensive search via google. Here are some of my findings:
>
> 1. Some mail programs have an option to prevent forwarding of encrypted
>     messages. I could not find a single one explicitely preventing it. 
> Some commercial application however give the system administrator the
> possibility to enforce this option system-wide.
>
> 2. RFC 1421 about PEM states (http://www.freesoft.org/CIE/RFC/1421/55.htm)
>
>    "Some level of support for generating and processing nested and
> annotated PEM messages (for forwarding purposes) is to be provided, and an
> implementation should be able to reduce ENCRYPTED messages to MIC-ONLY or
> MIC-CLEAR for forwarding."
>
> 3. There is an IETF draft about "Intended Recipients Attribute for the
>    Cryptographic Message Syntax (CMS)"
>    (http://www.ietf.org/internet-drafts/draft-ietf-smime-ira-00.txt) saying
>
>     "The problem of intent that as expressed in [MALFWD] is beyond the
>     control of S/MIME protocol or its implementers.  The use of the digital
>     signatures and encryption is correctly in the hands of the user.
> However, the intended recipients attribute offers a mechanism to reduce the
> likelihood of undetected malicious forwarding."
>
> 4. The mozilla team has the same problem:
>     http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html
>
>     "open issues:
>     1) forwarding an encrypted message?
>     2) standards for content type S/MIME. PGP. GPG. OpenPGP.
>     3) Eudora and Outlook, etc. what do we need to do to support reading
> encrypted message from other clients? "
>
> Regards,
> Volker
> _______________________________________________
> KMail Developers mailing list
> [e-mail]
> http://mail.kde.org/mailman/listinfo/kmail

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8sykV3oWD+L2/6DgRAqdGAJwNcRmGWoJScgyldtF8oRuZdkhJgwCgqSHS
EVIhVDaYSbaBNwblKUbAu9Q=
=Krt0
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39F1Xb20911 for ietf-openpgp-bks; Tue, 9 Apr 2002 08:01:33 -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 g39F1Vm20901 for <[e-mail]>; Tue, 9 Apr 2002 08:01:32 -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 g39F1k906437 for <[e-mail]>; Tue, 9 Apr 2002 11:01:46 -0400 (EDT)
Subject: Re: OpenPGP public key packet format
To: [e-mail]
From: [e-mail]
Date: Tue, 9 Apr 2002 10:01:32 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/09/2002 11:01:31 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

========
For the subkeys, the key usage flags subpacket can go in the subkey
signature.  For the top level key, probably the best place is in the
self-signature on all the userids.  I think the commercial PGP versions
look specifically in the self-sig on the primary userid.
======

Thanks.

In the diagram in 11.1, what are the "Direct Key Self Signatures" that come
before the first User ID?

Note that the commercial PGP lets me change which ID is the "primary".  So
if it's looking there, it must be on all of them, and when adding another
ID it must be consistant with what's gone before.  I wonder, though, if
programs just assume that the main key is for signing, and the first
current subkey is for encrypting?  In the case of DSA and the deprecated
RSA-sign-only types, it is clear that the main key can only be used for
signing, without the need for such a record.



Received: by above.proper.com (8.11.6/8.11.3) id g38LFP908144 for ietf-openpgp-bks; Mon, 8 Apr 2002 14:15:25 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38LFOm08140 for <[e-mail]>; Mon, 8 Apr 2002 14:15:24 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g38L6Ee12680; Mon, 8 Apr 2002 14:06:14 -0700
Date: Mon, 8 Apr 2002 14:06:14 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OpenPGP public key packet format
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

John Dlugosz writes:
> First, it seems that there are two utterly different version systems going
> on.  The "old packet" and "new packet" format allows more packet types in
> the new format, but otherwise doesn't affect the content, since the Version
> byte in the Type 6 (etc.) packet specifies Version 4 or 5.  So NAI's
> implementation (son of original PGP) uses old packets for "backward
> compatibility" with v2.6, but then uses a Version 4 Public Key packet which
> didn't exist before PGP 5.0, so using the older packet header is pointless.
> What's the deal here?  I'm supposing the real reason to use old packet
> header is to save a byte, in cases where they can be used (tags < 16).

If you're not interested in backwards compatibility with PGP 2, you can
use the new format packet tags.  If you require backwards compatibility,
you must use the old format tags and only V3 RSA keys.  If you're asking
why the commercial PGP versions use old format tags with V4 DSA keys,
it was in the hope that 2.6.2 could still parse the packets in terms of
their lengths, and skip over their unrecognizable contents.

> Second, how are the public key proper and the signing key specified?  I'm
> guessing that the key directly encoded in the Tag 6 is the signing(only)
> key, and all subkey packets are for public message keys.  The RFC says that
> the sign/encrypt only types for RSA are no longer used, but rather flags in
> the signature packet is used.  I see the following: Public Key (tag 6),
> User ID, Signature, User ID, Signature, Public Subkey, Signature.  I have
> two self-signed ID's (different email addresses), so I don't know what the
> third one is for.  I also suppose that although packets are not nested but
> sequential, the "applies to" is implied as a hiararchy?  That is, the sig
> applies to the previous ID?

Yes, there is an implied hierarchy.  This is illustrated in section 11.1
of the RFC.

> Anyway, with multiple signatures, does each one specify how the key is used
> in addition to saying "I vouch for him", and how do you make sure they all
> agree?  Can someone clarify this, please?

For the subkeys, the key usage flags subpacket can go in the subkey
signature.  For the top level key, probably the best place is in the
self-signature on all the userids.  I think the commercial PGP versions
look specifically in the self-sig on the primary userid.

The commercial versions of PGP do not support signature sub-keys.

Hal Finney


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38KUF806856 for ietf-openpgp-bks; Mon, 8 Apr 2002 13:30:15 -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 g38KUDm06852 for <[e-mail]>; Mon, 8 Apr 2002 13:30:14 -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 g38KUIm29400 for <[e-mail]>; Mon, 8 Apr 2002 16:30:18 -0400 (EDT)
Subject: OpenPGP public key packet format
To: [e-mail]
From: [e-mail]
Date: Mon, 8 Apr 2002 15:30:08 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/08/2002 04:30:04 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

I have a couple questions...

First, it seems that there are two utterly different version systems going
on.  The "old packet" and "new packet" format allows more packet types in
the new format, but otherwise doesn't affect the content, since the Version
byte in the Type 6 (etc.) packet specifies Version 4 or 5.  So NAI's
implementation (son of original PGP) uses old packets for "backward
compatibility" with v2.6, but then uses a Version 4 Public Key packet which
didn't exist before PGP 5.0, so using the older packet header is pointless.
What's the deal here?  I'm supposing the real reason to use old packet
header is to save a byte, in cases where they can be used (tags < 16).

Second, how are the public key proper and the signing key specified?  I'm
guessing that the key directly encoded in the Tag 6 is the signing(only)
key, and all subkey packets are for public message keys.  The RFC says that
the sign/encrypt only types for RSA are no longer used, but rather flags in
the signature packet is used.  I see the following: Public Key (tag 6),
User ID, Signature, User ID, Signature, Public Subkey, Signature.  I have
two self-signed ID's (different email addresses), so I don't know what the
third one is for.  I also suppose that although packets are not nested but
sequential, the "applies to" is implied as a hiararchy?  That is, the sig
applies to the previous ID?

Anyway, with multiple signatures, does each one specify how the key is used
in addition to saying "I vouch for him", and how do you make sure they all
agree?  Can someone clarify this, please?

What I'm doing:  I'm using OpenPGP in a system, and want to specify exactly
which packets should be used, as the program may be limited to this.  Also,
want to make sure I get it right when manipulating these files.

--John