Date: Sun, 20 Dec 2020 21:38:55 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Alastair Turner <minion@decodable.me>
Cc: Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Message-ID: <20201221023855.GC27507@tamriel.snowman.net>
References: 
 <CAC0GmyyVHstcMefpbCqXC25_Xg4V=Dy-q1ps1a06j9xUOL0SzQ@mail.gmail.com>
 <20201218213624.GG16415@tamriel.snowman.net>
 <20201219023844.GG28841@momjian.us>
 <CAC0GmywbXOWqnU7poYapfnSSd8JuZ0=-fGiumdwA-TumJNuEYg@mail.gmail.com>
 <20201219165837.GH28841@momjian.us>
 <CAC0GmyymnoQEUTzqi9wCCJdg96SbLja4Tc29Wc+xtRpu9Pv76w@mail.gmail.com>
 <20201220225909.GJ16415@tamriel.snowman.net>
 <CAC0GmyzT_90f6oHg8rBn-Eb8-Q=wHLsKripmadU2B4SkTKBbAg@mail.gmail.com>
 <20201221003321.GO16415@tamriel.snowman.net>
 <CAC0Gmyzk-vcmiqn6Nxbu=A1kEifAgpftRSLdCA-jZ2AHQcQZcw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="oTHb8nViIGeoXxdp"
Content-Disposition: inline
In-Reply-To: 
 <CAC0Gmyzk-vcmiqn6Nxbu=A1kEifAgpftRSLdCA-jZ2AHQcQZcw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--oTHb8nViIGeoXxdp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Alastair Turner (minion@decodable.me) wrote:
> On Mon, 21 Dec 2020 at 00:33, Stephen Frost <sfrost@snowman.net> wrote:
> > * Alastair Turner (minion@decodable.me) wrote:
> > > 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.
> >
> > Right- understood, but that's not what the patch does today and there
> > isn't anyone who has proposed such a patch, nor explained why we
> > couldn't add that capability later.
>=20
> I'm keen to propose a patch along those lines, even if just as a
> sample. Minimising the amount of code which would have to be unpicked
> in that effort would be great. Particularly avoiding any changes to
> data structures, since that may effectively block adding new
> capabilities.

Ok, sure, but are there such changes that would need to be made for this
case...?  Seems to only be speculation at this point.

> > > 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.
> >
> > This seems a bit confusing as the question at hand is the on-disk format
> > of the internal keyring, not anything to do with an external keyring
> > (which we wouldn't have any storage of and so I don't understand how it
> > makes sense to even discuss the idea of storage for the external
> > keyring..?).
>=20
> A requirement for validating the keys, no matter which keyring they
> came from, was mentioned along the way. Since there would be no point
> in validating keys from the internal ring twice, storing the
> validation data (HMACs in the current design) separately from the
> internal keyring's keys seems like it would avoid changing the data
> structures for the internal keyring when adding an external option.

This doesn't strike me as very clear- specifically which HMACs are you
referring to which would need to be stored separately from the internal
keyring to make it possible for an external keyring to be used?

> > Again, we will need the ability to perform the encryption using a simple
> > passphrase provided by the user, while using multiple randomly generated
> > data encryption keys, and that's what the latest set of patches are
> > geared towards.  I'm generally in support of adding additional
> > capabilities in this area in the future, but I don't think we need to
> > bog down the current effort by demanding that be implemented today.
>=20
> I'm really not looking to bog down the current effort.

Great, glad to hear that.

> I'll have a go at adding another keyring and/or abstracting the key
> wrap and see how well a true peer to the passphrase approach fits in.

Having patches to review and consider definitely helps, imv.

Thanks,

Stephen

--oTHb8nViIGeoXxdp
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJf4Aq/AAoJEO1sijiDR2RVW7EP/jeg/7liJy8kVaeB+bD3uhCD
2PGdCHkPh2qYUiN/9HbMMLwBK5oaH15/5kjRPsd+ULhiAhXslLkVAnBTtJtDJF4L
1+ws+f//Q/IomBKQPs75ampD6KzGc36Mr9NstiZkVUXqpAfuTM43peeOPvRxxF1q
LztgOMEFfn6+YmE34QudRTEerrT7VNWJ9XGIe3/CvxBUNtF7MFv05zei8RgASGo+
1J99FH/pKuoBSBgueIFRKrN8O9Qi4/ho277q523hUlVvp2/ed/2qRq504C22uXLh
pGB+XS3Uqa8O7lM9cbSo1H7RYCokpPPCTwlKdOsLGHXEGNjOIJWAXu8CYEiYAE1w
7zU7wO2AF40LXe0oAghOsMcLexBKBzHQwRg8P9Q+v4ALmjaF1dW4Dn6uPkyGXO1P
GVk5VHlxS0Dt5anSyQnX9ZBiLgPfik112MQWo2PbvQvLGnSnR5g2fTq112ad4+c5
PHgcOqYG4AN3ChhOdQYyy7evZypDfBdOf0muVi5oFv5kPTk+wnk6Icv6jzLDbK8k
w8hwkfGEiV6cHCbdps97IipsgJM8FGYMJJaBIXwFWv/FbQP4sxZ2Zz2K5/ZsbL8m
oZlOvdRAc1jZCTOXrrrkgQchKiL7uyCRLK5YsKTiCXsMQXgGkTConaHhovjZsl/u
xEjtDWwAIboOuV1opVmc
=5D2e
-----END PGP SIGNATURE-----

--oTHb8nViIGeoXxdp--