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 <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
