[FlorianFranzen]

Yubico ecosystem clients (ykman, yubico-piv-tool, yubikey.rs) send case 3 APDUs without an Le byte and never issue GET RESPONSE after a plain SELECT. apdu-dispatch currently treats the absent Le as "no response data expected" and answers 61XX with the data held back, which loses those clients entirely. A real YubiKey returns up to 256 bytes directly and chunks only what exceeds that over GET RESPONSE.

Covered by a new echo_without_le dispatch test; also validated end to end against ykman and yubikey.rs through piv-authenticator's vpicc virtual card.

[robin-nitrokey]

Thank you for bringing up this issue. The ISO 7816-4 standard explicitly says (§ 5.1):

L_e field: Absent for encoding N_e = 0, present for encoding N_e > 0
N_e denotes the maximum number of bytes expected in the response data field. The L_e field encodes N_e.
If the L_e field is absent, then N_e is zero.
Therefore in any command-response pair, the absence of L_e field is the standard way for receiving no response data field.

For the SELECT command specifically, it says (§ 7.1.1):

If the L_e field is absent, i.e., for returning no file control information, then the response data field shall also be absent.

So I think we implement the specified behavior correctly and I’m reluctant to deviate from the spec just because the Yubikey does so. Or do you see a reason why this behavior would also be covered by the standard?

[FlorianFranzen]

Wow, you are completely right. Turns out yubikey.rs just treated 61XX after SELECT as an error (iqlusioninc/yubikey.rs#663). 🤦

I was debugging this to long, I just convinced myself this must be the issue. Looked at the trace logs again and ykman actually never showed that behavior.

Anyhow, sorry for the noise.