PKCS#15 is not an API, it's a standard for storing objects on the card and managing all the meta-data about those objects. You would still need some sort of API for actually performing operations on the card (like key generation or crypto actions). I don't see why it would preclude using the MUSCLE API. MSCCreateObject () would still work like normal, it would just change _how_ the data is stored on the card. (I like the ACL idea by the way)
I'm not sure I see the tie in to 7816 commands. The only thing that PKCS#15 does that is 7816 specific is dealing with the file names. This can be changed however, it just looks that way because of how they wrote the standard. You could actually use any sort of file system you wanted, it wouldn't need to be 7816 compatible. That's the good part about PKCS#15, it should be able to work with any type of card. I know the PKCS#15 specifically points to a 7816-4 style filesystem but it would be possible to use any sort of system you want. The PKCS#15 paths could be anything. I don't see why PKCS#15 assumes that everything is already on the card. Section 5.8 of PKCS#15 talks about creating new objects, but there is no reason you have to do it that way. In fact, I wouldn't do it that way, with the "unused" space and all (but that is a way to do the whole PKCS#15 data model in one file). You still need some sort of API (MUSCLE) for personalizing the card in the first place, it would just be stored in a PKCS#15 manner using whatever filesystem you need. Remember, 7816-5 and 7816-6 require ASN.1 encoding and PKCS#15 fits right there. In the future it may make it easier to interface to other cards out there on the market that were not generated with MUSCLE. But who really knows... I don't mean to sound so much like a salesman, I just didn't know if anyone had thought about it. I've seen people brush PKCS#15 off because it looks too complicated. I believe it is a fairly good way of managing the data on a card because it is self contained. You have the data model and the data right there on the card. Client applications using the card don't need to know anything other than it's a PKCS#15 card. Just some of my thoughts. -- // Chris David Corcoran wrote: >Hello, > >We have looked deeply into PKCS-15 but it assumes all of your identities, >pins, keys, data structure already exist on the card. It doesn't abstract >the apdu's needed for doing on board key generation, external >authentication, etc for a variety of cards. In addition it's basis lies >on ISO-7816 file commands which don't even exist on many of todays current >and next generation JavaCards. Musclecard is much more simple. If you >want to create and write to a file you do: > >MSCCreateObject(connectionHandle, objectID, size, ACL); >MSCWriteLargeObject(connectionHandle, objectID, myData, dataSize) > >and the APDU's and protocol map 1:1 to the API. This CardEdge definition >allows post-personalization in an abstract manner. > >The GSA applet also fails to allow some of these post-personalization >functions assuming that the card is being used for crypto only and that >the keys/etc are pre-loaded. > >I > > >f I can dig it up, I have a paper on the weaknesses of PKCS-15 as a >smartcard abstraction. Send me a personal mail and I might be able to get >you a copy. > >I'm very open to suggestion though...... > >Dave > *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
