Anders Rundgren wrote: > >> There is no such thing as talking directly to USB if you want > >> your stuff to run in an ordinary computer > > > > Hm - what do you mean? > > I took it for granted (maybe incorrect) that the operating > system, libusb, or whatever is running the show assumes that > all connected USB devices implement one or more known > USB classes.
It is perfectly legal for a USB device to use the "vendor specific" device and interface classes. Then there is no driver in the operating system to interfere with communications, and the full feature set of USB is at the disposal of the firmware and host software developers. This is by far the most flexible way to create USB devices. Now, if there exists a USB device class that perfectly fits the purpose of the device, then that is absolutely the way to go! But then it must really be a perfect fit. It's a horrible idea to abuse the HID device class for non-HID devices. They are super easy to access in Windows but a big mess on all other systems. Vendor specific is neutral and equally easy everywhere. > Naturally you can (as you have suggested) defining you own > classes but that is a little bit more convoluted than just > exercising the pins on the USB. In fact to do it right way > you must pay a hefty fee to USB.ORG to make it official. Vendor specific is defined as 0xff for the class and interface class identifiers. This is distinct from implementing a new standard class, which would indeed require lots of politics, effort and money with usb.org. Vendor specific is the equivalent of private IP addresses. You can do whatever you want, noone else will interfere, but you will also not be reachable through any standard operating system interface, but e.g. using libusb will work just fine, across WinMacLinuxFBSDSolaris. > Is there any particular drawback of reusing CCID? As far as > I can tell it doesn't tell how your APDUs should look like. But it still uses APDUs and thus it still needs the middleware. With USB/PKCS11 the PKCS#11 provider would use libusb to communicate directly with the hardware. (The OS is in between, but no other files than the p11 would need to be installed.) Device driver replaces the middleware. For compatibility it could certainly make sense to implement CCID in parallel, so that either CCID or USB/PKCS11, or both, can be used to access objects in the token. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
