I still can't find the comment, so maybe I'm remembering something from an
e-mail exchange or something -- is the statement included somewhere, or
I can't tell from your message which functionality was requested --
that the self-encrypted message be included, or not. Or were you
referring to a request to Microsoft, rather than to the IETF?
In any case, although I value the human rights worker's cause,
and also the whistle blower's, etc., there is another set of values
that also needs to be addressed at the same time, and that is the
need for either the business or the user to be able to recover
encrypted messages, of various but legitimate purposes.
One set of values doesn't necessarily trump the other -- they need
to be debated on their merits.
(Again, apologies if this issue was thrashed to death without my having
seen it go by.)
"Jim Schaad (Exchange)" <jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com>
05/18/99 03:41PM >>>
Finally, somewhere in these documents there is a statement regarding the
advisability of including the content encryption key encrypted in the
originator's public key, but despite rereading the documents multiple
times I can't find that text again. As I recall, the text said that this
SHOULD be done. I would argue that this should be changed to MUST, for I
can't imagine a situation where the originator of an encrypted message
would not want to be able to read his own message, for example in an
outgoing or Sent-Mail queue. He might need to be able to decrypted, and
even retract it in order to resend it with modifications. It would not be
reasonable to rely on the originator to bcc herself to gain this
capability -- it ought to be required by the spec.
[Jim Schaad] This was a requested functionality by a group of people and is
there for a reason. One situation in which this would be the case is human
rights workers sending encrypted mail to the home office. They do not want
the local police to be able to read the mail by stealing the machine and key
or by force.