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
