GPG support in Mahogany

[Janusz A. Urbanowiz]

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

On Tue, Dec 10, 2002 at 06:38:06PM +0100, Xavier Nodet wrote:
> > It is bad on the grounds of OpenPGP default threat model.
> 
> Could you point me to some document that describes this threat model,
> please? I know I have much more to read than I already did.

It is described in the two-part documentation to the original PGP 2.
 
> > My question is: what do you want to prove (or prevent) with  the
> > sign-encrypt-sign model? What do you do with messages that look like you
> > aren't the designated recipient, or worse you are visibly not their
> > designated recipient. Throw away them for they are invalid?
> 
> Warn the user. I, as a developper of a mail client, do not want to
> decide anything. But I do want to provide some information when it is
> available.
> 
> And please remember that I'm only considering the decrypt/verify
> process. My objective is not at all to setup a way to send some
> encrypted information, but to receive it in such a way that a user will
> be warned when this is needed.
            ~~~~~~~~~~~~~~~~~~~
My point is that you (your mail client) are trying to do a thing, that
you won't know is right or wrong. Sometimes the originator wants to spread
the information, sometimes not. Sometimes the man in the middle is doing the
forward with good intent, sometimes, not. How do you (your mail client) warn
a user 'when this is needed'?

How you will detect a difference when someone reencrypts the message to me,
and the originator encrypts the message to me but won't sign it later
(nobody does this, as I see as long as I use PGP)?

OpenPGP defines a way to mark the message that its circulation should be
limited. It is called 'for your eyes only'.

> >> I'm speaking about the destinator decrypting first, then re-encrypting
> >> for a third person.
> 
> > You want to detect it, prevent it, prove it or what?
> 
> I want to detect it.

But why? Why you worry about this, but you don't worry that someone's
machine in the message path isn't compromised?

> I want to provide as much information as possible to the user, who is
> not necessarily a crypto-expert. And I am just beginning to use GPG for
> myself, just enough to understand that doing cryptography the right way
> is not necessarily easy.

- From the standpoint of usability it is a very bad thing to flood end user 
with lots of uninteligible information. You yourself said that your user is
no cryptography expert. He won't know what your mail client is talking
about.

It is very easy to write a software that will present a lots of information
to the user and make him decide. But the average user doesn't like this. He 
ehas say 1000 messages to deal - a day and don't want to have to deal with a
single one more that is necessarily needed.

Since your first mail I try to devise a larger scale threat model that
involves checking circulation paths on the receiver side. I can't. I can do
this for limiting circulation on sender's side. In PGP this is done via
'eyes only', elsewhere it is called DRM.
 
> Maybe I am completely off here. Maybe the sign-and-encrypt feature of
> GPG is fundamentally different than first signing, then encrypting. I'd
> be glad to learn that.

It is different in a way that sign+encrypt message can be 'opened'
(deciphered and signature verified) in one decryption pass.

> > (your approach looks a lot similar to one 'PGP vulnerability' that
> > gets widly announced every two years or so).
> 
> Do you consider <http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.ps>
> to be part of those 'wildly announces'?

A typo. It should say 'widely'. 

Yes, I consider this paper to be bogus. I don't consider the problem to be
bogus, but I think that PGP and mail clients should not be doing lawyers'
jobs - expressing important information in a way so both the originator
and recipient can't be contextually mistook for someone else.

We can't solve a social problem with technology.

If you want to approach the problem, make a good implementation for 'for
your eyes' option for both sending and receiving messages. Include From and
To headers in a message when signing it. Check the included headers when 
verifying the signature.

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

iQIVAwUBPfcgDw/uVbVGOZE4AQKFVRAAgXS1TBbduIdaAQGc5pgqoqLLZQyPxeeP
a5tgVIqTzd8nAh0goT7Ghd0C1rqYQx4e0TfKUquSslfq3yLYWspx3aA3+sWuagFY
eHVvTUrd9+F9n2zwwhgsv8gxEqtbtBrv4OEjK+yhfwTkQQXjpyRdpL5XDQUad6Zn
Wz1CfuxL9dhYJhVPiTw8CJPnqsNsYY+V0eNAGW7QmvYRVCsAqEwNKqHlqugJe3cC
C74kApdamOdY/fhnskMEuxb/+H5OEqaJPRmlLxE57ISdFRvkK7/AyOvodoj8NuOM
wOdIXUjTi305TSHn4k3uzLoh7Qbqp+sva/nPEA+K/WUycTzqyeLm2trHQptjMpR0
XikkFmgTGKZCkUlmq/eSZ8wpxni9ph5RAw2wQ6qAo+9FSgBzlOvE47MRg3ckw9d0
ONE0nngwGhtylcc01XdharIOYlsuiZoSr+njl8H2QanuCD7nPSnN/U95XfDGthpE
xtvAqAduGq/lkS78yLfpidkkxyVB9JOE1+8QoqlFtAPUpbqQJxLe/ghCrsEKxxUO
nM0vUwArCV8xIl1uHpKTVKWAQ7gHbHXA9K/1OMNX6q4TqlvYvUjWdrgKCPn/A7r+
/5gw2BfY6UIXD9/lnWualC4JyN++ybNHsC+kzj8Ts6xQl7Sz6J/tHwVCsSBH/1fv
C0Pr3TlT84c=
=jGLZ
-----END PGP SIGNATURE-----