State-of-the-art way to setup a shared security@ email with hardware-backed keys?

[Daniel Kahn Gillmor]

Hi Simon--

Thanks for the interesting use case.

On Tue 2015-06-09 09:21:08 -0400, Simon Josefsson wrote:
> My current idea is to generate a security at example.com master PGP key and
> keep that offline, and to generate one decryption sub-key, and load that
> onto a couple of OpenPGP Card smartcards.
>
> This would allow authorized people to decrypt emails properly, by using
> the "security team smartcard".  To respond to the emails, they would
> need to use their own smartcard which is a nauisance but workable.

I like this approach for encryption to the team; i think it's definitely
better than the server that does decryption/reencryption.

Another (much weirder) remailer approach that doesn't expose the content
to the remailer itself uses El Gamal keys that have a known relationship
to each other.  The remailer can transform the PKESK in such a way that
it is readable to each peer, without being able to recover the
cleartext.

This is the approach used in PSELS:

   http://www.ncsa.illinois.edu/People/hkhurana/ICICS.pdf

This still has the awkward key distribution step when new members join
the team -- you have to generate their encryption-capable secret key and
get it to them.

But for revocation for user X in this case, you'd just tell the server
to stop PKESK translation for the corresponding offset for user X -- no
certificate update is necessary, and no redistribution to every
remaining team member.


-----------

I note that you're asking here only about the encryption-capable
subkeys, and not signing subkeys -- it's quite possible that your
correspondents would like to be cryptographically confident that the
reply messages come from the team, and not from an imposter.

Interestingly, the case for signing-capable subkeys is not symmetric
with the case for encryption-capable subkeys.  It should be possible for
each of your members to contribute a distinct signing-capable subkey,
and you'd attach all of them to the primary key.

There are two approaches to this:

 a) you could have each person generate their own signing capable
    subkey, create the binding cross-sig with it to the primary key, and
    send the public part + the cross-sig to the team keyring maintainer,
    who would bind it as a subkey and publish the updated cert.

 b) during generation of the per-person encryption-capable subkey, you
    could go ahead and generate a separate signing-capable subkey for
    that user and pre-install it on the smartcard.

the advantages of this individualized signing-subkey scheme (using
either approach above) over a single-shared-signing-subkey are:

 0) you can do individualized revocation without reissuing new
    signing-capable subkeys for everyone else.

 1) you don't have to keep the signing-capable subkey on hand at the
    keyring management site in order to enroll new team members.

 2) when a message coming from the team is signed, you can identify
    which team member made the signature.


hth,

        --dkg