Subject: bis05: Armor Headers

From: Marc Mutz <[email-masked]>
Date: Tue, 30 Apr 2002 17:09:32 +0200

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 <[email-masked]>

---

From: Werner Koch <[email-masked]>
Date: Tue, 30 Apr 2002 19:31:07 +0200

> 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 

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

---

From: David Shaw <[email-masked]>
Date: Tue, 30 Apr 2002 13:54:51 -0400

> 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  |  [email-masked]  |  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

Date: Tue, 30 Apr 2002 13:54:51 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: bis05: Armor Headers
Mail-Followup-To: [email-masked]
Sender: [email-masked]

> 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  |  [email-masked]  |  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

To: [email-masked]
Subject: Re: bis05: Armor Headers
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Tue, 30 Apr 2002 19:31:07 +0200
Lines: 19
Sender: [email-masked]

  Werner

Date: Tue, 30 Apr 2002 17:09:32 +0200
From: Marc Mutz <[email-masked]>
Subject: bis05: Armor Headers
To: [email-masked]
Organization: KDE
Content-description: clearsigned data
Sender: [email-masked]

Hi!

Marc

- -- 
Marc Mutz <[email-masked]>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-05.txt
Date: Mon, 29 Apr 2002 07:52:10 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 28 Apr 2002 16:52:22 -0700
Subject: Re: Notary signatures
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 26 Apr 2002 08:46:08 -0400
To: Derek Atkins <[email-masked]>, Jon Callas <[email-masked]>
From: Bill Frantz <[email-masked]>
Subject: Re: Notary signatures
Cc: OpenPGP <[email-masked]>
Sender: [email-masked]

At 11:21 PM -0400 4/25/02, Derek Atkins wrote:
>Jon Callas <[email-masked]> writes:
>
>> On 4/25/2002 5:54 PM, "Len Sassaman" <[email-masked]> 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
(408)356-8506         | DMCA/CBDTPA is to      | 16345 Englewood Ave.
[email-masked] | prevent fair use.      | Los Gatos, CA 95032, USA

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: Musings on Notary signatures
Date: Fri, 26 Apr 2002 16:34:51 -0400
Sender: [email-masked]

----- Original Message -----
From: "Jon Callas" <[email-masked]>
To: "vedaal" <[email-masked]>; "OpenPGP" <[email-masked]>
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

Date: Fri, 26 Apr 2002 12:48:26 -0700
Subject: Re: Musings on Notary signatures
From: Jon Callas <[email-masked]>
To: vedaal <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/26/2002 9:00 AM, "vedaal" <[email-masked]> 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

Date: Fri, 26 Apr 2002 15:18:57 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Musings on Notary signatures
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

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

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

Signature notation subpacket.

David

-- 
   David Shaw  |  [email-masked]  |  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

Subject: Re: Musings on Notary signatures
To: [email-masked]
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Fri, 26 Apr 2002 14:17:03 -0500
Sender: [email-masked]

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 <[email-masked]> on 04-26-2002 11:18:30 AM

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: Musings on Notary signatures

On Fri, Apr 26, 2002 at 10:12:57AM -0500, [email-masked] 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  |  [email-masked]  |  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

Date: Fri, 26 Apr 2002 09:46:39 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: Notary signatures
Sender: [email-masked]

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

Date: Fri, 26 Apr 2002 12:18:30 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Musings on Notary signatures
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Fri, Apr 26, 2002 at 10:12:57AM -0500, [email-masked] 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  |  [email-masked]  |  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

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: Musings on Notary signatures
Date: Fri, 26 Apr 2002 12:00:57 -0400
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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

Subject: Musings on Notary signatures
To: [email-masked]
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Fri, 26 Apr 2002 10:12:57 -0500
Sender: [email-masked]

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.

To: David Shaw <[email-masked]>, Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Notary signatures
Date: 26 Apr 2002 09:33:39 -0400
Lines: 36
Sender: [email-masked]

David Shaw <[email-masked]> 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 <[email-masked]> 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
       [email-masked]             www.ihtfp.com

Date: Fri, 26 Apr 2002 07:18:52 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Notary signatures
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

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  |  [email-masked]  |  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

To: OpenPGP <[email-masked]>
Subject: Re: Notary signatures
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 26 Apr 2002 10:42:27 +0200
Lines: 17
Sender: [email-masked]

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

Date: Thu, 25 Apr 2002 23:53:02 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
cc: OpenPGP <[email-masked]>
Subject: Re: Notary signatures
Sender: [email-masked]

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.

Date: Thu, 25 Apr 2002 22:31:00 -0700
Subject: Re: Notary signatures
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 26 Apr 2002 00:16:47 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Notary signatures
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Thu, Apr 25, 2002 at 11:21:43PM -0400, Derek Atkins wrote:
> 
> Jon Callas <[email-masked]> writes:
> 
> > On 4/25/2002 5:54 PM, "Len Sassaman" <[email-masked]> 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  |  [email-masked]  |  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

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Notary signatures
Date: 25 Apr 2002 23:21:43 -0400
Lines: 33
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> On 4/25/2002 5:54 PM, "Len Sassaman" <[email-masked]> 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
       [email-masked]             www.ihtfp.com

Date: Thu, 25 Apr 2002 22:03:14 -0400
From: David Shaw <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Notary signatures
Mail-Followup-To: Hal Finney <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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  |  [email-masked]  |  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

Date: Thu, 25 Apr 2002 18:55:19 -0700
Subject: Re: Timestamp Signatures (was Re: Notary signatures)
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/25/2002 6:18 PM, "David Shaw" <[email-masked]> 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

Date: Thu, 25 Apr 2002 18:48:24 -0700
Subject: Re: Notary signatures
From: Jon Callas <[email-masked]>
To: Hal Finney <[email-masked]>, <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/25/2002 6:27 PM, "Hal Finney" <[email-masked]> 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

Date: Thu, 25 Apr 2002 18:27:39 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Notary signatures
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 25 Apr 2002 21:18:53 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Timestamp Signatures (was Re: Notary signatures)
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

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  |  [email-masked]  |  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

Date: Thu, 25 Apr 2002 21:08:50 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Notary signatures
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

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  |  [email-masked]  |  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

Date: Thu, 25 Apr 2002 18:02:10 -0700
Subject: Re: Notary signatures
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/25/2002 5:54 PM, "Len Sassaman" <[email-masked]> 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

Date: Thu, 25 Apr 2002 17:58:35 -0700
Subject: Timestamp Signatures (was Re: Notary signatures)
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 25 Apr 2002 17:54:21 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
cc: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Notary signatures
Sender: [email-masked]

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.

Date: Thu, 25 Apr 2002 17:27:37 -0700
Subject: Re: Notary signatures
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/25/2002 5:05 PM, "David Shaw" <[email-masked]> 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

Date: Thu, 25 Apr 2002 20:05:27 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Notary signatures
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Thu, Apr 25, 2002 at 04:49:46PM -0700, Jon Callas wrote:
> On 4/25/2002 3:07 PM, "David Shaw" <[email-masked]> 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  |  [email-masked]  |  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

Date: Thu, 25 Apr 2002 16:49:46 -0700
Subject: Re: Notary signatures
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/25/2002 3:07 PM, "David Shaw" <[email-masked]> 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

Date: Thu, 25 Apr 2002 16:22:00 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: David Shaw <[email-masked]>
cc: <[email-masked]>
Subject: Re: Notary signatures
Sender: [email-masked]

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.

Date: Thu, 25 Apr 2002 18:07:04 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Notary signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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  |  [email-masked]  |  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

Date: Thu, 25 Apr 2002 14:30:44 -0700
Subject: New Draft Gone Out
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

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

    Jon

content-class: urn:content-classes:message
Subject: RE: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Date: Thu, 25 Apr 2002 21:31:40 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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
[email-masked]

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 <[email-masked]>
To: Michael Young <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/17/2002 5:20 PM, "Michael Young" <[email-masked]> 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.

Date: Sat, 20 Apr 2002 00:53:50 -0700
Subject: Re: What's left before a new RFC?
From: Jon Callas <[email-masked]>
To: Florian Weimer <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 4/19/2002 11:47 PM, "Florian Weimer" <[email-masked]>
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

To: [email-masked]
Subject: Re: What's left before a new RFC?
From: Florian Weimer <[email-masked]>
Date: Sat, 20 Apr 2002 08:47:06 +0200
Lines: 15
Sender: [email-masked]

Jon Callas <[email-masked]> 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 	                  [email-masked]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Thu, 18 Apr 2002 21:28:25 -0700
Subject: Re: bis04
From: Paul Holman <[email-masked]>
To: [email-masked]
Sender: [email-masked]

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                        <[email-masked]>
> -----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-----
>

Date: Thu, 18 Apr 2002 20:02:28 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 19 Apr 2002 03:19:45 +0100
From: Adam Back <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Sender: [email-masked]

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/

Subject: Re: Clearsigning, MIME, etc.
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 18 Apr 2002 15:23:10 -0500
Sender: [email-masked]

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 <[email-masked]> on 04-18-2002 12:35:21 PM

To:   [email-masked], [email-masked]
cc:   [email-masked]
Subject:  Re: Clearsigning, MIME, etc.

On Thursday 18 April 2002 18:31, [email-masked] 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 <[email-masked]>

Subject: Re: What's left before a new RFC?
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 18 Apr 2002 14:50:36 -0500
Sender: [email-masked]

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 <[email-masked]>@mail.imc.org on 04-18-2002 05:48:57 AM

Sent by:  [email-masked]

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

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 <[email-masked]>

To: "Hal Finney" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 18 Apr 2002 21:49:07 +0200
Lines: 11
Sender: [email-masked]

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

Subject: Re: What's left before a new RFC?
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Thu, 18 Apr 2002 14:41:17 -0500
Sender: [email-masked]

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 <[email-masked]>@mail.imc.org on 04-17-2002 05:54:01 PM

Sent by:  [email-masked]

To:   [email-masked]
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

Date: Thu, 18 Apr 2002 12:20:40 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Apr 2002 19:35:21 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: Clearsigning, MIME, etc.
To: [email-masked], [email-masked]
Cc: [email-masked]
Organization: KDE
Sender: [email-masked]

On Thursday 18 April 2002 18:31, [email-masked] 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 <[email-masked]>

Date: Thu, 18 Apr 2002 19:30:33 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: What's left before a new RFC?
To: Marcel Waldvogel <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked]
Organization: KDE
Sender: [email-masked]

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 <[email-masked]>

Date: Thu, 18 Apr 2002 19:57:12 +0100
From: Adam Back <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Whither comment packets?
Sender: [email-masked]

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
> 

To: [email-masked]
Subject: Re: Whither comment packets?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 18 Apr 2002 19:53:04 +0200
Lines: 9
Sender: [email-masked]

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

Date: Thu, 18 Apr 2002 10:12:28 -0700
Subject: Re: Whither comment packets?
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

On 4/18/2002 9:44 AM, "David Shaw" <[email-masked]> 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

Date: Thu, 18 Apr 2002 12:44:49 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Whither comment packets?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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  |  [email-masked]  |  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

Subject: Re: Clearsigning, MIME, etc.
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Thu, 18 Apr 2002 11:31:08 -0500
Sender: [email-masked]

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!

Date: Thu, 18 Apr 2002 16:46:21 +0200
From: Marcel Waldvogel <[email-masked]>
To: Marc Mutz <[email-masked]>
CC: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: What's left before a new RFC?
Sender: [email-masked]

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

Date: Thu, 18 Apr 2002 14:44:54 +0100
From: Adam Back <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Sender: [email-masked]

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

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Marcel Waldvogel <[email-masked]>, Jon Callas <[email-masked]>
Subject: Re: What's left before a new RFC?
Date: Thu, 18 Apr 2002 12:48:57 +0200
Cc: [email-masked]
Sender: [email-masked]

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 <[email-masked]>

Date: Thu, 18 Apr 2002 10:17:03 +0200
From: Marcel Waldvogel <[email-masked]>
To: Jon Callas <[email-masked]>
CC: [email-masked]
Subject: Re: What's left before a new RFC?
Sender: [email-masked]

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
>

Date: Wed, 17 Apr 2002 22:40:14 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: bis04: revocation key nits
Mail-Followup-To: Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

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  |  [email-masked]  |  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

Date: Wed, 17 Apr 2002 19:26:26 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 17 Apr 2002 18:58:20 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Apr 2002 02:27:56 +0100
From: Adam Back <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Sender: [email-masked]

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.

Date: Wed, 17 Apr 2002 18:13:34 -0700
To: David Shaw <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: bis04: revocation key nits
Sender: [email-masked]

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

Date: Wed, 17 Apr 2002 20:52:50 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Revocation target subpacket (Re: What's left before a new RFC?)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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  |  [email-masked]  |  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

Date: Wed, 17 Apr 2002 20:49:18 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: bis04: revocation key nits
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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  |  [email-masked]  |  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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Revocation target subpacket (Re: What's left before a new RFC?)
Date: Wed, 17 Apr 2002 20:20:26 -0400
Sender: [email-masked]

From: "Jon Callas" <[email-masked]>
> 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).

Date: Thu, 18 Apr 2002 01:46:45 +0200
From: Thomas Roessler <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Clearsigning, MIME, etc.
Mail-Followup-To: Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

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                        <[email-masked]>

Date: Wed, 17 Apr 2002 15:54:01 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: What's left before a new RFC?
Sender: [email-masked]

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

Date: Wed, 17 Apr 2002 15:46:51 -0700
To: Thomas Roessler <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Clearsigning, MIME, etc.
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 17 Apr 2002 14:37:25 -0700
To: Thomas Roessler <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: literal data packet tags - nit
Sender: [email-masked]

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

Date: Wed, 17 Apr 2002 22:47:45 +0200
From: Timo Schulz <[email-masked]>
To: [email-masked]
Subject: Re: sha-1 protected test key
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: sha-1 protected test key
Date: Wed, 17 Apr 2002 21:52:30 +0200
Sender: [email-masked]

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

To: [email-masked]
Subject: sha-1 protected test key
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 17 Apr 2002 17:57:15 +0200
Lines: 15
Sender: [email-masked]

--=-=-=

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

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

--=-=-=--

Date: Wed, 17 Apr 2002 15:13:15 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: bis04: Armor headers w/ non-us-ascii values
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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                        <[email-masked]>

Date: Wed, 17 Apr 2002 14:28:03 +0200
From: Marc Mutz <[email-masked]>
Subject: bis04: Armor headers w/ non-us-ascii values
To: [email-masked]
Cc: [email-masked]
Organization: KDE
Sender: [email-masked]

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 <[email-masked]>

Date: Wed, 17 Apr 2002 11:33:57 +0200
From: Thomas Roessler <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Clearsigning, MIME, etc.
Mail-Followup-To: Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

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                        <[email-masked]>

Date: Wed, 17 Apr 2002 11:15:58 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: literal data packet tags - nit
Mail-Followup-To: [email-masked]
Sender: [email-masked]

(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                        <[email-masked]>

Date: Tue, 16 Apr 2002 18:05:51 -0700
Subject: Clearsigning, MIME, etc.
From: Jon Callas <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 16 Apr 2002 13:15:45 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: bis04
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Apr 16, 2002 at 11:01:57AM -0500, [email-masked] 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
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

Subject: Re: bis04
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Tue, 16 Apr 2002 11:01:57 -0500
Sender: [email-masked]

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 <[email-masked]>@mail.imc.org on 04-15-2002 07:38:13 PM

Sent by:  [email-masked]

To:   Werner Koch <[email-masked]>, [email-masked]
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

Date: Tue, 16 Apr 2002 15:47:51 +0200
From: Thomas Roessler <[email-masked]>
To: vedaal <[email-masked]>
Cc: [email-masked]
Subject: Re: bis04
Mail-Followup-To: vedaal <[email-masked]>, [email-masked]
Sender: [email-masked]

--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                        <[email-masked]>

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

--2/5bycvrmDh4d1IB--

Date: Tue, 16 Apr 2002 15:43:50 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Clearsigning considered harmful.
Mail-Followup-To: [email-masked]
Sender: [email-masked]

 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                        <[email-masked]>

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: bis04
Date: Tue, 16 Apr 2002 09:31:21 -0400
Sender: [email-masked]

- ----- Original Message -----
From: "Thomas Roessler" <[email-masked]>
To: "Jon Callas" <[email-masked]>
Cc: "Werner Koch" <[email-masked]>; <[email-masked]>
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

n.b.
the above message was done in OE 5.5, displayed the special characters, and
verified the signature
vedaal

Date: Tue, 16 Apr 2002 09:16:38 +0200
From: Thomas Roessler <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: bis04
Mail-Followup-To: Jon Callas <[email-masked]>, Werner Koch <[email-masked]>, [email-masked]
Sender: [email-masked]

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                        <[email-masked]>

Date: Mon, 15 Apr 2002 17:38:13 -0700
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: bis04
Sender: [email-masked]

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

Date: Mon, 15 Apr 2002 17:22:55 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: bis04
Sender: [email-masked]

At 11:04 AM -0500 4/15/02, [email-masked] 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

Subject: Re: Recipient-verifiable messages
To: [email-masked]
From: [email-masked]
Date: Mon, 15 Apr 2002 13:42:43 -0500
Sender: [email-masked]

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

Date: Mon, 15 Apr 2002 09:44:25 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Recipient-verifiable messages
Sender: [email-masked]

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

Subject: Re: bis04
To: [email-masked]
From: [email-masked]
Date: Mon, 15 Apr 2002 11:04:46 -0500
Sender: [email-masked]

From: John Dlugosz

The date in the headers reads April 15, 2001.

Subject: Re: Recipient-verifiable messages
To: [email-masked]
From: [email-masked]
Date: Mon, 15 Apr 2002 10:31:33 -0500
Sender: [email-masked]

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

To: [email-masked]
Subject: bis04
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 15 Apr 2002 16:35:02 +0200
Lines: 29
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-04.txt
Date: Mon, 15 Apr 2002 07:29:15 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sat, 13 Apr 2002 21:28:53 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: quasi-deniable signing
Sender: [email-masked]

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

Date: Sat, 13 Apr 2002 10:59:33 -0400
From: John Kane <[email-masked]>
To: [email-masked]
Subject: quasi-deniable signing
Sender: [email-masked]

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.

Date: Fri, 12 Apr 2002 18:44:58 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Recipient-verifiable messages
Sender: [email-masked]

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

Date: Thu, 11 Apr 2002 17:29:42 -0700
To: "David P. Kemp" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Recipient-verifiable messages
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 11 Apr 2002 20:06:33 -0400
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Recipient-verifiable messages
Sender: [email-masked]

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.

Date: Thu, 11 Apr 2002 15:42:02 -0700
To: "Hal Finney" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Recipient-verifiable messages
Sender: [email-masked]

>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

Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Thu, 11 Apr 2002 17:10:47 -0500
Sender: [email-masked]

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.

Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Thu, 11 Apr 2002 17:01:57 -0500
Sender: [email-masked]

From: John Dlugosz

Beautiful.

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

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

Sent by:  [email-masked]

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

----- Original Message -----
From: "Hal Finney" <[email-masked]>
To: <[email-masked]>
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

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Date: Thu, 11 Apr 2002 16:43:56 -0400
Sender: [email-masked]

----- Original Message -----
From: "Hal Finney" <[email-masked]>
To: <[email-masked]>
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

Date: Thu, 11 Apr 2002 08:45:39 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Sender: [email-masked]

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

Sam Roberts <[email-masked]> 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

Date: Thu, 11 Apr 2002 18:23:34 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Sam Roberts <[email-masked]> 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.

From: Volker Augustin <[email-masked]>
To: [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Thu, 11 Apr 2002 06:58:04 +0200
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Wed, 10 Apr 2002 22:59:01 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Cc: Paul Shields <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Mail-Followup-To: [email-masked], Paul Shields <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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 [email-masked], 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                        <[email-masked]>

-- 
Sam Roberts <[email-masked]> (Vivez sans temps mort!)

From: Keith Moore <[email-masked]>
To: Volker Augustin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless 
Date: Wed, 10 Apr 2002 21:34:28 -0400
Sender: [email-masked]

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

From: Volker Augustin <[email-masked]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 21:56:52 +0200
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 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

Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: [email-masked]
From: [email-masked]
Date: Wed, 10 Apr 2002 14:54:17 -0500
Sender: [email-masked]

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

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Marcel Waldvogel <[email-masked]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 21:12:39 +0200
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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 <[email-masked]>

Date: Wed, 10 Apr 2002 14:12:25 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: forwarding an encrypted message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Apr 10, 2002 at 11:01:47AM -0500, [email-masked] 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
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

From: Keith Moore <[email-masked]>
To: Marc Mutz <[email-masked]>
cc: [email-masked], Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless 
Date: Wed, 10 Apr 2002 13:52:00 -0400
Sender: [email-masked]

> 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

From: "vedaal" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: forwarding an encrypted message
Date: Wed, 10 Apr 2002 13:40:50 -0400
Sender: [email-masked]

- ----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked], Keith Moore <[email-masked]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 19:33:17 +0200
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wednesday 10 April 2002 18:10, [email-masked] 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 <[email-masked]>

Date: Wed, 10 Apr 2002 13:16:28 -0400
From: Paul Shields <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Sender: [email-masked]

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 <[email-masked]> 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.

[email-masked] 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

Subject: Re: forwarding an encrypted message
To: [email-masked]
From: [email-masked]
Date: Wed, 10 Apr 2002 11:29:47 -0500
Sender: [email-masked]

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 <[email-masked]>@mail.imc.org on 04-10-2002 08:41:50 AM

Sent by:  [email-masked]

To:   Matthew Byng-Maddick <[email-masked]>
cc:   [email-masked]
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

Date: Wed, 10 Apr 2002 18:06:51 +0200
From: Thomas Roessler <[email-masked]>
To: Paul Shields <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Mail-Followup-To: Paul Shields <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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                        <[email-masked]>

Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Wed, 10 Apr 2002 11:22:11 -0500
Sender: [email-masked]

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 <[email-masked]> on 04-09-2002 04:27:04 PM

To:   [email-masked], [email-masked]
cc:   [email-masked], [email-masked], [email-masked]
Subject:  Re: Bug#40394: forwarding an encrypted PGP message is useless

At 3:33 PM -0500 4/9/02, [email-masked] 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

Date: Wed, 10 Apr 2002 09:10:21 -0700 (PDT)
From: [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: Keith Moore <[email-masked]>
Cc: Marc Mutz <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Subject: re: forwarding an encrypted message
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Wed, 10 Apr 2002 11:01:47 -0500
Sender: [email-masked]

From: John Dlugosz

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.

"vedaal" <[email-masked]>@mail.imc.org on 04-09-2002 03:26:55 PM

Sent by:  [email-masked]

To:   <[email-masked]>
cc:
Subject:  re: forwarding an encrypted message

- ----- Original Message -----
From: "Simon Josefsson" <[email-masked]>
To: "Marc Mutz" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 09, 2002 3:32 PM
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless

>
> Marc Mutz <[email-masked]> 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

To: Paul Shields <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
From: Derek Atkins <[email-masked]>
Date: 10 Apr 2002 11:51:38 -0400
Lines: 25
Sender: [email-masked]

Paul Shields <[email-masked]> 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
       [email-masked]                        PGP key available

Date: Wed, 10 Apr 2002 10:46:26 -0400
From: Paul Shields <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Sender: [email-masked]

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

[email-masked] 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.

From: Keith Moore <[email-masked]>
To: Marc Mutz <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless 
Date: Wed, 10 Apr 2002 09:50:50 -0400
Sender: [email-masked]

> 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

Date: Wed, 10 Apr 2002 14:41:50 +0100
From: Ben Laurie <[email-masked]>
To: Matthew Byng-Maddick <[email-masked]>
Cc: [email-masked]
Subject: Re: forwarding an encrypted message
Sender: [email-masked]

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

Date: Wed, 10 Apr 2002 10:19:19 +0100
To: Jon Callas <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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
<[email-masked]>

From: Magnus von Koeller <[email-masked]>
To: [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Date: Wed, 10 Apr 2002 10:33:30 +0200
Sender: [email-masked]

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:    [email-masked]
address:  Georg-Westermann-Allee 76
          D-38104 Braunschweig / Germany
phone:    +49-531-2094886
mobile:   +49-179-4562940
web:      http://www.vonkoeller.de

Date: Wed, 10 Apr 2002 09:06:16 +0100
From: Matthew Byng-Maddick <[email-masked]>
To: [email-masked]
Subject: Re: forwarding an encrypted message
Organization: Colondot.net
Mail-Copies-To: never
Sender: [email-masked]

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         <[email-masked]>           http://colondot.net/

Date: Tue, 9 Apr 2002 14:27:04 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 3:33 PM -0500 4/9/02, [email-masked] 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

Date: Tue, 9 Apr 2002 16:08:03 -0500
From: "Clinton E. Troutman" <[email-masked]>
Reply-To: "Clinton E. Troutman" <[email-masked]>
Organization: CeTro
To: Simon Josefsson <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re[2]: Bug#40394: forwarding an encrypted PGP message is useless
Sender: [email-masked]

- --- 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:[email-masked]
- -----
"You can tell the Mafia is running the cockfight if the duck wins." -
Anon.
�F�\�$%

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: re: forwarding an encrypted message
Date: Tue, 9 Apr 2002 16:26:55 -0400
Sender: [email-masked]

- ----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Marc Mutz" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 09, 2002 3:32 PM
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless

> 
> Marc Mutz <[email-masked]> 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

Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Date: Tue, 9 Apr 2002 15:33:34 -0500
Sender: [email-masked]

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 <[email-masked]>@mail.imc.org on 04-09-2002 12:47:01 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:   [email-masked], [email-masked]
Subject:  Re: Bug#40394: forwarding an encrypted PGP message is useless

[ 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
> [email-masked]
> http://mail.kde.org/mailman/listinfo/kmail

- --
Marc Mutz <[email-masked]>

To: Marc Mutz <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Apr 2002 21:32:00 +0200
Lines: 23
Sender: [email-masked]

Marc Mutz <[email-masked]> 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.

From: "Leon Kuunders" <[email-masked]>
To: "Marc Mutz" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Bug#40394: forwarding an encrypted PGP message is useless
Date: Tue, 9 Apr 2002 21:08:28 +0200
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marc Mutz
> Sent: 09 April 2002 19:47
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
> [email-masked]
> http://mail.kde.org/mailman/listinfo/kmail

- --
Marc Mutz <[email-masked]>

Date: Tue, 9 Apr 2002 20:39:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Marc Mutz <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
Sender: [email-masked]

Marc Mutz <[email-masked]>
> 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

Date: Tue, 09 Apr 2002 19:47:01 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
To: [email-masked]
Cc: [email-masked], [email-masked]
Organization: KDE
Sender: [email-masked]

[ 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
> [email-masked]
> http://mail.kde.org/mailman/listinfo/kmail

- -- 
Marc Mutz <[email-masked]>

Subject: Re: OpenPGP public key packet format
To: [email-masked]
From: [email-masked]
Date: Tue, 9 Apr 2002 10:01:32 -0500
Sender: [email-masked]

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.

Date: Mon, 8 Apr 2002 14:06:14 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: OpenPGP public key packet format
Sender: [email-masked]

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

Subject: OpenPGP public key packet format
To: [email-masked]
From: [email-masked]
Date: Mon, 8 Apr 2002 15:30:08 -0500
Sender: [email-masked]

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