State-of-the-art way to setup a shared security@ email with hardware-backed keys?
simon at josefsson.org
Tue Jun 16 10:28:34 CEST 2015
Daniel Kahn Gillmor <dkg at 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 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.
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
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.
> 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 security at example.com but I
don't see what that improves over having see the response being signed
by user at 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 security at example.com, but not
necessarily have the security at example.com key SIGN outgoing emails.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 472 bytes
Desc: not available
More information about the Gnupg-users