> ...because it means handing over your private keys to gmail. You should be able to create a separate gmail-specific certificate and give gmail only the key f

> ...because it means handing over your private keys to gmail. You should be able to create a separate gmail-specific certificate and give gmail only the key for that. The resistance in doing this sort of thing bothers me. There are users who believe that their keys should only be on an airgapped machine or on a hardware crypto token or something. This is fine for things that need ultra-level security, but at the same time the gap between usability and ultra-security prevents adoption of even the simplest signing. If instead we consider hosted mail providers to have a copy of private keys as acceptable, incremental improvement in security (but on the understanding that this is a weak mode), use of strong encryption would become more ubiquitous and the ones who need stronger security would be in a position to get it. To make this work, I think that maybe we need more metadata capability though. Certificates should explain the level of security/usability trade-off the subject expects to take with the corresponding key (everyday use, ultra protected but awkward, etc). And protocols need better support for multiple keys that match a particular identity (eg. "sending encrypted? Do you want to send it to the recipients everyday key, or his ultra-protected key but then may not bother to read it for a while because it'll take him effort to get access?") Of course, this also means that there is a UX problem to solve. But that's part of the problem with email cryptography, isn't it?