On Fri, Nov 21, 2008 at 5:37 PM, Timothy J Miller <[EMAIL PROTECTED]> wrote: > This is sort of a general question. I should probably have CC:'d the MUSCLE > list as well, but there's a lot of overlap with this one, so here goes: > > There was a time when each card had a fixed data model. This is no longer > true; card data models are now abstracted through the use of on-card > applications; e.g., PIV, CAC, Coolkey, MUSCLE, etc. These data models can, > through JCOP, share the same card stock. > > So let's presume two different data models that can be implemented on the > same card stock; e.g., a Gemalto Cyberflex Access 64K v2c card can implement > CAC with one set of applets, or Red Hat's Coolkey with a different set of > applets. > > Each data model requires different middleware--in PC/SC terms, different ICC > service providers (ICCSPs). > > What happens if I need to use both cards in the same system? > > PC/SC, for example, directs the selection of an ICCSP based on the card ATR. > But since the card may implement one of a potentially infinite set of > different data models, this ICCSP may not be correct. > > PC/SC 2.x tries to remedy this using an extended ATR--essentially dumping an > object location into the ATR historical bytes so the ICC resource manager > can fetch that object, decode it, and be *told* which ICCSP to load > (however, I don't have any examples of this actually being used). > > NIST solves this through the data model field of the card capability > container. A similar solution in the end to PC/SC 2.x. > > On the OS side, I see that on OS X securityd fires off each tokend in > turn--in a sequential priority order set by some means--until one of them > returns back to securityd that it owns the card. It does this for every > card on every insertion. Not performance optimal, I don't think, but > probably more robust in the end. > > This is of concern to me as in the environment I support we're starting to > see more and more cards from other sources in addition to our own, and > there's a rising expectation that we need to provide at least some support. > E.g., a contract employee needing to log into a corporate portal to log his > timecard would need support for his corporate card as well as support for > the card we issued him on a single workstation (he's not allowed to bring > his corporate laptop into our network). > > I've been trying to create this condition using cards I have available to me > so I can see what various systems do (I actually have two cards with > colliding ATRs like this, but other technical problems are stymieing my > efforts at the moment), but I figured I'd ask as well. > > Anyone have any experience to offer?
No experience sorry. But I think the correct way to solve this is what Mac OS X is doing: ask each card service provider (called tokend) if it can use the card. Each provider answers with an integer number and the system (CDSA) uses the provider returning the higher value. If you use PKCS#11 you have the same solution. You configure your PKCS#11 application (like Firefox) to use each provider you need for your different cards. Firefox will then talk to each PKCS#11 provider and report tokens as seen by all the providers. The PKCS#11 solution is less user friendly since you have to configure each application. Using the ATR to identify a service on a card may have worked in the past but it is really not a good idea now. I don't think I will implement the PCSC v2 part 6 (ICC Service Provider) inside pcsc-lite. Bye -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
