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 <mutz(_at_)kde(_dot_)org>@mail.imc.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
-----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
kmail(_at_)mail(_dot_)kde(_dot_)org
http://mail.kde.org/mailman/listinfo/kmail
- --
Marc Mutz <mutz(_at_)kde(_dot_)org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8sykV3oWD+L2/6DgRAqdGAJwNcRmGWoJScgyldtF8oRuZdkhJgwCgqSHS
EVIhVDaYSbaBNwblKUbAu9Q=
=Krt0
-----END PGP SIGNATURE-----