GPG, subkeys smartcard and computer

[Peter Lebbing]

On 20/02/17 22:51, Kristian Fiskerstrand wrote:
> Revocation of the specific subkey is automatically picked up by all
> systems due to automatic refresh of the public key on regular intervals,
> without losing access to the system from non-compromised devices.

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
the new A key to the compromised device. Obviously I assume the primary
key was not available on the compromised device, because then the whole
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.

Also, I think you need to have a way to notify servers that they need to
get an updated certificate including the revoked old key *right* *now*.
We're talking about a compromised A key! The attacker has full access to
your login account for the time that the servers haven't checked for a
new key yet! Regular intervals just won't do. This looks to be the
painful step in the process.

The exception might be a private keyserver that gets hammered by all the
SSH servers every 10 minutes to check whether any updated keys were
uploaded. I don't think it'd be kind to do that to a public keyserver.

I'm not saying an A key per device is bad. Or even that it is not as
good as one A key. I'm just saying that, given you need to transfer
private keys anyway I don't think there's a significant difference in
practice. You can't generate these new A subkeys on the client device
itself, because it will not have the primary key of the OpenPGP
certificate. This is where the difference with plain old OpenSSH private
keys pops up: those you just generate on the client device itself and
you never have to worry about exporting and importing private keys at
all. In addition, it means you can then say "I'd never login to this
server from this client, so it needs not be in the authorized_keys
file". This kind of discrimination that provides defence in depth is not
possible with A subkeys on an OpenPGP certificate that get automatically
picked up by the servers, since they will always accept all A subkeys on
the certificate. So you lose that etra possibility you had with plain
SSH keys per client device.

Cheers,

Peter.

PS: I realised that you can't even generate the A key on the previously
compromised system only after I'd written my previous mail. So the two
stepwise processes should have been:

With A per system:

1) Create new key
2) Roll out new key to compromised system
3) Roll out new key to all server systems
4) Revoke old key on all server systems

With just one A:

1) Create new key
2) Roll out new key to all client systems
3) Roll out new key to all server systems
4) Revoke old key on all server systems

However, since Kristian is placing it in the context of servers
automatically fetching keys, it could be:

With A per system:

1) Create new key, revoke old
2) Roll out new key to compromised system
3) Poke every server system that they need to refresh *now*

With just one A:

1) Create new key, revoke old
2) Roll out new key to all client systems
3) Poke every server system that they need to refresh *now*

-- 
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/6d30ea54/attachment.sig>