Andreas Jellinghaus wrote: > > Basically .. talk PKCS#11 nearly directly with hardware.
> you still need to > * select the reader to use (if there are several) > * select the slot to use (if there are several) > * select the card to use (e.g.on contactless readers) Well, this could be implemented and multiplexed any way that is suitable. If the token has multiple keys (sign/encrypt/...) then maybe it would be better PKCS#11-wise to expose those as separate cards in different slots, rather than have only one card per token? Readers could map to physical USB ports. > * map PKCS#11 API to some transport stream or data structures This should be easy enough. USB is really flexible. > * handle locking, resets, enumeration, access control, etc. Yes, that's the only issue. But USB provides a lot of information to the driver, and maybe the design can even allow lock-free operation. > for me pkcs#11 is quite a low level api, at least compared to > microsoft crypto api. Maybe it's an okey fit for a hardware device then? > I'd prefer if the goal would be set high, with user stories > and end user perspective in mind, and then an easy solution > for that would be sought. Yes, I think this is important too. But everyone keeps talking about PKCS#11 and how it is the standard and I see more and more software implementing and using PKCS#11, so I'm starting to think that it may be the shortest path to success. > if you stay with pkcs#11 you don't fix the problems we have despite > implementing pkcs#11. I've never been a big fan of PKCS#11 but it seems that everyone is using it, so it might be worth a shot to actually optimize some hardware for it? //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
