Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > 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.
Hi. Thanks for confirmation. I'm going to write this up and implement it in the organization I had in mind. > 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. Is this implemented? I wan't to use standard stuff, anything experimental is likely to be difficult to deploy. Further, having an online remailer creates an attack surface that is costly to secure. > 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. I don't think key distribution is a significant problem for me -- I could generate the decryption keys for the members of the security team. > 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. Revocation is possible in my scheme -- just revoke the decryption key, create a new decryption sub-key and distribute it to all members that should have it. Perhaps not scalable to a large team, but quite feasible on my level of scale (<10 people). > 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. My plan was that people responding would sign their emails using their personal keys. While a shared signing key is possible, I'm not sure I see what the advantage is? I think I would prefer making communication going direct and end-to-end instead of continuing using the security@ address all the time. > 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. Right, that could be interesting. > 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. Sounds like figuring out the work-flow here will take some time. > 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. Yeah. > 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. Is there really any advantage in this scheme compared to all members having two smartcards -- one contains their personal user@ keys and one contains the security@ decryption key? The only point I see with your scheme(s) is that people receiving responses will see that they are signed by secur...@example.com but I don't see what that improves over having see the response being signed by u...@example.com. The latter invites direct end-to-end secure communication, bypassing the security@ alias if needed. I think my use-case is to allow people to REACH us with encrypted emails using a well-established alias like secur...@example.com, but not necessarily have the secur...@example.com key SIGN outgoing emails. /Simon
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
