Re: Proposed patch for key managment

From: Alastair Turner <minion(at)decodable(dot)me>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Subject: Re: Proposed patch for key managment
Date: 2020-12-21 00:22:44
Message-ID: CAC0GmyzT_90f6oHg8rBn-Eb8-Q=wHLsKripmadU2B4SkTKBbAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Stephen

On Sun, 20 Dec 2020 at 22:59, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
...
> However, after chatting with Bruce about it for a bit this weekend, I'm
> not sure that we need to tackle the second case today. I don't think
> there's any doubt that there will be users who will want PG to manage
> the keyring and to be able to work with just a passphrase, as Bruce has
> worked to make happen here and which we have a patch for. I'm hoping
> Bruce will post a new patch soon based on the work that he and I
> discussed today (mostly just clarifications around keys vs. passphrases
> and having the PG side accept a key which the command that's run will
> produce)...
>

Having Postgres accept a key which the command will produce sounds great

>
> Yes, it's true that after things are implemented it can be more
> difficult to change them- but if you're concerned about the specific
> on-disk format of the keyring then please help us understand what your
> concern is there. The concern you've raised so far is just that you'd
> like an option to have an external keyring, and that's fine, but we are
> also going to need to have an internal one and which comes first doesn't
> seem particularly material to me. I don't think having one or the other
> in place first will really detract or make more difficult the adding of
> the other later.
>
What I'd like specifically is to have the option of an external
keyring as a first class key store, where the keys stored in the
external keyring are used directly to encrypt the database contents.
The examples in this discussion so far have all put the internal
keyring between any other crypto infrastructure and the file
encryption process. Your description above of changes to pass keys out
of the command sound like they may have addressed this.

Regarding the on-disk format, separate storage of the key HMACs and
the wrapped keys sounds like a requirement for implementing a fully
external keyring or doing key wrapping externally via an OpenSSL or
nss tls pluggable engine. I'm still looking through the code.

Thanks
Alastair

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-12-21 00:33:21 Re: Proposed patch for key managment
Previous Message David G. Johnston 2020-12-20 23:55:10 Re: \gsetenv