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

[Andrew Luke Nesbit]

On 23/09/2018 21:19, Daniel Kahn Gillmor wrote:
> On Sun 2018-09-23 18:18:13 +0200, Peter Lebbing wrote:
>> The intent of this mail is not to ask whether something works. This can
>> be easily verified. It's asking whether it is a supported way of doing
>> things. I hope I can get some guidance on this!
> 
> I appreciate that you're asking for clarification about what is the
> scope of GnuPG's "API", such as it is.  We do need more clarity here.
> 
> i don't have the authority to answer your questions about the contents
> of ~/.gnupg/private-keys-v1.d/, but i'd always thought that the
> internals of ~/.gnupg/ were *not* part of the "API", and generally
> should not be relied upon.  I hope that Werner or someone else more
> closely related to the project can clarify here.

This raises interesting questions regarding subkeys.

For example, earlier this month there was a short thread with "Subject:
Subkeys" where OP was asking about generating subkeys.  The advice was
to consult https://wiki.debian.org/Subkeys .  That page contains the
following instructions:

> [...] delete the file `$HOME/.gnupg/private-keys-v1.d/KEYGRIP.key`,
where `KEYGRIP` is the "keygrip" of the master key which can be found by
running `gpg2 --with-keygrip --list-key YOURMASTERKEYID.`"

All other sources of information for generating subkeys that I have seen
contain similar instructions.

This is using the contents of `~/.gnupg/private-keys-v1.d/` as an API.
If this is *not* part of the API, then what *is* the official
recommendation for generating subkeys?

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

[Daniel Kahn Gillmor]

On Sun 2018-09-23 18:18:13 +0200, Peter Lebbing wrote:
> The intent of this mail is not to ask whether something works. This can
> be easily verified. It's asking whether it is a supported way of doing
> things. I hope I can get some guidance on this!

I appreciate that you're asking for clarification about what is the
scope of GnuPG's "API", such as it is.  We do need more clarity here.

i don't have the authority to answer your questions about the contents
of ~/.gnupg/private-keys-v1.d/, but i'd always thought that the
internals of ~/.gnupg/ were *not* part of the "API", and generally
should not be relied upon.  I hope that Werner or someone else more
closely related to the project can clarify here.

> While I'm at it: there are conflicting opinions on whether it is okay to
> build a keyring using:
> $ gpg --export SOMEKEY >pubring.gpg
> instead of:
> $ gpg --export SOMEKEY | gpg --no-default-keyring --keyring ./pubring.kbx
>
> Can we also get official guidance on that; is the former acceptable?
> (FWIW, I've always thought it was not.)

The former statement is a way to create a simple, exported OpenPGP
"transferable public key" (TPK) of the form described in RFC 4880.  This
is the most interoperable form, 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.

Traditionally, GnuPG keyrings have been just a linear concatenation of
TPKs interspersed with "Trust Packets".  The more modern keybox (the
default in 2.1 and going forward) is different from that format, though.

The latter statement doesn't even have a GnuPG command on the tail end
of the pipe, but i assume you intended for it to be --import.  is that
right?

In that case, it creates a keyring of whatever format the current
version of gpg uses by default.  But the real question is: why do you
need this, and what do you intend to do with it?  creating a keyring for
a specific version of GnuPG may be useful in some contexts, but it's
also pretty dicey to use in many other contexts.

Perhaps explaining what you're looking to do with this file you're
creating would help to decide whether the latter form is better for your
purpose.

Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

[Peter Lebbing]

Hi all,

The intent of this mail is not to ask whether something works. This can
be easily verified. It's asking whether it is a supported way of doing
things. I hope I can get some guidance on this!

On 23/09/2018 15:38, Peter Lebbing wrote: 
> The context is that for Debian's cryptsetup, I'm trying to determine
> whether all secret (sub)keys in a homedir are stubs (serial numbers or
> empty stubs). And the reason is that I'd like to error out if there is
> any actual confidential data in the private keyring, instead of copying
> it to the unencrypted initramfs. A password-protected on-disk key is a
> major red flag despite its password protection.

So this ran into a major mistake on my part. Not all keys in
private-keys-v1.d will be listed with this method, plus it launches an
agent which in this case is a no-go.

The situation with regard to which parts of the homedir are
implementation details and which are an API is a bit muddled IMHO. For
instance, we're supposed to be creating and editing *.conf files and
access revocation certificate files in openpgp-revocs.d, but a lot of
the rest is "Don't touch".

Would it be okay to scrub the private-keys-v1.d directory so it will
only hold KEYGRIP.key for that one smartcard stub we want to have? I'm
talking about a separate, special-purpose homedir, not the regular user
homedir, let's not scrub private-keys-v1.d there :-D.

That's the specific way of asking the question. A more general question
would be: in GnuPG 2.1+, can we expect the private key with grip X to be
at private-keys-v1.d/X.key and will an agent be happy to work on a
private-keys-v1.d with just files X.key, Y.key and Z.key when we
actually only need private keys X, Y and Z? Or is this an implementation
detail?

While I'm at it: there are conflicting opinions on whether it is okay to
build a keyring using:
$ gpg --export SOMEKEY >pubring.gpg
instead of:
$ gpg --export SOMEKEY | gpg --no-default-keyring --keyring ./pubring.kbx

Can we also get official guidance on that; is the former acceptable?
(FWIW, I've always thought it was not.)

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Exact definition of token S/N field for --with-colons

[Peter Lebbing]

doc/DETAILS says this about the output of --with-colons listings:

> *** Field 15 - S/N of a token
> 
> Used in sec/ssb to print the serial number of a token (internal
> protect mode 1002) or a '#' if that key is a simple stub (internal
> protect mode 1001).  If the option --with-secret is used and a
> secret key is available for the public key, a '+' indicates this.

This suggests that a '+' is only output for --with-secret --list-keys,
but I see it as well in --list-secret-keys. Running gpg 2.1.18-8~deb9u2
from Debian stretch/stable. The specification leaves some interpretation
room.

- Is '+' output iff it is an on-disk key, both on --with-secret
  --list-keys and --list-secret-keys?
- I see S/N's on --with-secret --list-keys, is there even a need to
  mention --with-secret separately or is field 15 completely identical
  for both invocations?
- Is field 15 ever anything else than a serial number, a '#' or a '+' on
  --list-secret-keys? I presume the answer is "this may change in the
  future", but I mean currently.

The context is that for Debian's cryptsetup, I'm trying to determine
whether all secret (sub)keys in a homedir are stubs (serial numbers or
empty stubs). And the reason is that I'd like to error out if there is
any actual confidential data in the private keyring, instead of copying
it to the unencrypted initramfs. A password-protected on-disk key is a
major red flag despite its password protection.

Not all of my questions directly pertain to this use case, I'm just
trying to get a good feel for the field to be able to reason about it.

My attempt at bailing on confidential data is here:

and it is this:

--8<---cut here---start->8---
#!/bin/sh

UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | 
\
gawk -F: '$1=="sec" || $1=="ssb" \
{ if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')

if [ -n "$UNSAFEKEYS" ]; then
echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
exit 1
fi
--8<---cut here---end--->8---

It will only accept true OpenPGP smartcard keys (matched on ISO 7816
Application Identifier) or empty stubs (no secret key whatsoever). No
other secret key material should be necessary for this particular
application. Note that the dialect (or lack thereof) is dash; if run in
bash, echo would need -e.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users