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.
