[Top] [All Lists]

Re: Bug#40394: forwarding an encrypted PGP message is useless

2002-04-09 13:33:31

From: John Dlugosz


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

Marc Mutz <mutz(_at_)kde(_dot_)org> on 04-09-2002 12:47:01 PM

Sent by:  owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org

To:   kmail(_at_)kde(_dot_)org
cc:   ietf-822(_at_)imc(_dot_)org, ietf-openpgp(_at_)imc(_dot_)org
Subject:  Re: Bug#40394: forwarding an encrypted PGP message is useless

Hash: SHA1

[ OK, I put this where it belongs: this touches OpenPGP and Internet
 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

What if, in a mail user agent, the user wants to forward an encrypted
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?


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
better delegate the resposibility for this action to the user itself.

There is still the question, what should be the default way. Another
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 (

   "Some level of support for generating and processing nested and
annotated PEM messages (for forwarding purposes) is to be provided, and
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)"

    "The problem of intent that as expressed in [MALFWD] is beyond the
    control of S/MIME protocol or its implementers.  The use of the
    signatures and encryption is correctly in the hands of the user.
However, the intended recipients attribute offers a mechanism to reduce
likelihood of undetected malicious forwarding."

4. The mozilla team has the same problem:

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

KMail Developers mailing list

- --
Marc Mutz <mutz(_at_)kde(_dot_)org>
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


<Prev in Thread] Current Thread [Next in Thread>