Lookup private key for decryption in keystore

[christian-schlichtherle]

Currently, only one private key for decrypting messages can be used.
This is not enough when renewing certificates because you may still receive messages which were encrypted using the old certificate.

This pull request searches for a matching private key in the keystore instead to fix this issue.
This search is based on a certificate selector, which is already used when looking for certificates to verify signatures - see Directory.certificate(X509CertificateSelector).
It introduces a new method in the Identity interface:

default Optional<PrivateKey> privateKey(X509CertSelector selector) throws Exception {
    return selector.match(certificate()) ? Optional.of(privateKey()) : Optional.empty();
}

The default implementation retains the old behaviour, so custom implementations of this interface still work.
When calling SECON.identity(KeyStore, String, Callable) however, clients get an implementation with the new behaviour.

[marcusfey]

As a side note (I lost track of this repository): ITSG requires the most recent certificate to be used on the sender's side.
https://www.itsg.de/oeffentliche-services/trust-center/

I'm not sure whether the current implementation reflects this - nor am I sure whether it contradicts it.

[christian-schlichtherle]

Yes, this is reflected.

As a certificate owner, whenever you renew your certificate, you just need to do the following to ensure that this SECON tool works properly:

1. Add a new private key entry to the keystore which holds the private key and its corresponding certificate - see keytool documentation.
2. Configure the SECON tool to use the alias for the new private key entry when calling the method identity(KeyStore ks, String alias, Callable<char[]> password) in the class SECON.

If you are using your own implementation of the interface Identity, then you need to implement the method privateKey(X509CertSelector selector). Otherwise, you will automatically get the old behaviour and thus, you may not be able to decrypt messages which do not match the configured private key.

[loetifuss]

As a side note (I lost track of this repository): ITSG requires the most recent certificate to be used on the sender's side.
https://www.itsg.de/oeffentliche-services/trust-center/

I'm not sure whether the current implementation reflects this - nor am I sure whether it contradicts it.

On the sender side, if using the LdapDirectory, the recipient certificates are sorted by validity date to ensure that the latest certificate is used, see LdapDirectory.java
AFAIK, when using a keystore as directory you can only have one certificate for each recipient ID, see KeyStoreDirectory