Add logic to determine if signer should use PQC certificate based on recipients

[TJ-91]

To a certain extent similar to #2219, what should the level of control for the caller be and what should the library do automatically in the following case:

The sender has a PQC certificate (PQC primary key) and a non-PQC certificate. For backwards-compatibility, he can sign a message using his non-PQC cert. If he can determine that every recipient understands PQC, he can use his PQC certificate.

@ni4 @falko-strenzke @kaie

[ni4]

I don't see strong need for this right now as user may manually implement signer choosing logic (and what Thunderbird as a major RNP user does now).

[kaie]

It's correct that as of today, Thunderbird doesn't make any automatic choices for the selection of the user's own preferred personal key.

So far, I had never considered the scenario that the user may have multiple equitable signer keys for the same email address.

The assumption so far was, the user decides for themselves what their preferred and most recent key is. For example, when they decide to no longer use something old, and want to use something newer.

A user might have chosen to start a process of phasing out an older key, but it might be still valid. And the user has a newer key, which is now the preferred key.

In this scenario, the user might not want to allow that the older certificate is still being used.

(The old scenario might have been imported simply for the purpose of being able to decrypt old emails.)

So based on the old assumptions, the user choses which key they want to use, configures it as the actively used key for an email address, and TB always uses exactly that one for signing. Also, only that one for including it when sending out emails with the user's own key.

I haven't yet considered the scenario that TJ-91 described in the initial comment, because it wasn't yet necessary.

Let me try some initial thoughts on this topic.

I think it's better to avoid automatic switching between separate certificates.

A recipient might have verified the sender's key already. If the sender suddenly switches to a different key, the recipient might not trust it, and might assume a fake. Thunderbird might even show a warning, that an unexpected different key is being used (with an unknown fingerprint).

I think it's simpler to keep the separation of keys/certificates for the "old, no longer used" vs "new, now preferred" scenario.

If it's necessary to switch between different algorithms for wider compatibility, then I think users should add additional subkeys to support additional algorithms. The application could assist the user in doing so, e.g. when a new version of an application is released, and the application discovers that the user's key is limited to old algorithms, but the application supports new algorithms, the application could optionally suggest to the user to upgrade their key. Either, by extending an existing key with additional subkeys, or by generating a new key that contains subkeys for all algorithms that are still supported (in this second scenario, the user should configure to use the new key, and declare the previous one as outdated).

If we really end up in a world where an application needs to support different keys in parallel, with equitable validity, then I think this concept of parallel keys would have to be implemented at the application level. It would require the ability to configure multiple keys in parallel. It would require support for automatically selecting the best certificate. Also, when advertising the user's own certificate when sending out messages, it would be necessary to attach all alternative keys, to ensure recipients can select the one that is compatible with their software.

I don't like the idea of having to support multiple active certificates in parallel. I hope it can be avoided by using subkeys.

[ni4]

A user might have chosen to start a process of phasing out an older key, but it might be still valid. And the user has a newer key, which is now the preferred key.

As a possible solution to this user may just sign his new PQC key with old non-PQC one, so it would be easier for recipient to make a trust decision on a new key.