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

[David Shaw]

On Sep 24, 2014, at 2:01 PM, Ximin Luo <infinity0 at pwned.gg> wrote:

> On 24/09/14 16:39, David Shaw wrote:
>> 
>> 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.

That's correct, but it's not sufficient, because it does not prove access to a *particular* primary key.  Just to *a* primary key.  It's perfectly valid in OpenPGP for a given subkey to be owned by multiple primaries (in the sense that there is nothing in RFC-4880 that says you shouldn't do it, and nothing in the crypto that prevents it).  I won't argue if this is a good or bad design, or if it should (or even could) be changed at this point, but it is the design we have today.

> When you certify a subkey, you mean "I and only I have access to the private component".

It proves only "I have access to the private component(s)".  It proves you have access to the primary private key and subkey private key because you issued signatures from both of them as part of the certification.  It states nothing provable about any other potential people having access to the private keys.

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

This has the same issue as a signing subkey.  The thing you sign when making a certification is the primary key plus user ID.  If you're basing the decision to sign on something other than the primary key plus user ID, you're basing that decision on something that may or may not be cryptographically tied to the thing you are signing.

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

That would be fine as well, but that doesn't exist in OpenPGP today.  It's a bit like saying "go ahead and make a signature just for this case" though.

David