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

[Daniel Kahn Gillmor]

On 09/24/2014 03:28 PM, David Shaw wrote:
> On Sep 24, 2014, at 2:01 PM, Ximin Luo <infinity0 at pwned.gg> wrote:
>> > 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.

fwiw, using encryption-capable subkeys in this way is actually pretty
common practice in my experience.  `caff` in particular (from the
`signing-party` package in debian) does this.  And encryption-capable
subkeys don't even have crossigs (indeed, some can't, if they're used in
algorithms that are encryption-only).

But i do recognize David's concern about how to prove control over the
primary key rather than just a subkey.

One approach to resolving David's concern would be to introduce a new
sigtype (we're not close to running out of them) that is "primary key
challenge-response certification".

This would give the possibility of David's proof-of-control round-trip
without encouraging most users to sign their daily messages with the
same key they use for OpenPGP certification.

It might be tricky to define such a sigclass cleanly, though.  You
certainly don't want to create a system that is effectively a
signing-oracle for the primary key.

	--dkg

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