Managing Subkeys for Professional and Personal UIDs

[Daniel Kahn Gillmor]

On 05/02/2014 09:32 PM, Robert J. Hansen wrote:
>> 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.
> 
> Imagine this: you're a purchasing agent at Yoyodyne.  You've established
> WoT connections with all your providers using a certificate whose only
> UID is:
> 
> 	"Daniel Kahn Gillmor (sales orders only) <dkg at yoyodyne.com>"
> 
> Now you go out on vacation for three weeks and on day four a sudden
> business need arises in which a sales order must be filed.

This business use case could be better handled by ensuring that whoever
is filling my shoes for three weeks has their own key and has a
relationship with the customers/clients/vendors that they need to work
with.  Cryptography aside, that's a just a better and more honest way to
do business, rather than trying to pretend i'm not actually on vacation.

So i mean, sure, i can definitely imagine a company doing it the way you
describe.  I just don't think it's a good business practice.

OTOH, if the key was a role key (that is, if the User ID on the key was
just "Yoyodyne Sales <sales at yoyodyne.com>") then it's no longer a
personal key and sharing the associated signing or certifying key with
other people who fill that role wouldn't be unreasonable.

Tangentially: there are still cleverer ways to manage role keys like
that, if you want to provide accountability and smoother transitions --
for example, the role key's certifying public key could be managed
strictly by the sysadmin, and she could add separate signing subkeys for
each member of the Yoyodyne sales force.  Then if a message is signed,
you know which of your team actually signed it.  And if someone leaves
the team, you can just revoke their signing subkey, (if the role key had
an encryption-capable subkey, though, you'd still need to rotate that
subkey -- revoke the old subkey, create and distribute a new subkey --
since that subkey would be shared by all members of the team in a role
key scenario).

	--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/7e527d0a/attachment.sig>