Il 26/04/2011 13:47, Peter Stuge ha scritto: > "forces local communications" makes no sense. If the device is > connected via USB then it will be local regardless of which interface > class it uses. And you can even use UsbIP stack if you want...
> Maybe you will argue that it should implement CDC Ethernet and expose > a network protocol over USB, so that the device can be anywhere on > the network. That would be simpler to use the included ethernet interface, then... > It's a bad idea because the standard interfaces do not fit the > purpose of the device. It's *very* difficult for people to get their > head around this - you're not the only one - but vendor specific is > very very useful in USB. It's not a bad thing, it just takes a bit of > detail knowledge about USB to see the benefits. And needs to be very well documented. :) Not like many closed vendor specific protocols that float around... > Networking the device is a new requirement. It could make good sense > to go there later, but I would like to start with something that fits > easily into the existing p11 model. Urgh... well, it could even "serve" many servers via lan, but I too think it's something that can come much later. >> How can two parties can communicate with each other while have >> nothing common? Do you prefer unconditional (information-theoretic) security or "simply" computational security? :) Too bad public-key crypto can only be computationally secure :( >> PGP/SSH like manual key exchange may be used, but it is too complex >> for most users. As I said in another mail, you have to define security perimeters. From when the device is manufactured to the moment you load a certificate on it, you must consider it "secure by definition" and always inside a trusted security perimeter. After a cert is loaded, it can leave the security perimeter for the real world. > I thought you meant encryption between applications and device? Do > you mean user to user? Keep different layers separed. If you mix 'em it becomes a mess. Users see "application" level, not p11 (or whatever) level. > The API can be implemented over USB just as well as over DLL. There's > really not a big difference. So using vendor-specific protocol as a sort of RPC? >> What I have in mind is to pull all objects from the device into main >> computer and implement PKCS#11 locally, while delegating only private >> key operations to the device. >> This way you have much faster implementation, and a very simple >> protocol implementation. > Go for it! It's also an interesting idea. Cache coherency issues pops up everywhere in this scenario :) BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
