On Thursday 15 February 2007 3:26 am, Henryk Plötz wrote:
> There you also get the definition of APDUs (Application Protocol Data
> Unit) for commands and responses. The second part of your #1, 7816-4
> then defines common ("interindustry") commands for most of the basic
> operations: selecting files, reading data, updating data, etc. from
> existing files. Most notably it doesn't describe commands for creating
> files or performing cryptographic operations.Okay, so "I/O to the smart card" was a more complicated item than I thought. So there's the transport layer, and then there's the command/packet layer. The egate card claims to support ISO 7816-3, but as you say this only describes up through the transport layer. What goes inside the APDUs is left to other specifications (unfortunately, none of which are mentioned in the egate brochure). This sounds to me like a web browser claiming TCP compliance. A few more acronyms would be needed before any interoperability could be reached. :) > > For #3 we have PKCS#15. Why this only applies to reading, I don't > > know, but 99% of smart card applications are read-only so this is > > still a very worthy standard, if it works as advertised that is. > > See above: Most cards only implement 7816-4 and -8 and then only a > subset of these. File creation and management has always been very > vendor specific, so in order to actually create PKCS#15 file system you > need to have a card specific driver (which opensc has for a lot of > cards). But reading files is generally not card-specific? What would it take to have a very standardized read-only card? 7816-1-4,8? > > Are there any known cases where PKCS#15 software has been > > incompatible for read access? > > Yes, that's the same problem as above: different interpretations, bugs > and incompleteness (e.g. last time I checked opensc couldn't read > HiPath formatted PKCS#15 cards because they use a feature from the > standard which opensc doesn't implement). How do you feel about PKCS#15's uptake at this point? Do you feel that these incompatibilities will eventually work themselves out? OpenSC being incomplete is not a major cause for concern, because that can be remedied. > > For #4, I guess there is nothing yet. I don't quite understand this, > > since anything readable as PKCS#15 must have also been written as > > PKCS#15, but I'm sure someone can step in and explain this. > > PKCS#15 is only the layout that you see when reading. As said above, > creating files and directories usually needs some vendor specific magic > (e.g. Siemens CardOS cards need proprietary secure messaging with a > secret key for formatting the card). Why doesn't anyone use 7816-9 ? -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
