Correctly handle a card with multiple PKI applications (e.g. PIV *and* PGP)

[dengert]

Smart card appications these days can be loaded on many different cards. Yet OpenSC still runs through a list of card drivers that look at the ATR of a card to determine how to handle the card.
The PIV application, and OpenPGP are examples of two alpplications that can be on on many different cards. ID cards in Europe also appear to be applications on multiple cards. These applications in many cases are not PKCS#15 cards, but use emulation.

Code changes proposed by #507 show the problems with the current code, where a card has one ATR but could have multiple applications on the card. #507 just added the ATR of the Yubico Neo to the card-openpgp.c and a match of the ATR in card-openpgp.c caused the search to stop with the card-driver, which later in the code determined the OpenPGP application was not on the card. (The historical bytes in an ATR can contain an AID, but not all cards do this. The Neo does not, and thus two card drivers could try and use the card.

The card-piv.c on the other hand does a select for the AID during the match process, and if the AID was not found, other card drivers would be given a chance to match the card. A proposed re-ordering of the card drivers in ctx.c was proposed in #507, but this only addressed the two applications.

I would like to propose, that the list of card drivers include a psudo driver that would look for an AID
and then call the appropriate card-driver that supports the AID. This would also keep extra operations to a card down, as each driver does not have to read the the AID.

A quick grep of the source code shows that many of the OpenSC card drivers already look for an AID.
The Neo appears to be the first card where the ATR does not change, yet it can have two applications that OpenSC could support.

Still to be addressed is how a user could select one or more applications on the same card.

[martinpaljak]

I think that the policy should be, that if the ATR is known to be uniq and of meaningful value, it SHOULD be used as a shortcut. But ATR MUST NOT be used as the sole indicator of card identity for cases where it is known to be non-uniq for an application/driver.

[frankmorgner]

No matter if it's mulitple pseudo drivers looking for mulitple AIDs or mulitple ATR-based driver that look for mulitple ATRs, the real problem stays the same: How do you deal with multiple drivers that match for the current card?

This actually is the problem you leave for future work in your last paragraph. If this problem would have been solved, there would be no problem with a NEO that matches for two card drivers by AID (piv) or ATR (pgp).

[dengert]

Pull Request #551 adds the NEO USB ATR to card-openpgp.c. It looks like it will not check the AID
if the ATR is found.
The reason #551 is OK with me, is because card-piv.c is called before card-openpgp.c in ctx.c.

"The ATR is known to be uniq and of meaningful value" only applies for the first applet OpenSC supports on that card, it will not be uniq if other applets can be on the same card.

I agree with "This actually is the problem you leave for future work in your last paragraph."

[frankmorgner]

A simple solution would be to have multiple PKCS#11/Minidriver modules, one for each card driver. An application could then load all modules simultaneously. However, this will most likely not work with all card drivers since they all expect some consistent context (e.g. implicitly assume that their applet stays selected).

I don't expect much work for this type of scenario, because most people don't need and don't want multiple PKI applications on their card.