Last message in this thread, as I think nothing is wrong and you try to tweak implementation to suit your needs.
Your assumption that only administrator is responsible for slot management is totally wrong. 1 Every USB reader that is unplugged/plugged by user will most probably result in a new slot index and slot id. This is done in order to invalidate all previous slot id references. 2 Even more, USB tokens (a combined device which is reader+crypto device), are plugged/unplugged all the time by the end-users, as a result a reader is plugged/unplugged and back to (1). Alon. On Tue, May 10, 2011 at 5:29 PM, Giuliano Bertoletti <g...@symbolic.it> wrote: > > Hello Alon, > > I still disagree. > > Despite the fact that slots can (in certain tokens) be added or removed by > the administrator, such person is supposed to have complete control over what > happens. > > Acessing a slot/token makes perfect sense from a user/administrator > standpoint, although adding or removing slots might shifts their respective > positions (an user might even swaps two token in two slots if the hardware > permits this). The administrator is responsible for what it does. > > In other words, slots are something that both, pkcs#11 and hardware token > expose and, most importantly, are something the user understands (practically > speaking they're the model upon which the pkcs#11 is built). > > On the contrary, Slot_IDs are meant to be used only internally by the > application and pkcs#11 library. > They should never be exposed externally to the user much the same as you > wouldn't present to the user the value of a pointer or expect him to set it. > > However you're absolutely right when you say that finding the slot by slot > description (or better the token by token description) is the safest way to > locate the proper container where crypto material is held. > > Giulio. > > > > Il 10/05/2011 14.38, Alon Bar-Lev ha scritto: >> >> On Tue, May 10, 2011 at 1:18 PM, Giuliano Bertoletti<g...@symbolic.it> >> wrote: >>> >>> I pointed out the slot_id matter instead because it is just wrong to start >>> from the assumption that the user knows it and it won't change between >>> multiple executions. >> >> Same for index. >> Sorry, I still cannot see your point. >> Had you argued that you wish to use slot description I would have understood. >> However, both id and index are generated at runtime and can change at >> any point in time. > > > -- > > 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
