On Mon, 4 Jan 2021 at 17:56, Bruce Momjian wrote:
>
> On Sat, Jan 2, 2021 at 12:47:19PM +, Alastair Turner wrote:
> >
> > There is also a further validation task - probably beyond the scope of
> > the key management patch and into the encryption patch[es] territory -
> > checking that the
Hi Bruce
On Mon, 4 Jan 2021 at 18:23, Bruce Momjian wrote:
>
> On Fri, Jan 1, 2021 at 06:26:36PM +, Alastair Turner wrote:
> > After the long intro, my question - If using a standard format,
> > managed by a library, for the internal keystore does not result in a
> > smaller or simpler
On Tue, Jan 5, 2021 at 10:18 AM Bruce Momjian wrote:
> On Fri, Jan 1, 2021 at 06:26:36PM +, Alastair Turner wrote:
>
> There is all sorts of flexibility being proposed:
>
> * scope of keys
> * encryption method
> * encryption mode
> * internal/external
>
> Some of this is related to
On Fri, Jan 1, 2021 at 06:26:36PM +, Alastair Turner wrote:
> After the long intro, my question - If using a standard format,
> managed by a library, for the internal keystore does not result in a
> smaller or simpler patch, is there enough other value for this to be
> worth considering? For
On Sat, Jan 2, 2021 at 12:47:19PM +, Alastair Turner wrote:
> If keys can have arbitrary scope, then the pg backend won't know what
> to ask for. So the API becomes even simpler with no specific request
> on stdin and all the relevant keys on stdout. I generally like this
> approach as well,
On Sat, Jan 2, 2021 at 10:50:15AM +0100, Fabien COELHO wrote:
> > No, this isn't anything like the Kerberos model and there's no case
> > where the PG account won't have access to the DEK (data encryption key)
> > during normal operation (except with the possibility of off-loading to a
> >
Hi Fabien
On Sat, 2 Jan 2021 at 09:50, Fabien COELHO wrote:
>
...
> ISTM that pg at the core level should (only) directly provide:
>
> (1) a per-file encryption scheme, with loadable (hook-replaceable
> functions??) to manage pages, maybe:
>
>encrypt(page_id, *key, *clear_page,
Hello Stephen,
I'm unsure about what is the "common use case". ISTM that having the
postgres process holding the master key looks like a "no" for me in any use
case with actual security concern: as the database must be remotely
accessible, a reasonable security assumption is that a pg account
Hi Stephen, Bruce, Fabien
On Thu, 31 Dec 2020 at 17:05, Stephen Frost wrote:
>
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Thu, Dec 31, 2020 at 11:11:11AM +0100, Fabien COELHO wrote:
> > > > I am not sure what else I can add to this discussion. Having something
> > > >
>
>
> > >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,
> >
> > I'm do not see why it would be the case. I'm just arguing to have key
> > management in a
On Wed, Dec 30, 2020 at 3:47 PM Bruce Momjian wrote:
>
> 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.
>
>
I
On Thu, Dec 31, 2020 at 12:05:53PM -0500, Stephen Frost wrote:
> > Let's unpack this logic, since I know others, like Alastair Turner (CC
> > added), had similar concerns. Frankly, I feel this feature has limited
> > security usefulness, so if we don't feel it has sufficient value, let's
> > mark
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Dec 31, 2020 at 11:11:11AM +0100, Fabien COELHO wrote:
> > > 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
On Thu, Dec 31, 2020 at 11:11:11AM +0100, Fabien COELHO wrote:
> > 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
> >
Greetings,
* Fabien COELHO (coe...@cri.ensmp.fr) 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),
Hello Bruce,
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
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),
17 matches
Mail list logo
