From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Alastair Turner <minion@decodable.me>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Date: Thu, 31 Dec 2020 11:21:12 +0100 (CET)
Message-ID: <alpine.DEB.2.22.394.2012311111380.3573723@pseudo> (raw)
In-Reply-To: <20201230234933.GI27507@tamriel.snowman.net>
References: <20201216001228.GC14807@momjian.us>
<CAC0Gmyy7QCvh4ey-e_XXYCHDEmaKKoeaagAFuAmhF=tS0DU4-A@mail.gmail.com>
<20201216213200.GS16415@tamriel.snowman.net>
<CAC0Gmyz9w7Axezsu66GVme3u+cR4OmqH5f-nCYNo6-cyxyA3pA@mail.gmail.com>
<20201216224331.GV16415@tamriel.snowman.net>
<CAC0GmyyVHstcMefpbCqXC25_Xg4V=Dy-q1ps1a06j9xUOL0SzQ@mail.gmail.com>
<20201218213624.GG16415@tamriel.snowman.net>
<CAC0GmyzJNXRZ5MQJYq24EiUarP+xN9Q19_cknkHmmYU=CTzHrQ@mail.gmail.com>
<20201227172526.GB17037@momjian.us>
<alpine.DEB.2.22.394.2012281736570.2094581@pseudo>
<20201230234933.GI27507@tamriel.snowman.net>
Hello Stephen,
>> The implementations should not have to be in any particular language: Shell,
>> Perl, Python, C should be possible.
>
> I disagree that it makes any sense to pass actual encryption out to a
> shell script.
Yes, sure. I'm talking about key management. For actual crypto functions,
ISTM that they should be "replaceable", i.e. if some institution does not
believe in AES then they could switch to something else.
>> After giving it more thought during the day, I think that only one
>> command and a basic protocol is needed. Maybe something as simple as
>>
>> /path/to/command --options arguments…
>
> This is what's proposed- a command is run to acquire the KEK (as a hex
> encoded set of bytes, making it possible to use a shell script, which is
> what the patch does too).
Yep, but that is not what I'm trying to advocate. The "KEK" (if any),
would stay in the process, not be given back to the database or command
using it. Then the database/tool would interact with the command to get
the actual per-file keys when needed.
> [...] 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.
I do not understand. Postgres should provide a working implementation,
whether the functions are directly inside pg or though an external
process, they need to be there anyway. I'm trying to fix a clean, possibly
external API so that it is possible to have something different from the
choices made in the patch.
--
Fabien.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: coelho@cri.ensmp.fr, sfrost@snowman.net, bruce@momjian.us, minion@decodable.me, michael@paquier.xyz, masahiko.sawada@2ndquadrant.com
Subject: Re: Proposed patch for key managment
In-Reply-To: <alpine.DEB.2.22.394.2012311111380.3573723@pseudo>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox