Using signing in a group environment

[Evan Prodromou]

>>>>> "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 support@your.company,
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 <alice@your.company>
            Your Company Support Technician <support@your.company>

        Bob <bob@your.company>
            Your Company Support Technician <support@your.company>

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 <alice@your.company>
            Your Company Support Technician <support@your.company>
            SIG: Your Company Tech Support Team <team@your.company>

        Bob <bob@your.company>
            Your Company Support Technician <support@your.company>
            SIG: Your Company Tech Support Team <team@your.company>

This is a way of saying, "Our company certifies Bob as a technical
support rep. If you get email from support@your.company, 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 support@your.company ID:

        Alice <alice@your.company>
            Your Company Support Technician <support@your.company>
            REV: Your Company Tech Support Team <team@your.company>
        
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 support@your.company 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
evan@prodromou.san-francisco.ca.us