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

[Andrew Gallagher]

> On 10 Nov 2018, at 00:57, Dirk Gottschalk via Gnupg-users 
>  wrote:
> 
> I suggest using a Cron job, or a SystemD timer and service to do a
> refresh on a regular base.

I’ve found parcimonie to be useful. 

https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/

A___
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)

[Dirk Gottschalk via Gnupg-users]

Hello Stefan.

Am Samstag, den 10.11.2018, 00:41 +0100 schrieb Stefan Claas:

> Thanks too, Dirk,

> i already made a refresh.

Yeah, I read it right after I sent my Email.

I suggest using a Cron job, or a SystemD timer and service to do a
refresh on a regular base.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
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)

[Stefan Claas]

On Sat, 10 Nov 2018 00:00:18 +0100, Dirk Gottschalk wrote:
> Hi Stefan.
> 
> Am Freitag, den 09.11.2018, 16:18 +0100 schrieb Stefan Claas:
> > On Fri, 9 Nov 2018 16:12:19 +0100, Peter Lebbing wrote:
> > 
> > [snip]
> > 
> > I get a valid signature but key has expired message, when
> > reading your posting.
> > 
> > Regards
> > Stefan  
> 
> Peters key is valid. Probably you have to refresh it or you are
> running into an issue I had a while ago with my keyring. Try to
> delete and re- import his key. In my case something with the
> pubring.kbx went wrong. In my case some of the keys were considered
> invalid without a reproducable reason.

Thanks too, Dirk,

i already made a refresh.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas


pgphf_Phe3Q0k.pgp
Description: Digitale Signatur von OpenPGP
___
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)

[Dirk Gottschalk via Gnupg-users]

Hi Stefan.

Am Freitag, den 09.11.2018, 16:18 +0100 schrieb Stefan Claas:
> On Fri, 9 Nov 2018 16:12:19 +0100, Peter Lebbing wrote:
> 
> [snip]
> 
> I get a valid signature but key has expired message, when
> reading your posting.
> 
> Regards
> Stefan

Peters key is valid. Probably you have to refresh it or you are running
into an issue I had a while ago with my keyring. Try to delete and re-
import his key. In my case something with the pubring.kbx went wrong.
In my case some of the keys were considered invalid without a
reproducable reason.

Regards,
Dirk

PS: My system makes a nightly key refresh. Probably the expiry date was
changed shortly.

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

[Stefan Claas]

On Fri, 9 Nov 2018 16:40:18 +0100, Peter Lebbing wrote:
> On 09/11/2018 16:18, Stefan Claas wrote:
> > I get a valid signature but key has expired message, when
> > reading your posting.  
> 
> In that case you should refresh your copy of my public key from the
> keyservers or from the URL in my signature:
> 
> $ gpg --refresh-keys pe...@digitalbrains.com

Thanks, now it is o.k. 

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas


pgp3fK8mQzwa2.pgp
Description: Digitale Signatur von OpenPGP
___
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)

[Guilhem Moulin]

Hi,

On Fri, 09 Nov 2018 at 16:12:19 +0100, Peter Lebbing wrote:
> On 07/10/2018 03:01, Daniel Kahn Gillmor wrote:
>> Does this make sense?  you just need to make sure you tie the version of
>> gpg and the keyring into the same initramfs build time.
> 
> The problem is that the gpg invocation is not at the time of building
> the initramfs.

It wasn't, but the hook file is a mere shell script where we can do
pretty much everything (as long as it's nullipotent from the main
system's perspective — besides creating the initramfs image of course).
In fact I implemented dkg's suggestion:

gpg --homedir="$DESTDIR/cryptroot/gnupghome" … --import <"$PUBRING"

is called by the hook file when the initramfs image is generated, using
the very same gpg(1) binary that's copied to the initramfs.  Hence we're
not relying on its homedir's internals, and we're safe as long as gpg(1)
is able to make use of the homedir content it generates (which is
definitely a reasonable assumption), even if the ‘gnupg’ package is
later is upgraded to a version with a different keyring format or file
name, and diverges from the version included in the initramfs image.
(In fact the ‘gnupg’ package can even be deleted on systems where one is
certain that the initramfs image won't be updated anymore.)

> I have an idea about elegantly handling the fact that the smartcard stub
> is not known during boot, since there doesn't seem to be a stable
> interface to transferring these stubs, and invoking gpg at initramfs
> build time will leave a running gpg-agent, which is rather avoided. I'll
> work this out when I have the time.

I look forward to see that! :-)  FWIW it's not the `gpg` invocation
during initramfs generation that's a blocker, but the fact that listing
secret key material spawns a gpg-agent(1) process hence breaks
nullpotency.  We could make make the hook nullpotent, but at the expense
of a brittle and racy logic I'm reluctant to write or merge in to
‘cryptsetup-initramfs’.

Cheers,
-- 
Guilhem.


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

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

[Peter Lebbing]

On 09/11/2018 16:18, Stefan Claas wrote:
> I get a valid signature but key has expired message, when
> reading your posting.

In that case you should refresh your copy of my public key from the
keyservers or from the URL in my signature:

$ gpg --refresh-keys pe...@digitalbrains.com

or

$ gpg --fetch-keys http://digitalbrains.com/2012/openpgp-key-peter

or whatever method you prefer, possibly through your favourite frontend.

FWIW, my key's latest expiry was in October 2017, and then it was
refreshed until October 2019. At least, that's what it looks like to me.
I don't think I made a mistake somewhere, but it could be :-).

HTH,

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

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

[Stefan Claas]

On Fri, 9 Nov 2018 16:12:19 +0100, Peter Lebbing wrote:

[snip]

I get a valid signature but key has expired message, when
reading your posting.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas


pgpjJrfGjd4Uh.pgp
Description: Digitale Signatur von OpenPGP
___
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)

[Peter Lebbing]

Daniel, many thanks for thinking about this! I'm sorry I didn't respond
earlier.

On 07/10/2018 03:01, Daniel Kahn Gillmor wrote:
> Does this make sense?  you just need to make sure you tie the version of
> gpg and the keyring into the same initramfs build time.

The problem is that the gpg invocation is not at the time of building
the initramfs. gpg is only invoked once during setup of the
smartcard-encrypted root. In the end, the --export during setup and
--import during early boot is probably the best alternative; since it's
an --import to an empty keyring, this shouldn't waste much time during
every boot anyway.

I have an idea about elegantly handling the fact that the smartcard stub
is not known during boot, since there doesn't seem to be a stable
interface to transferring these stubs, and invoking gpg at initramfs
build time will leave a running gpg-agent, which is rather avoided. I'll
work this out when I have the time.

> I don't know the answer to this about using concatenated TPKs as
> keyring.  Maybe Werner can weigh in?

Yes, I think it's useful to know what is a stable interface and what is
not, so I hope he will.

Thank you,

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

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

[Daniel Kahn Gillmor]

On Mon 2018-09-24 12:44:38 +0200, Peter Lebbing wrote:
> 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.

I think you're right that this is an "always-correct" option.

But i note that when assembling an initramfs, you have to choose which
version of GnuPG you put in it.  And i also note that the initramfs is
typically never modified once created: rather, a new one might be
created and swapped in.

This suggests that at time of initramfs creation, you can use your
suggested "--no-default-keyring --keyring foo.kbx --import" approach
(using the version of gpg that you are also packing into the initramfs),
and you can be confident that it will work in the initramfs, because the
version of gpg and the keyring will match.  In this case, you only need
to --import at initramfs creation time, and you can avoid the extra
--import at initramfs-run-time.

Does this make sense?  you just need to make sure you tie the version of
gpg and the keyring into the same initramfs build time.

> 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?

I don't know the answer to this about using concatenated TPKs as
keyring.  Maybe Werner can weigh in?

But GnuPG *will* forever continue to consume concatenated TPKs via
--import -- that's the OpenPGP interoperable format, and if GnuPG stops
consuming it on --import, it would no longer be an OpenPGP
implementation.

Regards,

 --dkg


signature.asc
Description: PGP signature
___
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 Mon 2018-09-24 01:09:25 +0100, Andrew Luke Nesbit wrote:
> 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?

The part of those pages about "generating subkeys" does use the GnuPG
API.

So I think the question you're asking is "what is the official
recommendation for deleting the cryptographic secret associated with the
master key?"

I agree that it would be nice if there was a clear, supported API for
doing that.  I suspect it would be something like:

  gpg-connect-agent "delete_key $KEYGRIP" /bye

(and you probably want to get the keygrip via

   gpg --with-colons --with-keygrip $FINGERPRINT

)

This clearly isn't a usable situation for most users, so it's primarily
important to document it so that more usable tools can be written that
know how to safely interact with GnuPG under the hood.

 --dkg


signature.asc
Description: PGP signature
___
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)

[Guilhem Moulin]

Hi there,

On Sun, 23 Sep 2018 at 16:19:22 -0400, Daniel Kahn Gillmor wrote:
> But the real question is: why do you need this, and what do you intend
> to do with it?

I believe it was a follow up to https://bugs.debian.org/903163, messages
≥160 in particular.  TL;DR: for smartcard usage (decryption in our case)
at initramfs stage we need a public keyring containing the relevant
public key(s), and copy it into the initramfs image.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature
___
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)

[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 



signature.asc
Description: OpenPGP digital signature
___
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)

[Wiktor Kwapisiewicz via Gnupg-users]

On 24.09.2018 02:09, Andrew Luke Nesbit wrote:
> 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?

I'm not in a position to suggest "official" recommendations but one
alternative that doesn't touch .gnupg is using secondary computer
(offline, air-gapped if possible) to store secret keys and either:

1) "keytocard" them or
2) --export-secret-keys one by one.

Kind regards,

Wiktor

-- 
https://metacode.biz/@wiktor

___
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)

[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