Long Term Key Management With Hardware Tokens

[Valtteri Vuorikoski]

Werner Koch via Gnupg-users <gnupg-users at gnupg.org> writes:

> Frankly, I am not convinced about the retirement slots on the card.
> They are of course useful if you rotate you key.  But the question is
> why you want to do this given that the keys are anyway securely stored
> on a card.

Whatever the merits of retired key slots for their intended use, there's
another use case for them which was probably not considered by NIST:
alternate certificates for X.509, SSH and similar authorization
applications to work around deficiencies in existing systems.

Examples:

  - Github allows associating one SSH public key with one account. If
    you need to operate multiple Github accounts, you need multiple SSH
    keys.

  - Support for EC certificates in the Samba KDC was broken at least as
    of version 4.10. If you need an EC certificate for SSH, you can't
    use the key associated with your AD/Kerberos X.509 certificate,
    since only RSA works for Kerberos.

  - Similarly, the OS on Mikrotik routers at least before version 7.x
    supports only RSA SSH keys.

Hence, having multiple key slots available for authorization keys is
quite convenient. It might be better to call these something else than
"retired" slots unless aiming for total terminological consistency with
PIV though.

I'm currently using pivy <https://github.com/joyent/pivy> with Yubikeys
and JavaCards with PivApplet PIV for this kind of multi-key
scenarios. It would be convenient if all external applications could go
through gpg-agent/scute in the future instead of having to deal with
pcsc-shared or similar workarounds.

 -Valtteri