group key?

[Neil Williams]

On Monday 26 April 2004 7:04, Jerry Windrel wrote:

To clarify: Personally, I don't see the point of a group key for a mailing 
list - it's generally unworkable, more than a little pointless and 
unnecessarily exclusive. Lists are meant to be open and openly archived. 
However, the question of a group key is wider than just a list. There have 
been discussions about corporate keys on this list before, a group key is a 
similar idea.

> imagining you mean is that a key pair is generated and assosicated, not
> with a person as is customery, but rather with a group.  The private key
> (and any passphrase) would then be distributed to all members of the group
> (which would be quite an unorthodox practice, in terms of PGP).  Then, all
> messages to the group would be encrypted to that "group key".

Or, more simply, a single database would keep a tally of current keyids and 
encrypt all messages to a vast list of keys using the same session key. Not 
surprising that this doesn't sound good. At least it removes the need for a 
distributed private key AND it allows for user additions and removals. You 
would be able to exclude old keys from decrypting old messages and allow new 
keys to decrypt old messages, however, re-encrypting archived messages to the 
amended group would be too burdensome, (being recursive and all). 

This would, in effect, simply be a group of keys (or key group), not a group 
key. GnuPG can already do this and has group functionality in place. I don't 
think the group was ever considered to be of sufficient size for an entire 
list/company!

> The ramifications of this would be: the group private key would be only as
> secure as the weakest practices of any of the group members; you would be

As has been discussed elsewhere on this list today, encrypting to more than 
one person/key always renders the entire chain vulnerable to the weakest link 
- it has always been this way, no matter what tool is used to create any 
chain.

> able to add but not remove members (unless you generated a new group key).
>
> Please clarify and correct as necessary

The problems and limitations of a group key are not technological but 
practical and social. It echoes other comments about using a key on a server 
to sign or decrypt messages automatically - the passphrase is either entirely 
absent or stored in a file on the server. Neither are particularly appealing 
because you substitute the security of GnuPG for the security of the server 
alone instead of adding. (If anyone can crack the server, they can obtain the 
private key + passphrase, if any.)

More feasible were ideas around corporate keys that had a single main key that 
had a private key only accessible to a named high-up bod. That key would sign 
subordinate keys and revoke signatures if the subordinate left the company. 
At no time would more than one individual ever have access to more than one 
private key in the corporate keyring and no one private key would ever 
available to more than one person. This is workable but is it worthwhile? The 
problem remains of controlling the signatures and what happens when the 
underlings get together and sign each other's keys thereby becoming trusted 
without the boss' signature? That's a procedural / management / policy issue. 
It also didn't address the issue of encrypting to everyone, just trusting the 
signatures / keys. Encryption would still use some form of key group - which 
leaves it right back at square 1.


-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20040426/38d6dd09/attachment.bin