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

[Ximin Luo]

On 24/09/14 16:39, David Shaw wrote:
> On Sep 24, 2014, at 6:17 AM, Ximin Luo <infinity0 at pwned.gg> wrote:
> 
>> 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.
> 
> [..]
> 
>> What problems do you see?
> 
> When certifying someone's key, you are signing the combination of the primary key and the user ID in question.  In addition to the usual checking of IDs and fingerprints, It is reasonable [1] to send a challenge token to the email address (if there is one) in the user ID.  Responding to this challenge with a signed message, quoting the token, proves that the email address reaches someone who has access to the private key that matches the primary key you are signing [2].
> 
> If the primary key can't sign, they can't respond to this challenge.  A signing subkey isn't sufficient here, as it can be attached to any number of keys, so a signature from it does not prove access to the primary key.  Backsigs don't help this problem since backsigs only protect against a "stolen" subkey - not against one that is intentionally attached to multiple primary keys.
> 

Why is a signature not enough? Cross-certification is typically considered fine for validation logic. It is not the signature by the subkey that "proves access to the primary key", but the certification of the subkey from the primary key.

When you certify a subkey, you mean "I and only I have access to the private component". So a signature from a subkey can be treated as from the primary key owner. IMO, this should actually be formalised into a byte in a packet or something; perhaps it is already. Now, the flaw you mentioned, is valid only if you think some people willingly give their signature keys to other people.

If you feel that people don't honour this contract for signature keys, perhaps you have more faith in this contract for encryption keys? You can send a nonce encrypted to their subkey, and wait for the decrypted one to come back.

But yes, if OpenPGP does not formalise a meaning for certifications, that is a design flaw, not a problem with my proposal per se. Another way to solve it would be to allow the certify key to be used in formal "proof of possession" protocols such as what you described. But allowing the certify key to sign arbitrary pieces of application-level content is asking for trouble, and not a clean architecture, IMO.

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/425972a4/attachment-0001.sig>