Subject: Re: Davis paper revisited // separation of signed and encrypted messages into clearsigned messages

From: "Hal Finney" <[email-masked]>
Date: Thu, 21 Aug 2003 13:14:25 -0700

Vedaal writes:

> have been able to separate a signed and encrypted message into a freestanding
> verifiable clearsigned message
>
> have put up the example here:
> http://www.angelfire.com/pr/pgpf/sclsf.html

Makes sense, signed messages are signed messages.

> would like to ask:
>
> [1] is there any way to distinguish the composite reconstruction forgery
> from a 'real' de novo clearsigned message ?

I disagree that this is a forgery.  Rather, it is a reformatting (plus
you have stripped off an encryption layer).  Generally, the hashing
rules for text-mode signed messages (as you have in your encrypted and
signed message) and clearsigned messages are the same.

However some (older?) versions of PGP don't follow the spec and don't
ignore trailing whitespace for text-mode signed messages, while they
do ignore it for clearsigned messages.  So if you had a message with
trailing whitespace and created a text-mode signed message (or a signed
and encrypted message) using such a version of PGP, it would not verify
when converted to a clearsigned message.  However such messages would
tend to have verification difficulties anyway due to this variation
from the spec.

> [2] is there a difference between GnuPG and PGP in the way a message
> is clearsigned, as opposed to signed and encrypted,
> that might distinguish the forged composite, from a real clearsigned
> message?

Again I would say "reformatted" rather than "forged".  These are just
two different formats for signed messages.  Except for the variation I
mentioned above I think that the two are hashed the same for GPG and PGP.

> while the Davis paper describes separating and re-encrypting,
> it doesn't deal with separating into a freestanding clearsigned message.

I saw some code to do this somewhere a while back.  It's trivial, once
you strip off the encryption layer and leave the text-mode signed message,
to convert it to a clearsigned message.  Just wrap the literal payload
in the appropriate BEGIN PGP headers, and base64 encode the signature
packet.

Hal

---

From: David Shaw <[email-masked]>
Date: Fri, 29 Aug 2003 23:07:10 -0400

On Thu, Aug 21, 2003 at 01:14:25PM -0700, Hal Finney wrote:

> do ignore it for clearsigned messages.

As far as I recall, no version of PGP ignores trailing whitespace for
textmode signed messages.  There is also a little gotcha in
clearsigned messages, as the tab character is not counted as
whitespace in PGP, while it is counted as whitespace in 2440.

David

Date: Fri, 29 Aug 2003 23:07:10 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Trailing whitespace (was Re: Davis paper revisited)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Aug 21, 2003 at 01:14:25PM -0700, Hal Finney wrote:

> do ignore it for clearsigned messages.

As far as I recall, no version of PGP ignores trailing whitespace for
textmode signed messages.  There is also a little gotcha in
clearsigned messages, as the tab character is not counted as
whitespace in PGP, while it is counted as whitespace in 2440.

David

Date: Fri, 29 Aug 2003 23:02:06 -0400
From: David Shaw <[email-masked]>
To: openpgp <[email-masked]>
Subject: Re: Signature extensions?
Mail-Followup-To: openpgp <[email-masked]>
Sender: [email-masked]

On Tue, Aug 26, 2003 at 12:02:26PM -0700, Mark Williams wrote:
> 
> Hi, I am working on some software where I am planning
> on using OpenPGP signature formats but with some
> custom extension subpackets.  Would this group be
> interested in seeing these extensions documented,
> perhaps in a draft informational RFC?

Hard to say without knowing what you are extending, how you are
extending it, and why ;)

David

Date: Tue, 26 Aug 2003 12:02:26 -0700 (PDT)
From: Mark Williams <[email-masked]>
Subject: Signature extensions?
To: openpgp <[email-masked]>
Sender: [email-masked]

Hi, I am working on some software where I am planning
on using OpenPGP signature formats but with some
custom extension subpackets.  Would this group be
interested in seeing these extensions documented,
perhaps in a draft informational RFC?  Is there any
chance that the extensions might eventually be adopted
into a future version of the OpenPGP specification? 
What would that procedure be?

Thanks for your help.

Mark K. Williams
[email-masked]

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

To: Don Davis <[email-masked]>
Cc: <[email-masked]>, [email-masked]
Subject: Re: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Sat, 23 Aug 2003 17:06:58 +0200
Sender: [email-masked]

On Fri, 22 Aug 2003 22:18:55 -0400, Don Davis said:

>   * a signed-&-encrypted message would include
>     the recipient's ID under the signature.

I came later to the conclusion that it is not gpg's task to construct
the notation data but that of a MUA.  This is because a MUA has far
better information on who are the intended recipients and a MUA can
also much better check and display such notation data.  This is
similar to the good practice to warn when a reply is about to send to
someone else than the orginal sender as indicated by the signature.

Adding this to GnuPG would overload it with functions out of its
domain.  GnuPG also does no MIME encoding and other stuff a MUA can do
better.

Salam-Shalom,

   Werner

-- 
Werner Koch                                      <[email-masked]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org

From: Ian Brown <[email-masked]>
To: iang <[email-masked]>, ietf-openpgp <[email-masked]>
Subject: RE: Davis paper revisited // separation of signed and encrypted  messages into clearsigned messages
Date: Sat, 23 Aug 2003 10:35:45 +0100
Importance: Normal
Sender: [email-masked]

> What you appear to be asking for is a recipient-based signature.

Adam Back and I proposed a way to do this in OpenPGP a few years ago...
http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm

Date: Fri, 22 Aug 2003 18:16:56 -0700
Subject: Re: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
From: Jon Callas <[email-masked]>
To: <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

I just want to make sure I understand this.

The problem is this:

Alice sends Bob an encrypted and signed message.

Bob decrypts the message, and then does byte-surgery to construct a
plaintext clearsigned message that the signature verifies, and anyone in the
world can read.

This is the "attack," right?

    Jon

Date: Fri, 22 Aug 2003 14:01:30 -0400
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: Davis paper revisited  //  separation of signed and encrypted  messages into clearsigned messages
Sender: [email-masked]

[email-masked] wrote:

> the point is,
> 
> can there be an additonal packet feature that somehow distinguishes
> a signed and encrypted message, from a clearsigned one

Signed is signed, regardless of how it was then later
transmitted.

What you appear to be asking for is a recipient-based
signature.

That is, Alice and Bob can sign messages to each other,
knowing that each can verify the signatures, but they
can't reliably prove this to others.  Hence, leakages
reduce to the same status as made up claims.

(I believe this is done relatively easily with MACs based
on previous key exchanges ... but the more crypto-cogniscenti
will know.)

My essential point is that it appears that you are trying
to overload a minor formatting feature with a high level
signature meaning and purpose distinction?

Yes, sure, this could be done, but it's not the right
place for it, I would have thought.  Let's map out the
meaning of this signature first, and then think about
a) whether it is useful, and b) how to do it.

-- 
iang

Date: Fri, 22 Aug 2003 08:57:41 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
Sender: [email-masked]

I agree that combinations of sign and encrypt don't really solve the
problem that the sender can have his plaintext revealed in a way that
cryptographically binds him to it via his signature.  At best we can
make it clear that this was done without his intention, but as Adrian von
Bidder points out this could be done equally well by a notation "this is
intended to be private mail from Alice to Bob" at the top of the message.

One addition: it is not necessary for the receiver to reveal his secret
key in order to prove a signature over plaintext on an E/S/E (or S/E)
message (i.e. encrypt and then sign the encryption).  He can reveal
the session key (which is used once per message and then thrown away)
and then prove it valid.  I have seen some software to do that.

I can't deny that these facts may be contrary to (some) users'
expectations, since users here have explicitly stated that these are
surprising to them.  Nevertheless these are the cryptographic realities,
and the solution is to try to improve the users' understandings of
the issue.

Now, there are cryptographic mechanisms by which Alice can send to
Bob a message which could equally have been signed by either Alice or
Bob.  Bob can't then show this around and bind it to Alice because he
could have created it as a forgery.  These are the "group", "ring"
or perhaps "designated verifier" signatures.  We discussed the possibility
of incorporating them into a (future? addendum?) spec at some point.
If people really want to send signed messages which can't be further
revealed to others, this is something we might pursue.

Hal Finney

Date: Fri, 22 Aug 2003 07:42:49 -0700
To: [email-masked]
Cc: [email-masked]
Subject: Re: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
From: <[email-masked]>
Sender: [email-masked]

On Fri, 22 Aug 2003 01:49:23 -0700 Adrian von Bidder 

[...]

>vedaal:
>> that did not reflect the intent of the sender, who would never
>think
>> of posting it unencrypted.
>
>If you send sensible content to somebody you can't trust to keep
>it secret, 
>there's no technical solution to solve that problem. Don't send
>that person 
>any sensible content - encrypted or not.

consider the case of a high-ranking corporate employee who left a company
on unfriendly terms,

or a pt./dr/ communication where, at a later date, the pt. is suing the
dr.

the content of the communication was perfectly appropriate in encrypted
form, at the time it was communicated

but,

if it is (maliciously, anonymously) posted by the receiver,
the reciver can claim that the dr. violated medical privacy issues, 
and someone in the corporation can claim that the sender 'leaked' sensitive
material to a public forum

of course, the sender can counter:

"i didn't do it !
it was a malious reconstruction of the message by the receiver into clearsigned
form!"

but this still leaves some doubt ...

[...]

>The recipient can publish the E/S/E message without the outer encryption
>>
>layer. Then he publishes the decrypted message and his public key.
>Everybody 
>can the generate the encrypted message and, with the signature,
>verify that 
>it is the same message. So this "solution" falls apart, too.

no it doesn't,

if the sender doesn't routinely encrypt to self,
then even if the receiver publishes the session key, then the 'leak'
can unequivocally be shown to be the receiver

the point is, 

can there be an additonal packet feature that somehow distinguishes
a signed and encrypted message, from a clearsigned one
(which could be done in backward compatible form, where older versions
might not 'recognize/be able to interpret' the new packet, but could
decrypt anyway,
while newer versions could be used to distinguish the signature/message
type.)

with Respect,

vedaal  

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

From: Adrian von Bidder <[email-masked]>
Organization: granitsoft.ch
To: [email-masked]
Subject: Re: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
Date: Fri, 22 Aug 2003 10:49:23 +0200
Sender: [email-masked]

--Boundary-02=_XkdR/FXlJ4cCxll
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

[People, why can't you use a sensible mailer who produces In-Reply-To or=20
References header?]

=2E..
vedaal:
> that did not reflect the intent of the sender, who would never think
> of posting it unencrypted.

If you send sensible content to somebody you can't trust to keep it secret,=
=20
there's no technical solution to solve that problem. Don't send that person=
=20
any sensible content - encrypted or not.

If you S/E/S the message, you can still stripp the outer signature and the=
=20
encryption and get a perfectly readable signed message. True, there could b=
e=20
some indication that the inner signature was part of a S/E/S message - but =
in=20
the original case, the sender could put a notice 'this is a confidential=20
message and was sent encrypted' in the message text.

IIRC E/S/E had some other significant drawback, somebody will certainly poi=
nt=20
it out here, but it would "solve" that particular problem. But I don't thin=
k=20
that it does achieve more than putting 'this is a confidential message' in=
=20
the signed body:

The recipient can publish the E/S/E message without the outer encryption=20
layer. Then he publishes the decrypted message and his public key. Everybod=
y=20
can the generate the encrypted message and, with the signature, verify that=
=20
it is the same message. So this "solution" falls apart, too.

cheers
=2D- vbi

=2D-=20
featured link: http://fortytwo.ch/gpg/subkeys

--Boundary-02=_XkdR/FXlJ4cCxll
Content-Type: application/pgp-signature
Content-Description: signature

Signature policy: http://fortytwo.ch/legal/gpg/email.20020822?version=1.5&md5sum=5dff868d11843276071b25eb7006da3e

--Boundary-02=_XkdR/FXlJ4cCxll--

Date: Thu, 21 Aug 2003 14:09:12 -0700
To: [email-masked]
Cc: 
Subject: Re: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
From: <[email-masked]>
Sender: [email-masked]

On Thu, 21 Aug 2003 13:14:25 -0700 Hal Finney <[email-masked]> wrote:

[...]

>I disagree that this is a forgery.  Rather, it is a reformatting

[...]

it is a forgery only in the sense, that if it were, for example, posted
anonymously by someone else,
then there could be circumstances where people viewing it might be upset
that such a message that should have been (and was) encrypted,
was posted as a public clearsigned message.

the term 'forgery' was meant to imply, that the message could be changed
in a way
that did not reflect the intent of the sender, who would never think
of posting it unencrypted.

in a sense, it is the same as the Davis re-encryption, which also does
not reflect the intent of the sender to send it to the third party

but, 

in the case of re-encryption to another receiver, the sender can take
pre-cautions of addressing the 'real' intended receiver by name in the
message plaintext.

while in the case of the clearsigned reconstruction, there is no such

precaution to demonstrate that the sender never intended sending an open

message 
(short of the E,(S&E) solution) 

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Thu, 21 Aug 2003 13:14:25 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
Sender: [email-masked]

Hal

Date: Thu, 21 Aug 2003 10:55:53 -0700
To: [email-masked]
Cc: 
Subject: Davis paper revisited  //  separation of signed and encrypted messages into clearsigned messages
From: <[email-masked]>
Sender: [email-masked]

(the keys and messages are in 3des, idea is not necessary )

would like to ask:

tia,

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: OpenPGP BOF at CRYPTO 2003
Date: Mon, 11 Aug 2003 13:04:58 +0900
Sender: [email-masked]

Hi,  

OpenPGP BOF and PGP Keysigning will be hold at CRYPTO 2003 Tuesday
afternoon (14:00-15:30 Tuesday August 19, 2003).  I hope to see you
soon.

See more details:

  CRYPTO 2003
  http://www.iacr.org/conferences/crypto2003/
  
  OpenPGP BOF and PGP Keysigning
  http://www.iacr.org/conferences/crypto2003/content.html

----

    *  Hironobu SUZUKI <[email-masked]>, OpenPGP BOF           

    I'm an auther of OpenPGP public keyserver, a.k.a
    OpenPKSD. Sometime, I'd like to ask to PGP, GPG and other public
    keyserver developers about their activities because keyserver have
    to work with other keyserver implementations, PGP/GPG tools and
    etc.  Also I'd like to discuss ideas about OpenPGP and keyserver.
    Informal face-to-face meeting of OpenPGP in CRYPTO 2003 is a good
    change to know what is going on around OpenPGP.  If you have idea
    or/and proposal for OpenPGP BOF, feel free to contact to
    <[email-masked]>.

    * PGP Keysigning
 
    After the OpenPGP BOF, in the same room, will be a PGP keysigning
    gathering, where PGP users can identify themselves and take away
    verified PGP key fingerprints for subsequent signing, enhancing
    the PGP Web of Trust.
---

---
Hironobu SUZUKI
E-Mail: [email-masked]
URL: http://h2np.net

Subject: Re: signature woes and reconciliation, examples appreciated
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Fri, 8 Aug 2003 10:46:59 -0500
Sender: [email-masked]

Adding "...in the same hash context" would probably be enough, as hash
contexts are explained in the key stretching section.  Of course, adding
pseudocode would not hurt.

                      "Hal Finney"                                                                                                
                      <[email-masked]>             To:      [email-masked], [email-masked]                            
                      Sent by:                     cc:                                                                            
                      owner-ietf-openpgp@m         Subject: Re: signature woes and reconciliation, examples appreciated           
                      ail.imc.org                                                                                                 

                      07/31/2003 07:15 PM                                                                                         

> From: [email-masked]
> I recently ran into trouble trying to calculate the hash needed to
> verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python
> hopeful-implementation-to-be.

I've had someone else run into the same problem interpreting this part of
the spec.  The language about "first you hash this, then you hash that,
then you hash this other thing" seems very natural to me (I wrote much of
it after all), working with a programming interface where you pass data
incrementally into a hash context object.  But other people interpret
it as you did, that you produce a hash of the first part, then a hash
of the second part, then a hash of the third part, and somehow combine
these hashes together to get the final signature.

Hal Finney

Date: Tue, 5 Aug 2003 19:05:52 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: multiple signature packets
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Aug 05, 2003 at 07:26:04AM -0700, [email-masked] wrote:

> On Mon, 04 Aug 2003 17:03:57 -0700 David Shaw <[email-masked]>
> wrote:
> 
> [...]
> 
> >> are multiple simultaneous signatures acceptable Open PGP behavior
> >?
> >
> >The first example you gave was of a nested one-pass signature, and
> >the
> >second example was a clearsigned message with two signatures after
> >it.
> >
> >While it is unfortunate that 6.5.8 can't handle them, both of these
> >constructions are legal in OpenPGP (as per sections 5.4 and 7).
> 
> 6.5.8 can handle all except the clearsigned messages
> (btw, 7.xx acts like 8, and handles everything)
> 
> is there a gnupg command syntax that would allow for a nested one
> pass signature during clearsigning ?

There is no such concept.  All clear signatures by their nature (being
a signature that can be processed in one pass, by specifying the hash
before the data begins) are one pass.

David

Date: Tue,  5 Aug 2003 07:26:04 -0700
To: [email-masked]
Cc: 
Subject: Re: multiple signature packets
From: <[email-masked]>
Sender: [email-masked]

On Mon, 04 Aug 2003 17:03:57 -0700 David Shaw <[email-masked]>
wrote:

[...]

>> are multiple simultaneous signatures acceptable Open PGP behavior
>?
>
>The first example you gave was of a nested one-pass signature, and
>the
>second example was a clearsigned message with two signatures after
>it.
>
>While it is unfortunate that 6.5.8 can't handle them, both of these
>constructions are legal in OpenPGP (as per sections 5.4 and 7).

6.5.8 can handle all except the clearsigned messages
(btw, 7.xx acts like 8, and handles everything)

is there a gnupg command syntax that would allow for a nested one pass
signature during clearsigning ?

{not suggesting it, as 6.5.8 can handle the armored signing, so it is
compatible enough,
but am curious if it could somehow be done)

tia,

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Mon, 04 Aug 2003 17:45:19 -0700
Subject: Re: Clarification needed on compressed messages
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
CC: Michael Young <[email-masked]>
Sender: [email-masked]

On 8/2/03 2:37 PM, "David Shaw" <[email-masked]> wrote:

> I'd like to change that to:
> 
> Literal Message :- Literal Data Packet |
>                    Literal Message, Literal Data Packet.
> 
> The draft, as it stands now, is internally inconsistent.  I'd like to
> fix that.

Changed.

    Jon

Date: Mon, 4 Aug 2003 20:03:57 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: multiple signature packets
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Aug 04, 2003 at 02:41:18PM -0700, [email-masked] wrote:
> 
> 
> have recently received a clearsigned PGP message that was signed
> simultaneously with two different PGP keys,
> but it caused 6.5.8ckt (build 8) to crash
> 
> the double signed messages can easily be generated from gnupg (command
> line only),
> but (afaik) not from pgp, even from the command line (2.x or 6.x)
> 
> have put up examples here:
> http://www.angelfire.com/pr/pgpf/dspm.html
> 
> have found that the double signed messages were not a problem in pgp
> 8 under any circumstances, and were not a problem for 6.5.8 as long
> as they weren't clearsigned

[..]

> {sort of cool, actually,   i wish it could be done from pgp ;-)   }
> 
> are multiple simultaneous signatures acceptable Open PGP behavior ?

The first example you gave was of a nested one-pass signature, and the
second example was a clearsigned message with two signatures after it.

While it is unfortunate that 6.5.8 can't handle them, both of these
constructions are legal in OpenPGP (as per sections 5.4 and 7).

David

Date: Mon, 04 Aug 2003 17:02:07 -0700
Subject: Re: multiple signature packets
From: Jon Callas <[email-masked]>
To: <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 8/4/03 2:41 PM, "[email-masked]" <[email-masked]> wrote:

> are multiple simultaneous signatures acceptable Open PGP behavior ?

I almost said no.

However, the grammar says yes.

   OpenPGP Message :- Encrypted Message | Signed Message |
                      Compressed Message | Literal Message.

   Compressed Message :- Compressed Data Packet.

   Literal Message :- Literal Data Packet.

   ESK :- Public Key Encrypted Session Key Packet |
          Symmetric-Key Encrypted Session Key Packet.

   ESK Sequence :- ESK | ESK Sequence, ESK.

   Encrypted Data :- Symmetrically Encrypted Data Packet |
         Symmetrically Encrypted Integrity Protected Data Packet

   Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data.

   One-Pass Signed Message :- One-Pass Signature Packet,
               OpenPGP Message, Corresponding Signature Packet.

   Signed Message :- Signature Packet, OpenPGP Message |
               One-Pass Signed Message.

    Jon

Date: Mon,  4 Aug 2003 14:41:18 -0700
To: [email-masked]
Cc: 
Subject: multiple signature packets
From: <[email-masked]>
Sender: [email-masked]

have recently received a clearsigned PGP message that was signed
simultaneously with two different PGP keys,
but it caused 6.5.8ckt (build 8) to crash

the double signed messages can easily be generated from gnupg (command
line only),
but (afaik) not from pgp, even from the command line (2.x or 6.x)

have put up examples here:
http://www.angelfire.com/pr/pgpf/dspm.html

have found that the double signed messages were not a problem in pgp
8
under any circumstances,
and were not a problem for 6.5.8 as long as they weren't clearsigned

would like to request confirmation of this from anyone who uses 6.5.8
or 7.x

the double signed message can be very useful in the following specific
situation:

if someone wants to sign and encrypt to two different people, but, for
whatever reason, 
exchanged one key with one recipient and another key with another, and
doesn't want to have the keys uploaded to a server,

then, by double signing, the sender can have the message verified
independently with different keys for different receivers

{sort of cool, actually,   i wish it could be done from pgp ;-)   }

are multiple simultaneous signatures acceptable Open PGP behavior ?

tia,

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Sat, 2 Aug 2003 17:37:53 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: Michael Young <[email-masked]>
Subject: Re: Clarification needed on compressed messages
Mail-Followup-To: [email-masked], Michael Young <[email-masked]>
Sender: [email-masked]

On Sat, Aug 02, 2003 at 04:39:26PM -0400, Michael Young wrote:

> > Come to think, your suggestion of using a compressed data packet to
> > encapsulate could be useful here as well:
> > ENCRYPTED(COMPRESSED(LITERAL+LITERAL)).
> 
> Yes, it's pretty clear that this is legal.  The grammar doesn't
> cover the contents of compressed packets, so the language in
> section 5.6 would seem to govern.  (Curiously, that section
> suggests that COMPRESSED packets might live directly in
> signatures, which is what kicked off this whole discussion.)

Well, I agree with your end result, but I'm not quite sure I agree
with the path you took to get there.  In fact, the grammar *does*
cover the contents of compressed and encrypted packets:

   In addition, decrypting a Symmetrically Encrypted Data Packet or a
   Symmetrically Encrypted Integrity Protected Data Packet as well as
   decompressing a Compressed Data packet must yield a valid OpenPGP
   Message.

Thus, COMPRESSED(LITERAL+LITERAL) is valid only if LITERAL+LITERAL is
valid.

So what this all comes down to is that 5.6 says that
COMPRESSED(LITERAL+LITERAL) is a valid construction.  10.2 says that
LITERAL+LITERAL isn't a valid construction.  Conflict: they can't both
be right.  Repeat as needed for section 5.7 and 5.13 - the problem is
identical.

This is why I have been suggesting a minor change to 10.2 to make it
match 5.6, 5.7 and 5.13:

The current draft says:

 Literal Message :- Literal Data Packet.

I'd like to change that to:

  Literal Message :- Literal Data Packet |
                     Literal Message, Literal Data Packet.

The draft, as it stands now, is internally inconsistent.  I'd like to
fix that.

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Clarification needed on compressed messages
Date: Sat, 2 Aug 2003 16:39:26 -0400
Sender: [email-masked]

"David Shaw" <[email-masked]> writes:
> > > The ONEPASS method can also easily handle such constructions as
> > > ONEPASS+OBJECT+OBJECT+OBJECT+SIG, which SIG+OBJECT cannot.
... [to which I replied, and then he replied again:]
> It's not clear whether it is permitted now or not.
...
> The general question of multiple packets (whether in a one-pass
> signature, compressed data packet, or encrypted data packet) is
> somewhat hazy in the draft.  Speaking only about literal packets for
> now, sections 5.6, 5.7, and 5.13 all say yes (using the plural
> "literal data packets").  Section 10.2 says no.

Those sections refer to sequences inside compressed and the two
flavors of encrypted data packets (respectively), not signatures.
My claim that this is not allowed for signatures was based on the
grammar in 10.2.

...
> Come to think, your suggestion of using a compressed data packet to
> encapsulate could be useful here as well:
> ENCRYPTED(COMPRESSED(LITERAL+LITERAL)).

Yes, it's pretty clear that this is legal.  The grammar doesn't
cover the contents of compressed packets, so the language in
section 5.6 would seem to govern.  (Curiously, that section
suggests that COMPRESSED packets might live directly in
signatures, which is what kicked off this whole discussion.)

I don't really think that sequences of LITERAL packets are a good
thing.  I really don't like them for general archiving, as they don't
carry nearly enough information.  I also see no reason to avoid using
an external archiver (tar, zip, or any of many others).  I was going
to argue against allowing sequences of LITERAL because they complicate
decryption: implementations will likely want to provide a user
interface to control which LITERALs should be processed.  But then,
David pointed out that we already have this problem inside COMPRESSED
packets.  I'd be happy to withdraw that ability, but I'm sure others
will object, so I'll admit defeat in advance.

[Note that one can always encrypt each file separately, and if you're
worried about the public-key encryption cost, your implementation
could reuse the session key (but not IV) during multiple-file
encryption, and recognize that case on decryption.  I'm not advocating
this -- I prefer using a real (external) archiver instead -- but
simply pointing out an option that would be "conservative in what you
generate".]

Date: Fri, 1 Aug 2003 17:00:54 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Location of 'key expiration time' signature subpacket
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Jul 15, 2003 at 01:37:34PM -0400, Edwin Woudt wrote:
> 
> While implementing key expiration, I noticed that the 'key expiration time' 
> signature subpacket (#9) is put in self certification signatures instead of 
> in (self signed) direct key signature.
> 
> Why is that?
> 
> I find it more logical to put it in a direct key signature, as it says 
> nothing about the user id that is self signed. In fact, given multiple user 
> id's, putting it in self certification signatures could even result in 
> conflicting information.

It is legal to put the key expiration in a direct key signature, but
I'm not sure why it isn't regularly done that way.  Possibly because
it was done that way a long time ago and there was no dramatic reason
to change.

In any event, GnuPG does accept a key expiration set from a direct key
signature.  I'm not sure about PGP.

David

Date: Fri, 1 Aug 2003 15:27:29 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: Michael Young <[email-masked]>
Subject: Re: Clarification needed on compressed messages
Mail-Followup-To: [email-masked], Michael Young <[email-masked]>
Sender: [email-masked]

On Fri, Aug 01, 2003 at 01:42:47PM -0400, Michael Young wrote:

> > The ONEPASS method can also easily handle such constructions as
> > ONEPASS+OBJECT+OBJECT+OBJECT+SIG, which SIG+OBJECT cannot.
> 
> Only for non-signature OBJECTs.

True.  There would have to be some encapsulation in that case, perhaps
using your compressed packet suggestion:
ONEPASS+COMPRESSED(SIG)+SIG.

> I'd rather not complicate the rules any further to allow this
> construction.  (It is not permitted now.)

It's not clear whether it is permitted now or not.

The general question of multiple packets (whether in a one-pass
signature, compressed data packet, or encrypted data packet) is
somewhat hazy in the draft.  Speaking only about literal packets for
now, sections 5.6, 5.7, and 5.13 all say yes (using the plural
"literal data packets").  Section 10.2 says no.

I actually requested a clarification whether LITERAL+LITERAL was valid
a few weeks ago: http://www.imc.org/ietf-openpgp/mail-archive/msg05537.html

The reason why I was thinking about LITERAL+LITERAL in the first place
was Jon Callas' comments about OpenPGP as an archival primitive.  It
would be Very Useful to be able to store more than one file into a
single OpenPGP message.  I don't think OpenPGP should be setting out
to replace tar or zip, but it's handy nonetheless.  An archive program
with strong encryption whose results can be de-archived with any
OpenPGP program is compelling.

Note that both PGP and GnuPG already do the right thing with
ENCRYPTED(LITERAL+LITERAL) messages.

Google says Hal Finney argued for this interpretation in 2000:
 http://cert.uni-stuttgart.de/archive/ietf-openpgp/2000/05/msg00032.html

All that said, I think that LITERAL+LITERAL should probably be legal,
but either way, the draft shouldn't say both yes and no.

Come to think, your suggestion of using a compressed data packet to
encapsulate could be useful here as well:
ENCRYPTED(COMPRESSED(LITERAL+LITERAL)).

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Clarification needed on compressed messages
Date: Fri, 1 Aug 2003 13:42:47 -0400
Sender: [email-masked]

"David Shaw" <[email-masked]> writes:
> It's not just signing the COMPRESSED packet.  Using Derek's
> interpretation, you can also do possibly useful things as
> sign-encrypt-sign or encrypt-sign-encrypt a message and have the
> parser handle it automatically.
...
> I suppose the user could create
> LITERAL(SIGN(ENCRYPT(SIGN(LITERAL(x))))) or
> LITERAL(ENCRYPT(SIGN(ENCRYPT(LITERAL(x))))) and sign that, but we're
> getting complex again since the parser shouldn't be looking inside a
> *literal* packet for more OpenPGP data to parse.

I'd use COMPRESSED (with no compression) here instead, which
generally are parsed for other packets.  But, I agree that this
looks messy for SES or ESE applications.

I can live with the special case.  (The fact that the new
implementation conformed to Derek's rule provides further persuasion.)

> I agree, but on the subject of the SIG+LITERAL (or SIG+OPENPGPOBJECT)
> format, I'd actually like to see it deprecated (in the "understand
> this, but please don't generate it" sense).  The ONEPASS signature
> method is far superior, and we can at least start the slow process of
> getting all implementations to use it.

I concur.

> The ONEPASS method can also easily handle such constructions as
> ONEPASS+OBJECT+OBJECT+OBJECT+SIG, which SIG+OBJECT cannot.

Only for non-signature OBJECTs.

I'd rather not complicate the rules any further to allow this
construction.  (It is not permitted now.)

Date: Fri, 1 Aug 2003 12:51:59 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Clarification needed on compressed messages
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Aug 01, 2003 at 11:24:30AM -0400, Michael Young wrote:

> Derek Atkins wrote:
> > I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the
> > SIG should be issued over the COMPRESSED(LITERAL).  The only special
> > case that I know of is SIG+LITERAL, where the SIG is over the data
> > inside the literal and doesn't include the literal packet itself.
> 
> to which "David Shaw" <[email-masked]> responds:
> > This sounds very reasonable to me.  I think a word or two to make that
> > clear in the draft would be helpful: something that indicates that
> 
> I have mixed feelings about Derek's interpretation, but if that's
> the intent, then I agree with David that this must be made clear
> in the draft.  There is definitely a special case here.
> 
> Why mixed feelings?  On the one hand, I don't like special cases.  I
> also find it surprising that one would want to sign the COMPRESSED
> packet.  (It's less to hash, but that hardly seems meaningful.)

It's not just signing the COMPRESSED packet.  Using Derek's
interpretation, you can also do possibly useful things as
sign-encrypt-sign or encrypt-sign-encrypt a message and have the
parser handle it automatically.

The special case (and I agree it is a special case) doesn't bother me
too much.  I agree it would have been nice if the signature had always
been over the complete literal packet, headers and all, but history
ruled otherwise.

It is not terribly complicated to say "always hash the complete
OpenPGP object unless it is a literal packet, in which case hash the
contents".  As you point out, if an implementation wanted to force
signing the complete literal packet, it could just encapsulate the
literal packet into a compressed data packet.

> On the other hand, it is a little disturbing that the LITERAL
> packet headers are ignored, and including them in the signature (by
> way of hashing the entire COMPRESSED packet) would overcome that
> deficiency.
> 
> Note that both of my concerns could be addressed by a different rule
> that has no special case: the signature hash is computed over the
> CONTENTS of the FOLLOWING packet (*not* recursively).  In the original
> PGP case, this would be the contents of the literal packet.  In the
> COMPRESSED(LITERAL(x)) case, it would be the LITERAL(x).  [One could
> use an "uncompressed" COMPRESSED packet to intentionally capture the
> LITERAL header information.]

This seems a bit like simplifying the hashing rule by adding
complexity somewhere else.  For starters, we would lose the current
ability to do encrypt-sign-encrypt (the signature would become
effectively a detached signature over the encrypted data) and
sign-encrypt-sign (the outer signature would become a notary signature
in effect).

I suppose the user could create
LITERAL(SIGN(ENCRYPT(SIGN(LITERAL(x))))) or
LITERAL(ENCRYPT(SIGN(ENCRYPT(LITERAL(x))))) and sign that, but we're
getting complex again since the parser shouldn't be looking inside a
*literal* packet for more OpenPGP data to parse.

> Whatever we do, I expect that
>     ONEPASS COMPRESSED(LITERAL(x)) SIGNATURE
> would be treated the same as
>     OLD-SIG COMPRESSED(LITERAL(x))
> Reasonable?

I agree, but on the subject of the SIG+LITERAL (or SIG+OPENPGPOBJECT)
format, I'd actually like to see it deprecated (in the "understand
this, but please don't generate it" sense).  The ONEPASS signature
method is far superior, and we can at least start the slow process of
getting all implementations to use it.

The ONEPASS method can also easily handle such constructions as
ONEPASS+OBJECT+OBJECT+OBJECT+SIG, which SIG+OBJECT cannot.

> Before passing final judgement, I'd be curious to know what the
> known implementation that uses SIG+COMPRESSED(LITERAL(x)) did
> with the construct?  What did it sign?

It signed COMPRESSED(LITERAL(x)) - the whole packet.  Note also that
PGP can correctly verify such a message, so Derek's interpretation is
supported by working code... though possibly because Derek worked on
the PGP parser at one point. ;)

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Clarification needed on compressed messages
Date: Fri, 1 Aug 2003 11:24:30 -0400
Sender: [email-masked]

Derek Atkins wrote:
> I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the
> SIG should be issued over the COMPRESSED(LITERAL).  The only special
> case that I know of is SIG+LITERAL, where the SIG is over the data
> inside the literal and doesn't include the literal packet itself.

to which "David Shaw" <[email-masked]> responds:
> This sounds very reasonable to me.  I think a word or two to make that
> clear in the draft would be helpful: something that indicates that

I have mixed feelings about Derek's interpretation, but if that's
the intent, then I agree with David that this must be made clear
in the draft.  There is definitely a special case here.

Why mixed feelings?  On the one hand, I don't like special cases.  I
also find it surprising that one would want to sign the COMPRESSED
packet.  (It's less to hash, but that hardly seems meaningful.)
On the other hand, it is a little disturbing that the LITERAL
packet headers are ignored, and including them in the signature (by
way of hashing the entire COMPRESSED packet) would overcome that
deficiency.

Note that both of my concerns could be addressed by a different rule
that has no special case: the signature hash is computed over the
CONTENTS of the FOLLOWING packet (*not* recursively).  In the original
PGP case, this would be the contents of the literal packet.  In the
COMPRESSED(LITERAL(x)) case, it would be the LITERAL(x).  [One could
use an "uncompressed" COMPRESSED packet to intentionally capture the
LITERAL header information.]

Whatever we do, I expect that
    ONEPASS COMPRESSED(LITERAL(x)) SIGNATURE
would be treated the same as
    OLD-SIG COMPRESSED(LITERAL(x))
Reasonable?

Of course, adopting the "be liberal in what you accept" principle, an
implementation *could* do parallel hashes against all of these
possibilities, and report what got signed :-).

Before passing final judgement, I'd be curious to know what the
known implementation that uses SIG+COMPRESSED(LITERAL(x)) did
with the construct?  What did it sign?