secure sign & encrypt

[Jukka Holappa]

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| BUT encryption COULD be useful for the recipient, if it was made clear
| that the message was sent encrypted in the first place. Of course the
| recipient still needs to trust the sender/signer of the message to have
| handled the contained information confidentially.
|
|
| In the end it all boils down that people (or, at least I) automatically
| put different meanings to a message, depending on the source of the
| message. A message in the newspaper is read differently than the same
| message in a letter. In the same way, an unencrypted e-mail message may
| be interpreted differently from the same message that comes encrypted -
| it tells something about the sender's intention.
|
|
|
| Concerning RFC compliance:
| from rfc2440, section 5.2.3.1:
| ======
|      An implementation SHOULD ignore any subpacket of a type that it
|      does not recognize.
| ======
|
| So, adding a hashed subpacket with a subpacket type of, say, 110
| (explicitely reserved for private use) for the purpose of announcing the
| 'intended encryption key' on signed+encrypted messages is fully within
| the scope of the rfc and SHOULD not break any openPGP compliant
| implementations.
|
| Displaying extra warnings on decrypting messages without this special
| subpacket should of course not be the default while this is not in
| widespread use. Displaying extra warnings in case there is a mismatch
| between the intended and the real encryption key can probably safely be
| enabled per default.

Very true and an excellent idea.

It would protect fairly well from sending someone else's signed messages
~ with perhaps malicuous (unsigned) attachments, only if programs warn
about missing subkey in encrypted message - and this is not going to be
a big warning in real life since there is no support for this key.

If Cecilia gets any Alices messages and is able to decrypt/copy it, he
can re-encrypt it without this subkey and send it to Bob in any other
contexts. It is not safer at all without this paranoid option which
tells that message was not sent to him originally.

Perhaps signatures would work better.. that they contain information to
who that particular message was sent. Perhaps the message itself ;)

Email programs should also warn when receiving unsigned attachments
along with encrypted/signed messages since there is no way knowing these
attachments are really from that person.


|
| Also - although I'm in no way involved with writing RFCs - the RFC
| documents have been known to be revised and extended from time to time.

Someone has to do it (not me either) :)

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87PYxYYWM2XTSwX0RAnktAJ4tX+HDuD7wrGBtMSSHK0BTBr/KHwCeLRw2
Y3Vxy/O9BzFffgXl5AoWbEM=
=WB+0
-----END PGP SIGNATURE-----