Yubikey enhancement: adds feature set to support multiple slots

[bsingh-kpt]

Following features are implemented:

1. Multiple slots of yubikey can be used
2. Algorithm support include: RSA2048 and RSA3072 for yubikey type only
3. --keytype options enhancement. For yubikey and for each key type SB hierarchy algorithm and slot can be specified. For example, to create a RSA3072 key in slot 9a, --keytype yubikey:RSA3072:9a can be used. Different algorithm and slot can be chosen for each SB key type
4. Subject DN in openssl style can also be specified for certificate generation for each key type
5. KeyConfig is enahanced to support Algorithm and slot for yubikey type only
6. Added key file existence check so that only missing keys are created with create-keys command and avoids unintentional key overwrite
7. Check key certificate first in yubikey and then fallback to its attestation cert if key cert is missing
8. Also supports yubikey retired key slots
9. Adds --prompt option to enable pin prompt for yubikey
10. Adds custom management key support when default is replaced

[Foxboron]

Generally, this is one large PR to support multiple features. Splitting things would be much easier to review.

[bsingh-kpt]

@Foxboron Did you had the time to test the changes?

[Foxboron]

I haven't had time. Sorry.

The PR is not super high on my list as the code is a big hard to review and the commit is doing several things. The description is also point list which is not great.

It would be nicer if there where multiple commits describing each atomic change.

[compujuckel]

This PR addresses a lot of the stuff I was missing, but a small issue remains:
I have a key in slot 0x82 without an accompanying certificate, so GetPIVKeyCert will fail to notice this key and sbctl will try to overwrite it. The key is imported, so GetPIVAttestationCert will not "find" it either.
Instead, KeyInfo could be used to also find private keys without a certificate.

[Foxboron]

I have a key in slot 0x82 without an accompanying certificate, so GetPIVKeyCert will fail to notice this key and sbctl will try to overwrite it. The key is imported, so GetPIVAttestationCert will not "find" it either. Instead, KeyInfo could be used to also find private keys without a certificate.

Is this related to this change? Is this an existing bug in sbctl?

[compujuckel]

Probably yeah, the same should happen if you import a key into the default slot used by sbctl. Attestation will only work when the key was generated on-device.

Basically:

• Imported key, no certificate -> neither detected by this PR or vanilla sbctl
• Imported key, imported certificate -> detected by this PR, not detected by vanilla sbctl
• On-device generated key -> always detected, certificate doesn't matter

[Foxboron]

Attestation will only work when the key was generated on-device.

Yes, you can't have attestation for something that was not created on the yubikey/hardware enclave.

Imported key, no certificate -> neither detected by this PR or vanilla sbctl
Imported key, imported certificate -> detected by this PR, not detected by vanilla sbctl
On-device generated key -> always detected, certificate doesn't matter

The first case should not work, so that is expected. The second case is fine, but it's unclear to me if it's intentionally fixed by this PR or just an artifact that we are looking at more slots.

The latter case is what the support on sbctl has been about.

[compujuckel]

The second case is fine, but it's unclear to me if it's intentionally fixed by this PR or just an artifact that we are looking at more slots

Intentionally fixed since now the stored cert is checked first before getting the attestation cert:
https://github.com/Foxboron/sbctl/pull/474/changes#diff-139951845068372dc118aaf15b7c853040ad4bdd89b375acd696bdb4a022375fR85