Using signing in a group environment

Evan Prodromou
Thu May 17 22:06:01 2001

>>>>> "MHW" == Mark H Wood <mwood@IUPUI.Edu> writes:
>> I would like to create a secret key for our group here at work >> so that we can send out signed email. What would be the best >> way of doing this so that when a group member leaves, they >> would not be able to continue to send signed email? MHW> Well, unless there is some compelling reason to share a MHW> single key, the *best* way is to give each member a separate MHW> key. If a member leaves, he can continue to send signed MHW> email, but since you know it is from a nonmember (the MHW> signature *proves* that) you can ignore it. If this is not MHW> sufficient, explaining your need more thoroughly may elicit a MHW> better answer. One use for group-signed stuff is, say, for a technical support team. If a number of people answer the email for, it'd be a good policy to have the same address on all their outgoing mail. One way to do this is to have each tech support person have their own key. Like, Alice and Bob both have keys, like this: Alice <> Your Company Support Technician <> Bob <> Your Company Support Technician <> Each key also has an extra ID for the support email. Note that although the IDs are the same, the keys are still different. Finally, there could be a master root key used to identify the organization. It'd be used to sign each of the technician IDs: Alice <> Your Company Support Technician <> SIG: Your Company Tech Support Team <> Bob <> Your Company Support Technician <> SIG: Your Company Tech Support Team <> This is a way of saying, "Our company certifies Bob as a technical support rep. If you get email from, and it's signed with Bob's key, well, that's a real support email." It's EXTREMELY important to protect this master root key, and keep it in the hands of a very responsible person. [As a side note, while there are a lot of docs on the Web on how to manage a personal key, I haven't seen a lot on how to deal with a root key, especially for sensitive stuff. Links, anyone?] If Alice leaves the company, the company could revoke the signature on her ID: Alice <> Your Company Support Technician <> REV: Your Company Tech Support Team <> Revoked signatures mean, "Our company no longer certifies Alice as a support rep. If you get mail from her, with that as her signature, don't come running to us." The revokation would need to be published to a number of key servers to be useful. All that said, this is a pretty sophisticated set up. Unless you're doing support for, say, PGP B-) or some other product with a fairly fanatical cryptophreak clientele, I can't see it being much use. Most people don't check email signatures, keep keyrings up to date, or, frankly, even know that From: lines can be spoofed. One more thing: this setup would preclude having customers SEND encrypted email to the address, since it would be encrypted to any of a number of public keys with the same email address. But if outbound signing is the important part, and not inbound encryption, I think the above scheme would work. ~ESP -- Evan Prodromou