Long Term Key Management With Hardware Tokens

[Brandon Anderson]

> 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
>
Those are great points; I had not thought of those use-cases! I only 
used the term retirement slots because it was an existing term used in 
PIV smartcards, but we could just call them alternative slots, 
supplemental slots, auxiliary slots, peripheral slots, secondary slots, 
or anything really, so long they can hold old keys decryption keys; my 
use-case is met.

Thanks for posting about the PivApplet project. I was looking for 
something like that for either the basic cards or java cards as I wanted 
to tinker around with them. Do you have a specific Java card model you 
are using?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x255837AEF812E87E.asc
Type: application/pgp-keys
Size: 9076 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210625/e2b18497/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210625/e2b18497/attachment.sig>