[rt-users] GnuPG key management issues

[Christopher Kunz]

Hello all,

we are using the RT::Crypt::GnuPG module and have run into an issue that
I'm afraid we cannot solve.

Recently, some german mail providers, most notably GMX (one of the
biggest free webmail providers in Europe) have enabled end-to-end
encryption for their users. This is implemented using OpenPGP keys and a
browser plug-in (modified version of Mailvelope).

However, GMX does not publish the generated keys to a keyserver.
Instead, users can send a so-called "invitation to encrypted
communication" which is essentially an auto-generated mail that has the
public key attached in an .asc attachment. [I am told by some customers
that this is the way some commercial mail servers/appliances seem to
handle key management, too.]

This is where the problems start. With our current setup (and a local
keyring on the RT server), RT will try handling the .asc attachment as
encrypted data (which it isn't), fail and not handle the rest of the
ticket. The requestor will receive a mail saying RT found invalid PGP
data in their request.

To remedy this (and add the key to RT's keyring), we currently have to
manually extract the pubkey, scp it to the RT, add the key to the
keyring and then re-set permissions (since gpg seems to modify ownership
to the user who last modified a keyring file) to the web server. This is
clumsy, error-prone and a security issue (since ssh access to our RT box
is restricted with good reason).

Also, it's unfortunately not possible to make GMX or our other customers
with similar behavior change their mail format - this is clearly out of
scope.

We are  using RT 4.0.8. Is there any configuration setting that I might
have missed, or any other possibility to get RT to automatically import
keys that come into the system as a .asc attachment? I am aware of the
security implications of this (and, in fact, have set the trust settings
to "always", as authentication of user requests is always performed
separately).

Best regards,

--ck