Interaction will be something like this:

Priority is high, because Gnuk Token requires this feature for testing its implementation.

Thank you for the clarification. For now, I'll modify our implementation to use shorter length representation and close this bug as Invalid.
However, I'm still not convinced that using hard-coded arguments is the right way to handle requests. I'll do some more testing and if I discover a legitimate use-case that requires long APDUs, I'll reopen the issue.

Thanks for the information.

In our implementation, DO 0x6E contains:

I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?

Here is a sequence of operations/commands that permits to setup or update KDF-DO and align PIN codes accordingly:

Now there it gets complicated. According to the card software author in 3.3 and even 2.2 there is a fix. BUT there was a small amount of cards already created in 3.3 without the fix. Nobody ever told my how to diferentiate them.
There is no Version 3.3.1 you can by - it is only 3.3. So you can buy one and hope you have a good one.
At least this is my understanding.

Does v3.3.1 fix this? (The release notes for it seem to imply that's not the case.)

@nitroalex Perhaps, creating new ticker is better for this topic.
In the current OpenPGP card specification, there is no way for an application (except having a list of card implementation information) to know wich algo and which curve is supported or not.
So, what an application does is try and error.
I don't like this situation, but I don't know how we can modify the specification.

Well, I surely would agree (and this is only a proposal anyway), but my point here is, that OpenPGP Card does not support Curve 25519, so that one *have to* choose between those other two. Considering me a tinfoil hat person, I would rather not choose NIST, as many others wouldn't too.

Neither Brainpool nor NIST curves make any sense unless there is an organizational policy requirement. Thus the --expert requirement is the Right Thing (tm).

works just fine, thx!

For the situation where PINs are not factory setting, given the specification, I don't know how to achieve "to align all PWs and the KDF-DO with correct values"; It might depend on card's implementation.

You are right about the fact that multiple steps could result in unusable cards in case of power down before all commands have been issued. Nevertheless, in practice, these commands would involve very few treatments on the token (i.e. no cryptographic operation or heavy data transfer) and it should really not take long to complete the three steps (admin PIN update, user PIN update, KDF-DO update).

Workaround is implemented in 2.2.6.

Fixed in 2.2.6.

My interpretation of the specification is different.
By requiring the condition of setting KDF-DO (it is only valid to setup KDF-DO when PINs are factory setting), Gnuk works well with current "kdf-setup".
If the procedure of setting KDF-DO includes multiple steps with KDF-DO update and PIN update, there is a risk of power down which results unusable card.

Yes, I meant the document. Please note that I am also one of users of the specification (for GnuPG, and for Gnuk Token). I am not defending, but try to explain the current situation.

I was referring to this document:

You describe it as 'manual'. AFAIK, it's the specification for the functionality.
I have an experience implementing the functionality, following the specification.
And my own implementation does always return 512 bytes for RSA-4096. So, I could support your opinion.

I realized that KDF support may be incompatible to Gnuk's feature of "admin-less" mode.
I'm going to implement compatible KDF support to Gnuk; That is, KDF data which only has a single salt.
In this case, all KDF calculation (user, reset-code, and admin) is done with the single salt.
With single salt, admin-less mode can work with no problem.

Furthermore, I changed to have an explicit command: key-attr