Utilizing facts of homedir organization (was: Exact definition of token S/N field for --with-colons)

[Peter Lebbing]

On 23/09/2018 22:19, Daniel Kahn Gillmor wrote:
> [...], if you're looking to export a specific key for transfer into
> any other implementation (including other versions of GnuPG).  This is
> not only "acceptable" but it is normal, standardized, and widely
> interoperable.

I'm sorry, I did a very poor job of explaining it. I'm not transferring
keys, I'm managing keyrings. This is all with the same version of GnuPG.

And yes, I simply forgot to type the --import command.

The context is that we want to build a keyring for a specialized runtime
environment. We will be invoking gpg in the initramfs stage, to get
decryption keys for encrypted filesystems. It's still the same computer
running the same software (same gpg), but the normal filesystems are not
available yet.


So what there is now is this:

Preparation:
# gpg --export 0xDEADBEEF >/etc/cryptsetup-initramfs/pubring.gpg

This pubring.gpg gets copied into the initramfs at /cryptroot. During
early boot, the following gets executed (with an empty homedir in
default location):

# gpg --no-options --trust-model=always --no-default-keyring --keyring=/cryptroot/pubring.gpg --decrypt -- /etc/keys/cryptkey.gpg

I objected to this on the grounds that it is using what I have thought
for years is an implementation detail. Up to GnuPG 2.1, keyrings were
simple concatenated OpenPGP exported format certificates. Even though it
might work, even with GnuPG 2.1+, I thought building keyrings by
concatenating --export was considered not an API. So I proposed:

# gpg --export 0xDEADBEEF | gpg --no-default-keyring --keyring /etc/cryptsetup-initramfs/pubring.kbx --import

Note how we're not even changing the homedir or the executable, it's
just the same GnuPG version talking to itself, but with a different
destination keyring for --import. Okay, it also doesn't have the default
keyrings anymore during this one invocation. This does have some 
implications, the invocation might not be optimal yet.

Copy the pubring.kbx to /cryptroot in the initramfs. During subsequent
early boot (again, default but empty homedir):

# gpg --no-options --trust-model=always --no-default-keyring --keyring=/cryptroot/pubring.kbx --decrypt -- /etc/keys/cryptkey.gpg

Just the extension of the keyring changed. Extensions here are a hint
for the user anyway, GnuPG doesn't seem to care.

The always-correct option would be to --export, copy the exported key to
the initramfs, and simply --import it before use, no meddling with
prefabricated keyrings. It does waste some processing.

So have I been too strict all these years? :-) Are we free to build
keyrings with --export and will GnuPG happily consume them as an
always-supported fallback?

Thanks,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180924/c9627112/attachment.sig>