[openpgp] key distribution by email strategy

[Kai Engert <[e-mail]>]

Thanks to everyone for your comments and suggestions, it was very helpful.

I wonder if the following could be reasonable.


(1) Similarly to the Autocrypt keydata header
let's define a new header that can be used to transport revocation 
information for a key.

With Thunderbird's current approach to include revocations as part of an 
gpg-keys attachment, we probably cannot expect most other MUAs to 
automatically process it.

Thunderbird would implement the new revocation information header, and 
both send and consume it. With this, Thunderbird would no longer need to 
distribute this information in an attachment.


(2) If the sender's key is simple, don't use an attachment.

Strip certificates, include it as an Autocrypt keydata header.


(3) Develop a reasonable strategy for treating complex keys,
which contain multiple user IDs, or multiple sub keys, or both.

I'm worried that sending a key with only a single user ID can be 
confusing, for example in the following scenario.

Alice's key has two user IDs, @project1.org and @project2.org.

Alice sends a signed email from @project1 to Bob, Bob verifies/accepts 
the key for this email address. Later Alice sends a signed email from 
@project2. Bob will be confused why Alice's key is shown as unverified, 
despite her using the same key. This will require UI to distinguish the 
key verification status individually per user ID.

To minimize this confusion, I think it would be preferable to always 
keep all user IDs, then Bob can be immediately aware that the keys is 
used for multiple addresses.

Does the current Autocrypt specification allow the distribution of a key 
with multiple user IDs and sub keys?

If we strip certificates, but keep user IDs and sub keys, can we expect 
keys to still have a reasonable size for transport in the Autocrypt header?

If yes, then Thunderbird could always include an Autocrypt keydata 
header for complex keys, too.


Kai