On Sat, Jan 2, 2021 at 12:47:19PM +0000, Alastair Turner wrote: > If keys can have arbitrary scope, then the pg backend won't know what > to ask for. So the API becomes even simpler with no specific request > on stdin and all the relevant keys on stdout. I generally like this > approach as well, and it will be the only option for some > integrations. On the other hand, there is an advantage to having the > key retrieval piece of key management in-process - the keys are not > being passed around in plain. > > There is also a further validation task - probably beyond the scope of > the key management patch and into the encryption patch[es] territory - > checking that the keys supplied are the same keys in use for the data > currently on disk. It feels to me like this should be done at startup, > rather than as each file is accessed, which could make startup quite > slow if there are a lot of keys with narrow scope.
We do that already on startup by using GCM to validate the KEK when encrypting each DEK. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
