Hello,
The API to fetch the KEK doesn't care at all about where it's stored or
how it's derived or anything like that. There's a relatively small
change which could be made to have PG request all of the keys that it'll
need on startup, if we want to go there as has been suggested elsewhere,
but even if we do that, PG needs to be able to do that itself too,
otherwise it's not a complete capability and there seems little point in
doing something that's just a pass-thru to something else and isn't able
to really be used.
Right now, the script returns a cluster key (KEK), and during initdb the
server generates data encryption keys and wraps them with the KEK.
During server start, the server validates the KEK and decrypts the data
keys. pg_alterckey allows changing the KEK.
I think Fabien is saying this all should _only_ be done using external
tools --- that's what I don't agree with.
Yep.
I could compromise on "could be done using an external tool", but that
requires designing the API and thinking about where and how things are
done before everything is hardwired. Designing afterwards is too late.
ISTM that the current patch does not separate API design and cryptographic
design, so both are deeply entwined, and would be difficult to
disentangle.
--
Fabien.
