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>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users