Managing Subkeys for Professional and Personal UIDs

Daniel Kahn Gillmor dkg at fifthhorseman.net
Sat May 3 00:18:38 CEST 2014


On 05/02/2014 06:03 PM, Faramir wrote:
> El 28-04-2014 14:35, Daniel Kahn Gillmor escribió:
> ...
>> But I also want to point out that some employers may have a
>> legitimate need (even a legal compulsion) to be able to decrypt
>> communications coming to your work-related e-mail.  One reasonable
>> solution to this is to provide them an escrowed copy of your
>> encryption-capable subkey, perhaps locked in a way that you would
>> need to be informed (or perhaps deceased?) that they were making
>> use of the escrow.
> 
>> However, i see *no* legitimate need for any employer to be able to
>> forge data signatures or identity certifications from your
>> work-related key. escrow only make sense for encryption-capable
>> keys in limited contexts.
> 
>   What about to adding the boss key to the keys the message is
> encrypted to?

You're saying instead of doing escrow of encryption keys?

The only problem with that approach is that you have no control over the
people who are encrypting messages and sending them to you.  So you're
bound to get some messages that the Boss wouldn't be able to decrypt later.

It should be *possible* with OpenPGP to prepend a new PK-ESK packet on
any received message, but i know of no tools that do that.  also, once
you leave the organization, messages could still come in encrypted to
your key by people who want to talk to the org, but don't know that
you've left.  in that case, the organization couldn't get those
messages.  (in some cases, this may be the Right Thing; in other
business relationships, that might be really problematic)

I'm not saying that all employers *should* do escrow of all their
employees' encrpytion-capable keys.  In fact, i think the majority of
employer/employee relationships should probably never require any kind
of key escrow.  But there are some relationships where key escrow makes
sense, and i wanted to clarify that it *only* makes sense for
encryption-capable keys, not personal signing or authentication keys.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140502/662633f1/attachment.sig>


More information about the Gnupg-users mailing list