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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp