Greetings,
* Alastair Turner (minion@decodable.me) wrote:
> On Sun, 20 Dec 2020 at 22:59, Stephen Frost <sfrost@snowman.net> wrote:
> > 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.
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.
> 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.
The updates are intended to make it so that the KEK which wraps the
internal keyring will be obtained directly from the cluster key command,
pushing the transformation of a passphrase (should one be provided) into
a proper key to the script, but otherwise allowing the result of things
like 'openssl rand -hex 32' to be used directly as the KEK.
> 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..?).
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.
Thanks,
Stephen