On Sun, 17 Oct I wrote:
> Why not allow/define the use of MIME multipart messages for such applications?
> That is, rather than using the SUBMIT attribute as above to retreive a
> customized version of the form, why not include named sections of a document
> section and define EXPAND/COLLAPSE attributes to control display? For instance
[ rest of message not included ]
I realized that we could use the same technique to store and retrieve
encrypted documents as well. For instance,
MIME-Version: 1.0
Content-Type: multipart/related;
boundary=unique-boundary-1
--unique-boundary-1
Content-Type: application/html-form
[some stuff here]
<INPUT NAME="key" TYPE=text ENCRYPT=@secret SUBMIT>
[ possibly more stuff here ]
--unique-boundary-1
[ whatever MIME headers are appropriate for an encrypted message ]
Content-Id: secret
[ encrypted text of message goes here ]
--unique-boundary-1--
One could hit a button on the client to pull in the above template, then type
in a key and the secret text. The client would encrypt the secret portion
using the given key, and then submit it to the server.
Later, when the document is downloaded, the secret portion will be unreadable
until the appropriate key is typed in.
This method is nice since the key never even needs to leave the client
machine. The server doesn't even know how to decrypt the secret part(s).
Of course, you could share the key with others in separate transmissions and
thus allow them to view the secret message.
Chris
--------------------------------------------------------------------------------
Christopher McRae mail: mcrae@ckm.ucsf.edu
UCSF Center for Knowledge Management at&t: 415/476-3577
530 Parnassus Avenue, Box 0840 fax: 415/476-4653
San Francisco, California 94143