Hello Alon, I respectfully disagree. The slot_id is to be considered no more and no less than an handle returned by the pkcs#11 library in the eyes of the caller (although such handle must never be closed or freed).
The application has no right to guess it's value, in the same sense you cannot guess the return value of a fopen() or malloc() function. This is exactly why C_GetSlotList exists and should be used: to map indexes into slot ids. A perfectly compliant pkcs#11 impelentation can arbitrary fill the array returned by C_GetSlotList with random numbers as slot_ids each time the application is run (the only constraint is all the entries in the array should be different). Even in the special case of only one slot, the library is free to return, for example, a properly cast opaque pointer to one of its internal structures, without violating the pkcs#11 standard. From the pkcs#11 standard: > A list of CK_SLOT_IDs is returned by C_GetSlotList. A priori, any value of > CK_SLOT_ID can be a valid slot identifier—in particular, a system may > have a slot > identified by the value 0. It need not have such a slot, however. Notice also that by matching the supplied value against slot_index you won't loose anything in case slot_index = slot_id. Regards, Giuliano Bertoletti Il 09/05/2011 21.53, Alon Bar-Lev ha scritto: > This is a matter of interpretation. > Either is not constant and user is not suppose to know of. > Apart of the special case of having a single slot, so you expect 0 I presume. > You can check which slot is what simply by using: > pkcs11-tool --list-slots --module /usr/lib/pkcs11/.... > > On Mon, May 9, 2011 at 7:51 PM, Giuliano Bertoletti<g...@symbolic.it> wrote: >> Hello, >> >> I think I've found a bug in the OpenSSL engine_pkcs11. >> >> The slot_index supplied from the command line to OpenSSL and actually >> directed to engine_pkcs11, is incorrectly parsed by the latter which >> treats it as if it were the slot_id. >> >> Most pkcs#11 implementations assume slot_index = slot_id, so there're no >> issues in these cases. >> >> However some implementations (for example the nCipher Hardware Security >> Modules product line I'm working with) do not follow such convention >> (the pkcs#11 does not require that). >> >> For example to access slot#0 with such devices, I need to issue >> something like: >> >> openssl req -config ./openssl.cnf -new -out ncipher.pem -days 365 >> -engine pkcs11 -keyform engine -key slot_761406613 >> >> because nCipher's C_GetSlotList adds a constant before filling the array >> returned by C_GetSlotList: i.e.: slot_id[index] = 761406613 + index. >> >> That could be easily corrected in engine_pkcs11 by checking the >> slot_index supplied against the array index rather than the array value >> returned by C_GetSlotList. >> >> Consider that in no way, the user is supposed to know the slot_ids. >> They're internal values to be treated as opaque pointers that the >> library gives to the driving application and that the application is >> supposed to later return as they are: (i.e. typically for accessing >> slots with C_OpenSession or C_GetSlotInfo) >> >> Kind Regards, >> Giuliano Bertoletti >> >> >> -- >> >> Giuliano Bertoletti >> Pre-Sales Engineer - Technological Dept. >> >> Symbolic S.p.A. >> Viale Mentana, 29 I-43121 - Parma >> >> Tel. +39 0521 708811 >> Mob. +39 346 8749890 >> Fax +39 0521 776190 >> g...@symbolic.it >> www.symbolic.it >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Giuliano Bertoletti Pre-Sales Engineer - Technological Dept. Symbolic S.p.A. Viale Mentana, 29 I-43121 - Parma Tel. +39 0521 708811 Mob. +39 346 8749890 Fax +39 0521 776190 g...@symbolic.it www.symbolic.it _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
