On Mon, Dec 28, 2020 at 06:15:44PM -0400, Fabien COELHO wrote:
> The API should NOT make assumptions about the cryptographic design, what
> depends about what, where things are stored… ISTM that Pg should only care
> about naming keys, holding them when created/retrieved (but not create
> them), basically interacting with the key manager, passing the stuff to
> functions for encryption/decryption seen as black boxes.
>
> I may have suggested something along these lines at the beginning of the key
> management thread, probably. Not going this way implicitely implies making
> some assumptions which may or may not suit other use cases, so makes them
> specific not generic. I do not think pg should do that.
I am not sure what else I can add to this discussion. Having something
that is completely external might be a nice option, but I don't think it
is the common use-case, and will make the most common use cases more
complex. Adding a pre-defined system will not prevent future work on a
completely external option. I know archive_command is completely
external, but that is much simpler than what would need to be done for
key management, key rotation, and key verification.
I will say that if the community feels external-only should be the only
option, I will stop working on this feature because I feel the result
would be too fragile to be reliable, and I would not want to be
associated with it.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee