Yes Libkleo should imo provide a configurable new Key generation dialog. But I don't think you need a dialog at all from KMail because you can take the Name / Mailbox from the Identity configuration.

With GnuPG 2.1.12 or so we could use a Quick Gen Key, but as we don't want to rely hard on such a new version we need these params :-(

I don't think this "Inline Keygen" can work for S/MIME in KMail this way as a new S/MIME Certificate only generates a CSR that has to be exported and sent to a Certificate Authority for signing. This is out of scope currently as it creates loads of problems usability wise.

I think for S/MIME the common case is that you either get your certificate handed to you by your CA or Administration and have to import it or that you start a dedicated tool (Kleo) to work this out.

I don't think this is needed as I think we should only show ultimately valid keys with the email matching the identity. Maybe if we make this more generic without a preset identity this could work.

This is something I always found annoying in the old selection that it showed you even keys that you could not select. We should imo only include keys with ultimate UID Trust as these are what GnuPG thinks are "your own keys" and you are currently selecting your own keys.

For the super corner case that someone wants to configure not his / her own key for an E-Mail address. (I'm maybe thinking about some "support@foo.bar" with a shared support signing key that does not have ultimate trust they can edit the configuration of KMail.

To quote Björn "We should design for the 95% and not the 5%".

No name here imo. Otherwise you might get keys that do not provide the email, this would be wrong and should not be supported. This also might reduce results and thus simplify selection for the user imo.

This can be a ridicoulously slow job:

e.g on my very high performance system (admittedly with a fairly large keyring):
time gpg2 -K
gpg2 -K 3.85s user 0.13s system 98% cpu 4.032 total

Because due to the Architecture GnuPG has to go over every public key and ask the gnupg-agent through IPC if he has a secret key for this public key. On slower Systems or if a TrustDB Update (which gnupg does automatically) is involved seen this job to take over 30 seconds. That's why Kleopatra now has a "Keycacheoverlay" to similarily to KMails Akonadioverlay disable widgets and show a "Loading Certificates.." Progress bar.
I've already complained to upstream about this and they might fix this in the future.

But in this widget this would result in a noticable delay between widget shown and entries visible. With GnuPG versions > 1.4 < 2.1.6 this job could even take an infinite amount of time as it resulted in CRL Checks for each S/MIME Certificate.

This could be solved by putting the keycache into libkleo so that it can be populated before in the background.

If I ditch the S/MIME key generation, then we don't (just need some progressbar).

Right, but there should be a class in libkleo where you setKeyType(), setKeyLength(), addSubKey() etc. and then call generate() and the class would assemble the XML internally and call the generation job. I've spent way too much time understanding and stripping down the code from Kleopatra's wizard to get this working.

I can remove the option for S/MIME then. Alternatively we could have "Import" action instead of "Generate new key pair", but that adds even more complexity.

I don't think that Bjoern's argument should ever lead to "they can modify config files manually". I'm thinking of adding "More keys..." option that would open the regular KeySelectionDialog where you can select whatever you want. Not sure how to do it yet though.

I can work on that, but in a separate patch, that would be out of scope for this review IMO. On my rather small keychain (i.e. a keychain that most people have?) this is rather fast (no noticable delay), so it should be good-ish for now (?)

Please remove the shortKeyID here. We should not use it in new code and start to remove it. GnuPG since 2.1.13 has removed short KeyID's from keylistings etc. Where an exact identification of a key is required we should use the full fingerprint or where the API / Protocol requires it the long fingerprint.
With Björn and Werner I've agreed that using the creation date for simple distinction between your keys. Without having to add a "complicated number" ;-)

Some background:
https://lwn.net/Articles/689792/

I'd also slightly prefer if this could be handled in the model or thorugh formatting / the keylistmodel so that we could reuse the representation. I've called this "Formatting::SummaryLine". One idea I have in mind for this is that we skip the Type in case the user only uses one Protocol. (e.g. does not have any OpenPGP or any S/MIME keys) which we expect to be common among non institutional crypto users.

What about String Filter? I think we could use the string filter to filter for a key matching the mailbox of the identity.

(Once we fix the KeyListSortFilterProxyModel to handle filtering for multiple uid's, which should be simple enough.)

(Once we fix the KeyListSortFilterProxyModel to handle filtering for multiple uid's, which should be simple enough.)

I've fixed it with 69fa563 as this was important anyway.
Now you can also filter for e.g. aheinecke@gnupg.org and it will match my key although the primary uid is aheinecke@intevation.de.