Are the symmetric keys that are used to encrypt the private keys derived from a password, or not?
> This protocol overcomes this weakness by wrapping all key packets, encrypted with a key derived from a second high-entropy alphanumeric passphrase.
>
> The passphrase SHOULD be a random high-entropy uppercase alphanumeric string of 24 characters, generated from a cryptographically secure pseudo-random number generator (CSPRNG).
So do you seed the CSPRNG starting from something derived from a password? And if not, then how do you decrypt your private keys when you want to use them on a new device?
The RNG is, as far as I can make out, only recommend to ensure that users don't use a weak passphrase.
It also seems like there's no key-stretching involved, right? The cost of each brute-force attempt is very cheap? So the option of permitting a user-generated passphrase (with much lower entropy) seems like a pretty bad idea.
Have you looked into password-authenticated key exchange (PAKE) mechanisms? https://en.wikipedia.org/wiki/Password-authenticated_key_agr... My understanding is they let you use a relatively weak passphrase to authenticate a short-term session using a new 128-bit key, and once that session is established, attacks need to be against the session key, not the passphrase. This involves a bit more active communication than simply leaving an encrypted key in an IMAP folder, but you could do something where a new client requests a key by dropping a message in the folder, then you have to physically go to the old client to confirm it, which leaves a new message in the folder that (only) the new client can use.
I believe Firefox Sync uses a similar approach, except that the low-entropy passphrase is a PIN automatically generated by one of the devices, so the UX feels sort of like Bluetooth pairing.