Multiple Subkeys/UIDs

[David Shaw]

On Mon, Mar 21, 2005 at 04:25:07PM -0600, Grimes, Dean wrote:
> >You mention that all data enters the central location encrypted, but is
> then decrypted ("for processing") and then re-encrypted.
> 
> The processing script would most likely decrypt the file piping the output
> into the processing program. Once processing is complete, the script would
> then mv/cp the already encrypted file to it's storage location. There would
> be no need to re-encrypt the file.
> 
> >Also: once a file is archived, is it still writable?  That is, is it
> >permissible to go back and edit this file to remove a particular key
> >from it?
> 
> No. The file would not be editable nor would any other process write to the
> file. The only activity allowed on the file would be to decrypt for reading
> purposes in a designated work area to be determined and set forth in the
> policy.

That makes things very difficult, unfortunately.  Given those
restrictions, I think your best bet is to have some sort of "check
out" process when someone needs to read a file.  At that point, the
file is decrypted by the master key and then re-encrypted to that
persons key.  Your local policy and setup will need to be written in
such a way that this person cannot make their own copy of the file
while reading it.

However, given that restriction (that the user has no way to make
their own copy), I wonder what the point is in re-encrypting.  Why not
decrypt as part of the check-out and give it to them in the clear?

David