GPG, subkeys smartcard and computer
peter at digitalbrains.com
Tue Feb 21 15:15:09 CET 2017
On 21/02/17 14:37, Kristian Fiskerstrand wrote:
> Who said anything about creating a new one in this part of the process?
Since I assumed you were siting behind a trusted machine with your
primary key installed when you revoke, it made no sense to me to just
revoke the key and not create a new one, as you are sitting there in
"gpg --edit-key" with your primary unlocked anyway.
But the rest of the mail makes clear this was not your assumption.
> (this step is actually the most tricky, as
> revocation certificates can't be generated for subkeys - so you need to
> have pre-generated versions of pubkey with it revoked created carefully
> manually beforehand).
Yes, I had kinda assumed that this was not the level of trickery we were
willing to go to when suggesting people to use multiple A subkeys. It's
not even a feature of GnuPG, it's just being clever.
>> certificate would have to be revoked. I don't see much extra effort in
>> rolling it out to the few other systems you use as a client as well.
> not following, you don't have access to the primary key at this point
> (say you're travelling and the primary is on smartcard in a vault)
I did assume that you need the primary to do the revocations, as GnuPG
does not support revocation certificates for subkeys. So I assumed you
could only mitigate the compromise when seated behind your most trusted
system, or something to that effect.
> Whether need for "right now" depends on severity, the compromise is in
> most cases a lost device
I suppose we were working with different definitions of "compromise".
Yours makes more sense. Mine was too narrow.
> so a 20-30 min
> timeframe is likely sufficient in most cases anyways e.g from a regular
> crontab run of monkeysphere, this also should fit with most key
> propagation across network as using a single keyserver can create a SPOF
> and DoS the update
If Kristian Fiskerstrand says it's okay for SSH servers to refresh their
keyring every 20 or 30 minutes from the public keyserver netowrk, then I
guess it really is :-). I had estimated it as inappropriate.
Okay, you have convinced me. To deal with the pyhsical loss of a device
or the medium holding the private key, it makes sense to create an
OpenPGP auth-capable subkey per device. However, the revocation trickery
limits its user-friendliness in a big way.
Thanks for expanding my understanding of this area.
It's still not for me though. I often need to be able to grant access on
a per-client basis. I try to limit access to accounts to client devices
where I actually need it, to somewhat limit the consequences of a single
client machine being compromised. It's not a panacea, more of a defense
in depth thing.
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...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users