Steve Crocker and Rhys started a discussion about extending PEM-MIME
constructs and functionality beyond the interactive user - mail transport
focused scope of PEM (as is). Rhys suggested extended uses most
interestingly involve signed and/or encrypted storage, protecting against a
hacked system (at a later time than storage/receipt time), and for enabling
restricted discussions within the mail system between local users. Steve
brings up policy driven (automatic & outside of user control?) protection of
'external' mail via non-user requested use of PEM mechanisms.
I like the functionalities. Both start to raise a lot of questions I don't
remember being discussed for the current PEM.
My first question though is if you encrypt with the public key and the mail
system, hopefully, doesn't have the secret key around all of the time, how
do you get the system to do anything with the mail unless the user is
on-line and supplies access to the key?
I can think of a couple of additional and somewhat related things to explore
as extended PEM uses. In general they strain my understanding of the
extensibilities of PEM 'as-is'.;
- Signing or encrypting not just spooled but stored or saved mail.
- Long... term storage of signed or encrypted mail.
- Recoverable archives or backups of some or all encrypted or signed mail.
- Updating spooled or stored mail signatures or seals as new certificates
or revocations are received.
- Forwarding protected mail to a portable or other remote user agent where
either the remote host or the communications channel inbetween is insecure
or untrustworthy (,and may be only intermittently connected).
- Portable or remote hosts with user agents that share or divide mail
folders, such as duplicated inboxes, that need updating and alignment.
- The much maligned, but much used, secretaries privileges to receive,
receipt, forward, and/or answer someone elses mail when delegated.
- The delay (mucho processing time) needed when changing certificates on
everything stored that's analogous to decrypting/reencrypting disks or
directories when an encryption password is changed.
- And of course the combinations of the above.
Perhaps none of these requires anything new. Perhaps nobody wants to work
on them. If they do though need agreements about or extensions to PEM
'as-is' then is attacking a short prioritized list best or is it worth
looking at a more exhaustive list to seek common functionality requirements.
And yes, I know that I haven't really listed functionality requirement.
This is just a quick idea list of scenarios for mail usages where I don't
understand how they are enabled by present PEM. Most of these are things
that I have or want in my current 'unsecure' mail.
Rich Harris, M/S 7L-15 rharris(_at_)atc(_dot_)boeing(_dot_)com
Boeing Computer Services/ Computing Security Technology
PO Box 24346 / Seattle WA 98124
phone 206-865-4922 fax 206-865-6903
----------
From: pem-dev-request
To: Stephen D Crocker
Cc: pem-dev
Subject: Re: Enveloping messages in mail spools
Date: Tuesday, May 03, 1994 11:53AM
On Mon, 2 May 1994, Stephen D Crocker wrote:
Not a bad idea. We've done some work on the dual: encrypt everything
headed out as it passes the gateway. It's interesting to see the
variations that develop from different assumptions about whether the
local or external environment is more hazardous.
It's also interesting to note that a high school may be very hesitant to
install a package which will encrypt all of the student's messages so the
teachers can't tell if the students are simply chatting, or swapping
assignment solutions. :-) Six in one hand, half a dozen in the other.
I don't think there's any inherent conflict. The agent which encrypts
can choose not to sign it. If it signs the message, it should say
it's the incoming gateway. Our implementation of MIME-PEM will have a
mode for retaining annotating the decrypted, signature-verified
message with the names of the relevant parties. The annotations will
distinguish between unsigned messages and signed messages so as to
prevent possible spoofs.
Sounds pretty much what I wanted. My question was mainly intended to see
if there is a documented way to automatically identify any locally-added
privacy/signature enveloping so that when a message is saved, forwarded,
etc, the extra stuff is removed, and the original message is used instead.
It's a question of knowing when to stop so that remotely-added enveloping
is not removed unless the user really wants it removed.
Cheers,
Rhys.