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 secur...@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
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
