offline primary keys [was: Re: Why 2.1 is delayed for so long]

[Ximin Luo]

On 24/09/14 06:16, David Shaw wrote:
> On Sep 23, 2014, at 5:51 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
>> As for Ximin's goals: I think the transition process could look like this:
>>
>> 0) add a signing-capable subkey
>> 1) remove signing-capability from primary key
>> 2) move primary key offline
> 
> I understand the desire for steps 0 and 2, but I do not see the need for step 1. You can do 0 and 2 without doing 1.  Can you explain why you want 1?
> 
> I see actual problems for a primary key that can't issue signatures as well as certifications.
> 

As I mentioned in the other email, the need for step 1 is long-term and architectural - it's a much cleaner data scheme, and separates independent concerns appropriately. You can update key metadata separately.

For example, if you have a CS master key and an S subkey, a signing program might "pick the last key to expire" as logic to select which key to use. But you might want to update the expiry date for your master key, to be longer than your signing key. Different programs might implement different logic. It would be more predictable, to have only one signing key (that is separate).

What problems do you see?

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140924/4b3d2d0c/attachment.sig>