Hi, I would like to propose to dissociate the object ID and index of the file (instantiated from the profile), and to relate the choice of the file index to the path (entire or the last byte) of the existing objects of the same type.
Actually, 'New API' of pkcs15init uses the last byte of the object ID as an index to instantiate new object file. With the 'Old API' the index for a new object is the number of objects of the same type. Actually, default object ID is one byte value. For a new object of a given type the choice of ID follows the next rules: - existing objects of the same type should have a unique ID (? what about split key ?); - value should be in the range [DEFAULT_ID(0x45), 255]. The problems of such implementation has already been reported: http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012812.html http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012815.html Otherwise with a 'New API', when application supplies its own, intrinsic to object ID (for ex. application that uses NSS -- Firefox, ..), a conflict of the file indexes can happen if two different IDs have the same last byte . (This last is rather IMHO -- I have no card that has a 'New API' support ). The same if the last byte of supplied ID is 0x45 -- then the next object creation with pkcs15init-tool can cause the conflict of indexes . (Once more -- IMHO). In the code I do not found any protection for such cases. Is it so? Kind wishes, -- 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
