You need to look at the OpenPGP card specification (version 2.2, here):

... and indeed SELECT FILE has a very specific meaning and needs to be fixed in card-openpgp.c

card-openpgp.c in pgp_match if the ATR does not match it will use
if (SC_SUCCESS == iso_ops->select_file(card, &partial_aid, NULL)) {
to try and select the AID. But iso_ops->select_file adds P2='0C' because of the NULL thus causing the command to be an applet specific command rather then a SELECT AID. This cause it to fail on a multi applet card such as the Yubikey when some other applet is already selected.

In pgp_init it uses if (SC_SUCCESS == iso_ops->select_file(card, &partial_aid, &file)) { so P2='00'
The code then goes on to get the full AID and do some more testing.

The simple fix:

diff --git a/src/libopensc/card-openpgp.c b/src/libopensc/card-openpgp.c
index 12e048a..6058489 100644
--- a/src/libopensc/card-openpgp.c
+++ b/src/libopensc/card-openpgp.c
@@ -333,11 +333,12 @@ pgp_match_card(sc_card_t *card)
        else {
                sc_path_t       partial_aid;
                unsigned char aid[16];
+               sc_file_t       *file = NULL;
 
                /* select application "OpenPGP" */
                sc_format_path("D276:0001:2401", &partial_aid);
                partial_aid.type = SC_PATH_TYPE_DF_NAME;
-               if (SC_SUCCESS == iso_ops->select_file(card, &partial_aid, NULL)) {
+               if (SC_SUCCESS == iso_ops->select_file(card, &partial_aid, &file)) {
                        /* read information from AID */
                        i = sc_get_data(card, 0x004F, aid, sizeof aid);
                        if (i == 16) {

introduces a memory leak of the sc_file and does not try and get the full AID like in pgp_init. It is not clear if not having the full AID is needed to use with the sc_get_data.

@frankmorgner it looks like you added the original code in d20290d2

Also see #391 #538 #507

The problem may be shown up now with newer Yubikey tokens that come with both PIV and OpenPGP applets and the PIV is the default applet on power up and the user wants to use the OpenSC openpgp driver.

Future issue:
Multi applet cards where the user wants to use multiple applets with OpenSC is going to become more problematic because OpenSC is built on selecting only one applet at a time, even though PKCS#11 could support more than one. P11-kit would be a solution, but I don't think it can load more then one instance of OpenSC, and even if it could how would each instance know which applet to select.

Just tested with your patch, configuration card_drivers = openpgp; and I am getting the card OpenPGP card detected and the key stored there listed properly (twice -- for each PIN, there is a slot):

$ ./src/tools/pkcs11-tool -L
Available slots:
Slot 0 (0x0): OMNIKEY AG CardMan 3121 00 00
  (empty)
Slot 1 (0x4): Yubico Yubikey 4 OTP+U2F+CCID 01 00
  token label        : User PIN (OpenPGP card)
  token manufacturer : Yubico
  token model        : PKCS#15 emulated
  token flags        : login required, token initialized, PIN initialized
  hardware version   : 2.1
  firmware version   : 2.1
  serial num         : 000606917085
  pin min/max        : 6/127
Slot 2 (0x5): Yubico Yubikey 4 OTP+U2F+CCID 01 00
  token label        : User PIN (sig) (OpenPGP card)
  token manufacturer : Yubico
  token model        : PKCS#15 emulated
  token flags        : login required, token initialized, PIN initialized
  hardware version   : 2.1
  firmware version   : 2.1
  serial num         : 000606917085
  pin min/max        : 6/127

Thank you for having a look into that!

OK, things are looking better. We know how to do a SELECT AID correctly in the OpenSC OpenPGP driver now.

But there are more issues with a multi applet tokens such as Yubikey with PIV and OpenPGP applets.

Only one appet can be active at a time. Switching between applets using SELECT AID can cause the login state for the deselected applet to be lost. The switching may be caused be some other user application and middleware OpenSC, OpenPGP, scdeamon, tokend, some Java or python based piece of software. They all need to be aware of this. P11-kit or Mozilla's NSS loading for example OpenPGP's pkcs#11 and Yubico's pkcs#11 module for PIV may end up interfering with each other as they both will need to do a SELECT AID for their applet to the token.

PCSC's SCardConnect SCARD_SHARE_EXCLUSIVE can be used to make sure no other application cause a different applet to be selected. But holding on in exclusive mode for along time defeats the purpose of having multiple applets on the same device. The first running application that requests access to the card will lock out all other applications, and is not what the user expects.

To determine if an applet is usable, or its serial number requires access to the token, and may require a SELECT AID.

To work in a SCARD_SHARE_SHARED environment, requires the each piece of middleware expect that some other piece of middleware may have done a SELECT AID for a different applet, and thus it should be ready to do a SELECT AID for its applet and maybe a verify. The OpenSC card-piv.c tries to do this
with the Yubico devices, but I don't think the OpenSC card-openpgp.c does. (TODO Some opensc/openpgp developer (not me) needs to look at doing SELECT AID for every transaction. Look at the card-piv.c and look at CI_OTHER_AID_LOSE_STATE and uses of piv_select_aid)

PCSC did not go far enough. It can report a card reset, of disconnect, but not a change in AID.

And all the above assumes the applications are using PCSC. If the token is accessed some other way its not clear.

Some careful examination of the EF.DIR might be in order. But standards like NIST 800-73 and OpenPGP lists the commands they support, including SELECT AID but do not require an EF.DIR, or require commands to support for a file system, so there may be tokens without an EF.DIR.

Some careful examination of the EF.DIR might be in order. But standards like NIST 800-73 and OpenPGP lists the commands they support, but do not require an EF.DIR, or support for a file system, so there may be tokens without an EF.DIR. (TODO look if OpenSC could try and read the EF.DIR and pass it to the card drivers during the card match. This could avoid doing a SELECT AID and interfering with some other middleware.

Needless to say, this is a can of worms. All the different middleware assume one applet (theirs) is the only applet on the token, and they can have exclusive access. Only when all the middleware addresses the use of multiple applets on a token, where the user wants to use more then one applet will this get resolved.

Maybe Yubico could resolve this on the next Yubikey release, by placing each applet in its own device so they appear as independent CCID USB devices. They already make the Yubikey look like different devices, CCID being one of them.

P11-kit or Mozilla's NSS loading for example OpenPGP's pkcs#11 and Yubico's pkcs#11 module for PIV may end up interfering with each other as they both will need to do a SELECT AID for their applet to the token.

Loading the Yubico pkcs11 module is probably the worst idea one can do, since it is very broken and nobody touches the issues reported years ago on github:

I would not consider it public PKCS#11 module, but just internal library for yubico-piv-tool (at least this is what we do in Fedora -- we do not install unversioned library and do not add it to NSS nor p11-kit). If I am right, for PKCS#11, even they recommend OpenSC in their guides.

Thank you for the verbose analysis. It clearly makes and I believe we already mentioned that using two independent CCID USB devices would be much less troublesome. Did you already try to contact yubico in this matter?

The comment about using the Yubico PKCS#11 with p11-kit was an example of unintended interference. OpenSC has the additional problem of only using one driver per card set via opensc.conf. It would take some work to get it to support the PIV and OpenPGP applets at the same time on the same card.

I sent a note today to [email protected] (which may not be active any more) and Klas Lindfors and Simon Josefsson. Who appear to still be with Yubico.

If you are anyone else have contracts at Yubico or a better way to send suggestions, let me know

@frankmorgner @Jakuje @mouse07410 or any other developer interested in Yubikey making the changes needed in card-openpgp.c?

Loading the Yubico pkcs11 module is probably the worst idea one can do, since it is very broken and nobody touches the issues reported years ago on github

I concur. That module is semi-useable at best, and exists only because some Yubikey-specific initialization parameters (like, generating a private key that requires touching the Yubikey touch-pad to allow an operation with it) aren't currently supported by OpenSC pkcs11 library.

we ... do not add it to NSS nor p11-kit.

I added it to p11-kit for the sake of completeness, but don't really use it.

If I am right, for PKCS#11, even they recommend OpenSC in their guides.

Correct.

. . . @mouse07410 or any other developer interested in Yubikey making the changes needed in card-openpgp.c?

Yes. Could you briefly summarize what the exact message/request to Yubico should be?