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

[Simon Josefsson]

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
> 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 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.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20150616/c1495eab/attachment.sig>