Based on comment in main ticket I suspect my PR doesn’t handle if key can’t be read. Weird because I only have two certificates and it works for me. Will need to look at this if I can find a problem. Perhaps it’s ok if slot 9a has a valid certificate and others get ignored.

EDIT: no, I can't find a problem.
EDIT 2: found the problem.

I noticed that I had forgotten to commit the private key part of my change for supporting alternate key slots. With the older version the code failed to sign as it tried to use the first slot private key with the public key of the other slots.

EDIT: I need to get some sleep, looks like. Earlier timings were wrong because the faster sign-in failed. D'oh.

Before caching signers (retrieving all 4 certificates):

23:26:04.977937 main.go:138: healthy: 6.390402ms
23:26:04.978475 main.go:151: ensureYkLocked: 6.931901ms
23:26:04.981069 main.go:261: getPublicKey: 2.576495ms
23:26:04.981790 main.go:261: getPublicKey: 698.492µs
23:26:04.984173 main.go:261: getPublicKey: 2.372677ms
23:26:04.984849 main.go:261: getPublicKey: 659.378µs
23:26:04.984859 main.go:226: List: 13.31911ms
23:26:05.632506 main.go:138: healthy: 8.135289ms
23:26:05.633340 main.go:151: ensureYkLocked: 8.975186ms
23:26:05.636000 main.go:261: getPublicKey: 2.644408ms
23:26:05.774866 main.go:261: getPublicKey: 3.188217ms
23:26:05.910598 main.go:290: signers: 277.2486ms
23:26:05.981258 main.go:324: SignWithFlags: 356.880247ms

After caching signers, showing significant speedup:

23:13:30.498797 main.go:141: healthy: 6.108291ms
23:13:30.499358 main.go:154: ensureYkLocked: 6.671232ms
23:13:30.502525 main.go:269: getPublicKey: 3.149611ms
23:13:30.503285 main.go:269: getPublicKey: 732.616µs
23:13:30.505628 main.go:269: getPublicKey: 2.330273ms
23:13:30.506291 main.go:269: getPublicKey: 648.202µs
23:13:30.506299 main.go:234: List: 13.616576ms
23:13:31.158748 main.go:141: healthy: 8.431034ms
23:13:31.159461 main.go:154: ensureYkLocked: 9.149914ms
23:13:31.229363 main.go:336: SignWithFlags: 79.049619ms

Just to update this PR status. I'm hoping to get feedback whether it's welcome to support multiple slots per key. This PR supports both multiple slots and multiple keys - which arguably could be split to separate PRs.

Personally I only care about the multiple slots - I'm happy to rebase and improve based on review comments. I won't rebase only for the multiple Yubikeys. I can rebase the multiple slots after receiving some feedback what are the conditions to get that merged, and if possible, I'd welcome some help getting consistent benchmarks so we know if adding multiple slot support degrades performance for most users or not.

I don't mind at all if someone picks the multiple yubikeys part of this PR and makes a cleaned up and new PR on it. I will not.

My 2c: multiple slots has the most straightforward use-case (as per #22), and I don't understand the use-case for multiple keys.

Let me rebase and start again, including only "load all slots".

@joneskoo @smlx For what it is worth, I actually think support for multiple YubiKeys would be stellar.

One use case: I keep a YubiKey 5c nano in my macbook as long as I'm at home or in the office; it is convenient and easy. But, I maintain slightly higher security by keeping a separate YubiKey 5c NFC for more sensitive credentials / services / systems.

You could also easily picture not wanting to intermingle identities / credentials related to personal projects and work projects, but occasionally wanting to log in to a personal system from work.