Re: Internal key management system

On 18/6/20 19:41, Cary Huang wrote:
> Hi all
>
> Having read through the discussion, I have some comments and
> suggestions that I would like to share.
>
> I think it is still quite early to even talk about external key
> management system even if it is running on the same host as PG. This
> is most likely achieved as an extension that can provide communication
> to external key server and it would be a separate project/discussion.
> I think the focus now is to finalize on the internal KMS design, and
> we can discuss about how to migrate internally managed keys to the
> external when the time is right.

As long as there exists a clean interface, and the "default" (internal)
backend is a provider of said functionality, it'll be fine.

Given that having different KMS within a single instance (e.g. per
database) is quite unlikely, I suggest just exposing hook-like
function-pointer variables and be done with it. Requiring a preloaded
library for this purpose doesn't seem too restrictive ---at least at
this stage--- and can be very easily evolved in the future ---
super-simple API which receives a struct made of function pointers, plus
another function to reset it to "internal defaults" and that's it.

>
> Key management system is generally built to manage the life cycle of
> cryptographic keys, so our KMS in my opinion needs to be built with
> key life cycle in mind such as:
>
> * Key generation
> * key protection
> * key storage
> * key rotation
> * key rewrap
> * key disable/enable
> * key destroy

Add the support functions for your suggested "key information"
functionality, and that's a very rough first draft of the API ...

> KMS should not perform the above life cycle management by itself
> automatically or hardcoded, instead it should expose some interfaces
> to the end user or even a backend process like TDE to trigger the above.
> The only key KMS should manage by itself is the KEK, which is derived
> from cluster passphrase value. This is fine in my opinion. This KEK
> should exist only within KMS to perform key protection (by wrapping)
> and key storage (save as file).

Asking for the "cluster password" is something better left optional /
made easily overrideable ... or we risk thousands of clusters suddenly
not working after a reboot.... :S

Just my .02€

Thanks,

    J.L.