Rolling your own USB device classes isn't completely without issues as this bright young man describes it:
http://fourwalledcubicle.com/blog/archives/561 Anders Peter Stuge wrote: > 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 > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
