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

From: <[email-masked]>
Date: Fri, 22 Aug 2003 07:42:49 -0700

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: Ian Grigg <[email-masked]>
Date: Fri, 22 Aug 2003 14:01:30 -0400

> 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

---

From: Ian Brown <[email-masked]>
Date: Sat, 23 Aug 2003 10:35:45 +0100

> 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

---

From: Werner Koch <[email-masked]>
Date: Sat, 23 Aug 2003 17:06:58 +0200

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