GPG, subkeys smartcard and computer

[Peter Lebbing]

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.

Cheers,

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: </pipermail/attachments/20170221/9e3ca9e4/attachment-0001.sig>