Timothy J Miller 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?
Looking at this from the user's point of view, If the card has more then one on-card application, how does the user express which one is to be used? Or do they need to care? If each has a seperate PIN they will. And with PKCS#11 which (or all) of the applications should be presented? As Martin Paljak pointed out, with OpenSC a driver can do further interrogation of the card to determine if the driver should be used. For example the OpenSC PIV driver will be called for many different ATRs, and will then query the card to determine the default application is PIV. NIST 800-83 says the PIV application will be the default application. But if the card had more applications, depending on the order the drivers are called (or what drivers are enabled in the opensc.conf file) would determine which drive found its application first. > > 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? > > -- Tim > > > ------------------------------------------------------------------------ > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
