#731 Strip unrelated user_ids and outdated keys from autocrypt keys

[Azul]

Autocrypt headers contain the full key. They are therefor much larger than needed.
mejo reported on irc that some mailservers reject mail with autocrypt headers due to "550 Autocrypt header is too long"
The particular mailserver is managed by spamexperts.com and runs exim4. One option is to contact the provider but it turns out the size limit is 10k chars - which would be fine even for 4k keys.

Mejos key has a large number of user ids which each add 0.5k for signatures. My key contains outdated public keys which also make the header slightly bigger than 10k.

According to the autocrypt spec the header should only contain a minimal version of the key. I know that this is difficult to achieve with the current tooling. I am happy to help if i can.

[Patrick Brunschwig]

I'm not sure that I agree with the proposed solution. The used key is simply not Autocrypt-compliant. The specification says that the keydata in the Autocrypt header MUST consist of exactly:

• a signing-capable primary key
• a user id
• a self signature over the user id by the primary key
• an encryption-capable subkey
• a binding signature over the subkey by the primary key

Concerning the subkeys: it's not sufficient to strip outdated subkeys. The requirement says that the key contain only ONE encryption subkey - which is considerably different than "no expired (or otherwise revoked) subkeys". That is, we have to decide on one specific valid, not revoked, not expired subkey that we would include, and all other subkeys would have to be exclucded. If at all, we should include the "best" subkey - strongest, longest valid ...?

Concerning the UIDs: Autocrypt does not mandate that the UID match the sender's email address at all. I would therefore say, if we strip any UIDs, then we should acutally only keep the primary UID -- independently of its content.

However, I'm not sure if we should go this path at all. After all, the key does not comply to Autocrypt, and I'm somewhat inclined to say " the key is not Autocrypt-compliant - you can't put it into an Autocrypt header".

[Patrick Brunschwig]

The tooling is not a big issue. Enigmail contains already OpenPGP.js, which provides access to the complete packet details. However, you need to know quite precisely how the packets are structured etc. to get them correctly.

[Patrick Brunschwig]

It turned out that OpenPGP.js offers all I needed. The actual code to extract the revant key parts is just a few lines of code.

The key in the Autocrypt header now contains:
1. the public key
2. the primary UID + the self-sig
3. the newest valid (not revoked/expired/disabled), encryption-cabable subkey + the signature

Please ask Mejo to test again using the latest nightly build.

[Azul]

Hi Patrick,

Thanks a lot for this! I will check back with Mejo. But for me myself this already reduced the size of my Autocrypt header by a factor of 3. \o/
I will most likely still migrate to a 3k key but it's great that i don't have to worry about that right away. :)
So thanks again! Will let you know if I hear anything from Mejo.