S/MIME public key storage

[LecrisUT]

What would you like to be added

The certificate issuance can be handled with the current templates, but in order to have s/mime be useful, a key server should also be introduced, where users can query for someone's public key. Some features to consider.

• Minimum: Ability to query for a user's certificate, upload and auto-store on creation one's certificates
• Privacy and anti-spoof: ACL or require a trusted client certificate and log requests
• Other helper cli commands: encrypt file for user(s), decrypt using stored certificate, re-encrypt with newer certifiatea, add/remove aliases

Why this is needed

Some usecases for private/semi-public S/MIME where we also need public keys being shared:

• Automated backup system with multiple admins. Probably a group query (maybe from oauth) would also be useful here.
• E2E encryption with backup encryption. Maybe the user or a trusted admin has a long-term S/MIME certificate stored in a secure offline vault, and short term certificates for "everyday" use. Files/messages etc. can be encrypted with both keys to ensure the files are readable. Maybe even have a mid-term key stored in a keepass vault
• Re-encryption of archived files. The user can have their own rolling long-term keys and have either the backup manager, email client/server, etc. re-encrypt the user's data with a more trusted certificate

[dopey]

Hey @LecrisUT, thanks for opening the issue! First off, we're glad there is interest from the community in this issue - we had been thinking about this project internally, and it's great to get some confirmation.

However, this is definitely a larger project. One that will require design discussion and a spec. Our roadmap is currently packed until at least Q1 of next year, but in the mean time it would be great to get more feedback from the community on this issue: either in the form of support or additional requirements. We'll take the feedback and support into consideration when we review our roadmap.

Cheers!

[LecrisUT]

Indeed it is a big issue to tackle, but we'll get there eventually.

On the implementation, consider coordinating with polhenarejos/acme_email on standardizing a discovery endpoint on the CA server. Probably it will be inspired by ooengpg and WKD standard in particular.

Additional clients to consider so far are email clients like Thunderbird and gpgsm (gpg's S/MIME addon) for non-email encryption and key location.