Keybase asks me to sign my updated public key for no apparent reason

[a3nm]

Hello,

I would like to update my GPG public key on keybase, to replace the current key (which is expired) with a more recent version of the same key. To do this, I can select "Update my key (I edited it elsewhere)", and then paste the new key. However, the Keybase website now asks me "How would you like to sign your updated public key? You'll do this using your private key." and gives me several options to do this.

I don't understand why it is necessary for me to perform a new signature when uploading a new version of my existing key. As far as I understand, only someone with my private key can create a new version of the public key, and the updated public key already carries the self-signature made by GPG when editing the key.

Hence, in my opinion it is a problem that additional user action is required when uploading a new version of an existing key. In fact, Keybase should be able to automatically update its public keys from keyservers without any user action.

If I don't properly understand what is going on, and if this signature is actually required for a good reason, the prompt "How would you like to sign your updated public key?" should give more information about why this action is needed.

[maxtaco]

We ask for two-way signatures between any two signing keys, much like GPG itself does with signing subkeys. This precaution prevents someone else from claiming your public key as their own, which in turn would allow them to take credit for something you had published. You can see an example here in the reverse_sig field.

[a3nm]

Thanks for your explanations! I understand that you require a signature initially, the first time a key is uploaded, to guarantee that it is indeed the owner of the key who is claiming that key as their own on Keybase; but I still don't understand why a signature is required for subsequent versions of the same key?

-- Antoine Amarilli Sent from a mobile device, please excuse brevity and top-posting.

On July 28, 2017 2:40:48 PM GMT+02:00, Maxwell Krohn notifications@github.com wrote:

We ask for two-way signatures between any two signing keys, much like GPG itself does with signing subkeys. This precaution prevents someone else from claiming your public key as their own, which in turn would allow them to take credit for something you had published. You can see an example here in the reverse_sig field.

[maxtaco]

We're pegging the full contents of the user's GPG key so that the server later can't lie by dropping subpackets. In reality this is a big security improvement over traditional GPG key server system.

[a3nm]

Thanks again for your explanations! Are you implying that GPG self-signatures do not cover all packets and subpackets of the key? I tried to find more detail online about a security problem related to what you were mentioning, but I haven't been able to find a source. Is there a more precise explanation somewhere? Is this something that the GPG team is aware of?

If there is some explanation of this problem online, I think it would be nice to link to it from the prompt asking the user to sign a new statement when updating their key on Keybase. Indeed, this prompt is confusing when the user doesn't understand why you are not just relying on the traditional GPG system.

-- Antoine Amarilli

On Fri, Jul 28, 2017 at 01:05:00PM +0000, Maxwell Krohn wrote:

We're pegging the full contents of the user's GPG key so that the server later can't lie by dropping subpackets. In reality this is a big security improvement over traditional GPG key server system.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/keybase/keybase-issues/issues/3026#issuecomment-318646504

[maxtaco]

I am indeed implying that! Your GPG fingerprint is a hash of your primary key. Self-signatures cover User IDs and embedded JPEGs, but they don't cover (as far as I've seen) key revocations. I think any key server along the way can permute the packets of your GPG key (or just drop them altogether) in arbitrary ways. This might have been envisioned as a feature as some point, even.

At this point, it's near impossible to change, since GPG wants to be backward compatible with keys out in the wild. Probably the right answer, in my opinion, is a blockchain based approach that prevents key servers from equivocating. See various "Key transparency" proposals for more on that. But if you were going to build all of that, you probably wouldn't need a lot of GPG's features in the first place.

I don't know of any link to it, it's just we noticed all of these problems in maintaining two PGP libraries (more or less). In keybase, the key used to sign your PGP key just signs a hash of the entire key into your append-only signature chain. That way, there's no way our server can maliciously (or accidentally) distribute a PGP key other than the one you've signed.

You can read RFC 4880 for more details, but it's pretty quiet on specifics about what packets need to be in a key, and in what order, and you'll see that it says almost nothing about key server infrastructure. I think that aspect of the GPG infrastructure is ad-hoc (though maybe there are new RFCs I haven't read).

In general, we've been focussing on building out chat, teams, and KBFS, so we haven't been spending too much time on the PGP side of our product. But we still mean for it to be a useful tool for those who are interested in it.

[a3nm]

OK, I think I'm beginning to understand, so let me try to put this in my own words. Self-signatures, like regular signatures, can only apply to keys, subkeys, User IDs, or User Attributes (RFC 4880, Section 5.2.4). They cannot cover the rest of the key data, in particular, to revocations.

Hence, for instance, if a key has a UID x, and the key owner then revokes UID x and creates UID y, the resulting key could be used to forge a key where UID y has been created but UID x has not been revoked.

By contrast, with Keybase, for each version of the key, you are requiring a signature of the entire key, so you are basically enforcing a linear history: while a keyserver can propose an old version of a key, it cannot forge a key by partially reusing an older version like in the example in the previous paragraph.

I agree with you that this is a bit problematic. Not knowing about the details of this, I was expecting that, whenever I edited my key with GPG, a new self-signature was generated that encompassed all the contents of the key so far, so that parts of the new key (e.g., a new UID) couldn't be used without this self-signature, hence couldn't be used while hiding older information in the key (e.g., a revocation). So I agree that the Keybase way makes sense!

Thanks a lot for taking the time to explain this! So I guess there is no problem after all, except that maybe the Keybase prompt about signing the key could point to some explanation about why the action is needed. (But maybe it's not worth it, I don't know.)

Thanks again!