I don't know if this was discussed, but for me this is not a question of
encryption, but of trust. If you don't like someone else to forward your
messages, send them on paper. With a company logo, a watermark and a unique
number.
It is the risc of living :)
-Leon.
-----Original Message-----
From: owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openpgp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Marc
Mutz
Sent: 09 April 2002 19:47
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-----