progmaticltd commented 4 years ago

Along with #335, it does not seem to be a huge amount of work to implement a web key directory, and seem nice for a professional email hosting platform.

Soem links:

fredericmoulins commented 4 years ago

I do have a playbook for the web key discovery part, ie publication of the public key under a well-known URL, for both direct and advanced method.

I did it quick and dirty, so it needs some changes on the way to configure the PGP public keys per users.

The RFC requires (for now) the public key to be in the binary format. To get a public key in the system configuration, there might be several options:

require a public key to be in a backup folder already named with its WKD specific name (gpg --list-keys --with-wkd-hash ; the hash part before the @[domain]), and configure the name in the user object in the system configuration.
require a public key in the ASCII armored format to be configured in a YAML file in a new object (eg openpgp-wkd or webkeydirectory), listing the keys indexed by user uid. People are maybe more used to handle the public keys in this format. I haven't tested this, but I think it might be doable since gpg is installed by default, to convert the file from ASCII armored to binary and even handle the WKD name. A PGP public key in the ASCII armored format is not the length of an SSH public key, it would take quite some space in the configuration files. It could be:
- either at the end of the system.yml file ;
- or in another PGP specific YAML file that would get included somehow.

Any thoughts?

arodier commented 4 years ago

Thanks, a lot of nice ideas, as usual, I will come back to you on this. For now, I am focusing on fixing the postfix/dovecot sent mail copy. See the PR for the status

fredericmoulins commented 3 years ago

356 allows to publish PGP public keys as a Web Key Directory by adding them ascii armored in the server's configuration. This can be useful for the administrator or for a few people on the domain.

A few notes.

There is no check whether the PGP public key corresponds to an email address or alias declared for the user. I was not sure how to handle this, meaning how to fail or get the message to the admin during an install about a mismatch between keys and email addresses. The extraction of the information from the public keys is done, as it is, on the server during the role execution: I would rather prefer a check on the configuration data before executing the install; this would require gpg on the localhost, it might be ok or not.
This PR adds a pgp object in the configuration. If I am not mistaken, there is at least one role that uses a file that need to be placed in the backup directory. That could also be a possibility. The long PGP public key in the configuration is not pretty, I don't know how practical it is to have to place files in the backup directory (especially when it might not exists on the first runs).

I am open to discussion, opinions and ideas on these. I am happy to be able to publish keys, the rest is a matter of convention and coherence with other roles, and can quite easily be changed.

In the great scheme of things, a next step would be to implement the Web Key Service integrated with Postfix (and apparmor-ed…).

progmaticltd commented 1 year ago

Implemented

progmaticltd / homebox

Implement web keys directory #336

356 allows to publish PGP public keys as a Web Key Directory by adding them ascii armored in the server's configuration. This can be useful for the administrator or for a few people on the domain.