GPG, subkeys smartcard and computer

[Andrew Gallagher]

On 21 Feb 2017, at 13:37, Kristian Fiskerstrand <kristian.fiskerstrand at sumptuouscapital.com> wrote:

>> On 02/21/2017 02:21 PM, Peter Lebbing wrote:
>> Revoking the old A key and creating a new one needs to happen on the
>> system you have the primary key on, so you need to subsequently roll out
> 
> Who said anything about creating a new one in this part of the process?

I did. In my original scenario, since you have to load up your primary key in order to revoke the compromised subkey, there's little extra effort involved in creating a new subkey while you're at it. (Yes, you could have prepared offline subkey revocations, but as you say this is very poorly supported and I wouldn't recommend it to anyone)

I'm not convinced having different A subkeys for each client device is useful. If one of your A subkeys gets compromised, all your servers are vulnerable until such point as your revocation gets pushed, and after which point any new subkeys will also have been pushed. So rolling A subkeys is an atomic operation on the server no matter what way you go about it or whether you have subkeys created in advance. On the other hand, if you have separate A subkeys for each *server*, then why not make life easy for yourself and just use separate primaries? 

Distributing revocations is the Achilles heel of every PKI. I don't know of any that has definitively solved it. 

A