No Support for Encrypted Private Key for Secure Token Endpoint?

[tzfx]

Hello there! Just started using the module and I noticed pretty quickly that the private keyfile that is configured via OIDCClientTokenEndpointKey doesn't appear to support encrypted private keys. Based on a quick look of the easy_curl/libcurl stuff, it looks like that underlying library should support it as a CURLOPT: https://curl.se/libcurl/c/CURLOPT_KEYPASSWD.html

C is absolutely not my strong suit, but I forked and created a PR into my own repo to play around with this: tzfx#1

Is this something that would be worth including? Or is there some other sneaky way I should be handing in my key that isn't immediately obvious? I'm not super keen on keeping unencrypted private keys hanging out in my apache server.

[zandbelt]

I'm not really against taking a PR if it is really clean, but my question has always been: since the encryption password is in the Apache config now, why don't you protect the private key file in the same way as the Apache config file since that renders the same security?

[tzfx]

That's a fair question! Even if we took the CryptoPassphrase route of getting the password from the stdout of a script, if the someone can see the location of that script/file, and also has read access on the encrypted key, then is it really doing anything other than implementing security through obfuscation? It's just been hammered into everyone's brains at this point to 'never keep raw unencrypted keys on disk' , I guess.

That said-- Being able to keep the key encrypted at rest simplifies a lot of things when we're configuring a bunch of services/servers through automation tools and we need to store/distribute our private keys to places and applications other than apache.

[zandbelt]

Sort of, but you may get the automation tools to change the private key file access, I'm sure they can do so; if you're worried about automation tools themselves or the people that operate them, you have a different security problem to solve...

Anyway, I've come across this supposedly "large enterprise argument" several times: no one was able to explain the security benefit, and it always ended up with "this is what our company policy" is; so at the end of the day, if you provide the PR and it is clean enough, I will merge it, and everyone will feel safer.