Andreas Jellinghaus wrote: > the old mechanism for selecting IDs was maybe too simple, so implementing > a better mechanism would be a good idea. I guess the card driver should > have some control over it, as different cards have different requirements. > Yes!!! That's the point! IMHO, it's the most essential point that actually handicaps (sorry!) the OpenSC support.
Card specific pkcs15init part needs more freedom. There should be the possibility to make OpenSC support of a particular card to be compatible with the card producer's native middleware . Actually, there is an emulation of 'pkcs15' -- it's quiet natural to have the possibility to emulate 'pkcs15init' (or at least to support non-pkcs15 content descriptors). > for example: > * with some cards, file index must be uniq (e.g. you can't have foo/A and > bar/A) > * some cards might want to set short ids (one byte global values for direct > reference) > * some cards might be limited - at least some special objects need to have > a "right" file ID. > > no idea how to actually implement it. if it breaks some or all cards, > now is a good time to make big changes, as we break ABI anyway. > It should not break the other's card support. IMHO, it can be done absolutely transparently. The sc_pkcs15init_operations has to be extended by some limited number of methods like: get_free_index() -- card specific file index policy; store_data() -- to update non-pkcs15 descriptor system; update_df() -- to support complete emulation of pkcs15init (without on-card PKCS#15 file system); change_attr() -- update non-pkcs15; no more need of select_id(): the general support of intrinsic IDs should be sufficient. maybe a couple more ... It can be done gradually. Each card will decide itself what to implement, in the same manner as it's actually done . > opensc reads all DF files on startup, so if a new ID is needed, a card > driver could (worst case) go through all DF entries and see which ones > are already in use to avoid conflicts? > IMHO, for the crypto objects the ID should be an intrinsic one. Any way, card (or, if you like, the on-card pkcs15 application) should not contain the same object twice. So, no danger of ID collision. The same for the DATA object, some unique ID can be derived from it's content and attributes. In any case file index should not be derived from ID. > Regards, Andrea Kind wishes, Viktor. -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
