noggin
noggin copied to clipboard
As an email user, I want to communicate securely with a Fedora Project member.
Suppose I want to send a secure email to someone who prefers to use their fedoraproject.org email address. Suppose I use an email program with Web Key Directory support. My email program will contact fedoraproject.org servers to ask for the recipient's OpenPGP key. If the recipient has a key, then I want to be able to look it up this way.
Resources: https://wiki.gnupg.org/WKD https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-09
Note that submitting keys through the Web Key Directory Update Protocol (or Web Key Service) is not appropriate for a forwarding alias like a fedoraproject.org email address. Instead users should log in to their account and upload their key that way, which ties in with issue #117.
I may be able to help with the implementation, but I need to gather more data before i can promise anything.
@lgriffin asked to be tagged. Let's see if I have divined correctly how to do that.
I believe this should be filed as an infra ticket at https://pagure.io/fedora-infrastructure/issues
i.e. I think this requires changes to the email servers that handle those aliases, not the system which generates/creates those aliases.
No changes to any email servers are needed. The WKD lookup protocol is based on HTTPS. It's essentially a collection of files on a web server. The web server needs to know about key that users have uploaded, and that's where the account system gets involved.
Email servers would only be involved in the update protocol, which I'm suggesting that we should not implement.
@Rombobeorn thanks for explaining. This isn't in scope for the project right now but might be worth looking at later on.
Thanks @Rombobeorn for logging the ticket (and for tagging me!). This is definitely something of value and as @relrod mentioned it may not be in scope right now but lets explore what an implementation would look like. Could you share your thoughts here and lets explore what this could look like.
I have done some more research. Here's a draft of an outline for a design:
First and foremost there needs to be a domain name, and a web server with a certificate for that name. The draft WKD specification favors "openpgpkeys.fedoraproject.org", but just "fedoraproject.org" should also work. A separate server isn't needed. An additional hostname on an existing web server will suffice. The implementation will be simplest if it's the same server that the account system runs on. Clients will send HTTPS requests to this server to look up keys.
In the other end, users log in to the web GUI and upload their keys. There should be a file selection widget for this. Possibly users could be allowed to either select a file or paste the key into a text area. Having only a text area would be a bad idea, because that would require users to know how to ASCII-armor a key.
Each uploaded file should be run through GnuPG to verify that it is a public OpenPGP key, and maybe sanitize it.
For tying those two ends together, I'm considering three main approaches that differ in how keys are stored:
Uploaded keys are stored the same way that FreeIPA stores other data. In LDAP or something? I'll call it "the database" for now. When keys are displayed to logged-in users in the web GUI, they are looked up in the database.
Keys that have a user ID with a fedoraproject.org email address are also exported through a program that removes other user IDs and signatures, and stores the keys in the key directory with a specially encoded filename. WKD requests are served from there, and shouldn't require executing any code other than the web server itself.
There are some tools that can help with exporting keys. If this will run on Fedora then /usr/libexec/gpg-wks-client has --install-key and --remove-key commands for managing a key directory. gpg-wks-server has like-named commands that may also be suitable. In RHEL/CentOS 8 gpg-wks-client is too old, but we may be able to use a program called generate-openpgpkey-hu that exists in Python 2 and Python 3 variants.
This approach causes some duplication of data as keys are stored in two places, but they are small files so the storage requirements should be manageable.
Keys are stored only in the key directory, using the same tool as above. To display keys to logged-in users, the web GUI converts the username to the encoding used in WKD and looks for a file with that name.
This approach should work well if WKD is the only way that uploaded keys are used. It becomes much more complicated if keys will be used for any other purpose, such as issue 117 , because then there may be a need to store other user IDs and/or signatures, that shall not be served according to the WKD specification.
Keys are stored only in the database. When a WKD request comes in, the web server doesn't just send a file, but executes a program (through CGI or WSGI or whatever). This program looks for a key in the database, exports it on the fly, and sends the stripped key to the client.
This approach deviates from how the GnuPG tools expect things to be done, and will probably take more programming work. It may also make the server more vulnerable to overloading.
I think approach 1 looks best so far. If separate servers are desired for some reason, then only approach 1 makes sense.