Decide how to handle plain passwords for PEM encoded certificates

[s-l-teichmann]

We currently support PEM encoded client certificates which may be protected
with an optional password.

There is an design flaw in RFC 1423 See used call in Stdlib for details

Currently we tend to leave it in, but for the 2.4.0 release we should document it or maybe
remove it or use another container format.

[s-l-teichmann]

@tschmidtb51 ... as discussed in the meeting PR #435 documents the issue.

[bernhardreiter]

Reading up on this, I do not fully understand the situation yet.

• https://pkg.go.dev/crypto/x509@go1.20.7#DecryptPEMBlock says there is a problem with a padded oracle attack. However I fail to see where the oracle would be in an attack scenario against a local file holding the private key. From what I have understood so far, an oracle would require the password.
• ssh, openssl and gnutls use other private key protection methods, so our implementation probably does not work with client certificates that are created these days. crypto/x509: no support for parsing encrypted PKCS8 private keys golang/go#8860 may offer some pointer to libraries that implement modern private key protections.

[bernhardreiter]

We want to leave it in, but mark it as experimental (so we can remove it in the future). The limits of the options shall be documented.

This is reflected in #435 now.