We could implement a 'command:' prefix now, and maybe
a 'pass:' one, and allow other methods like 'pkcs11' later.
We don't need to do anything except provide a way to tell OpenSSL where to get the KEK from, for situations where having Pg generate it internally undesirable.
I proposed a simple GUC that we could supply to OpenSSL as a key path because it's simple. It's definitely not best.
In my prior mail I outlined what I think is a better way. Abstract key key initialisation - passphrase fetching KEK/HMAC loading and all of it - behind a pluggable interface. Looking at the patch, it's mostly there already. We just need a way to hook the key loading and setup so it can be overridden to use whatever method is required. Then KEK operations to encrypt and decrypt the heap and WAL keys happen via that abstraction.
That way Pg does not have to care about the details of hardware key management, PKCS#11 or OpenSSL engines, etc.
A little thought is needed to make key rotation work well. Especially when you want to switch from cluster passphrase to a plugin that supports use of a HVM escrowed key, or vice versa.
But most of what's needed looks like it's there already. It's just down to making sure the key loading and initialisation is overrideable.
