Secure Private Key Synchronization (RFC)

[Arjan Wekking]

Hello Tankred. Interesting proposal.

> On 03 Jul 2015, at 12:44, Tankred Hase <tankred at whiteout.io> wrote:
> 
> That's a good question and the spec is indeed not specific enough
> here. If I'm not mistaken Mailvelope only includes the primary key
> packets in their current implementation. But it makes sense to include
> subkey packets as well. Something to be clarified in the spec.

So, if I understand this correctly, this would still only cover private keys c.q. key pairs?

But what about the public keys of your contacts, and their uids and signatures? If it would allow you to store these as well, perhaps with the same [KEY ID]@[HOSTNAME] message-id scheme but using different MIME types, it could also function as a simple “shared key ring”?

Also, wouldn’t it be better to use [FINGERPRINT] instead of [KEY ID] in the message-id, assuming that the latter is actually a long key ID and not the fingerprint already? Although it is probably still unlikely for quite a while, collisions on long key IDs are technically possible and will only become more likely. RFC 4880 section 3.3 also recommends not relying on the uniqueness of key IDs:

> Implementations SHOULD NOT assume that Key IDs are unique.


Now, if you were only to generete these message-id’s for private key pairs, I assume it would probably never be an issue. But if you were to add public keys as well, then using fingerprints instead of (long) key ID’s would perhaps be better.

-Arjan