Multiple Subkeys/UIDs

[Grimes, Dean]

>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.

I like the idea of a check out system. This would eliminate the need to
create individual subkeys altogether. I could even use CVS as the
warehousing system. This accomplishes two goals: 1. Check in/out procedures
and 2. Logging all activity for checked out files.

>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?

I agree. There is no need to re-encrypt the files. These are trusted
employees who have the authority to view the data. I'm not too worried that
they wouldn't adhere to company policy.

However, just to be sure: There is no way to create multiple subkeys with
individual pass phrases that have the ability to decrypt messages/files
encrypted by a master key. Is this correct?

Thanks,
Dean

-----Original Message-----
From: gnupg-users-bounces at gnupg.org
[mailto:gnupg-users-bounces at gnupg.org]On Behalf Of David Shaw
Sent: Monday, March 21, 2005 4:36 PM
To: gnupg-users at gnupg.org
Subject: Re: Multiple Subkeys/UIDs


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

_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users