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.