Decide how to handle plain passwords for PEM encoded certificates

s-l-teichmann commented 1 year ago

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 commented 1 year ago

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

bernhardreiter commented 1 year ago

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. https://github.com/golang/go/issues/8860 may offer some pointer to libraries that implement modern private key protections.

bernhardreiter commented 1 year ago

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.

gocsaf / csaf