Of course there is no interoperability between Java Card implementations at either the source code or the byte code level. Nor is there any interoperability between Global Platform implementations. As usual the card manufacturers Java Card middleware providers have quite intentionally loaded their Java Cards and GlobalPlatform implementations up with all sorts of proprietary features and incompatibilities. You don't really believe you can load a CAC card with Korea Telecom's GlobalPlatform system do you, Peter? On the other hand I have quite successfully moved MULTOS applications between MULTOS cards from different implementers without changing a byte and I have loaded these applications onto these disparate MULTOS cards using different key management authorities. Some folks work with cards and code and others work with press releases and color brochures. Cheers, Scott
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Williams Sent: Monday, November 27, 2006 10:41 AM To: MUSCLE Subject: RE: [Muscle] debugging muscle? when you look at how javacard - the early platform - morphed into musclecard/cac, how SUN morphed javacard to be a custom embedded processor, and how with some platform refinements IBM has morphed it further into PIV, it was/is a very successful design. The key obviously is globalPlatform, here. The combination of the javacard + GP just outstrips multos, as an open platform - even tho so many ideas are obviously shared. The the openess of modern javacards that make them so attractive. Hopefully PIV-styled javacards will still project that, and can thus be adopted with the same spirit that earlier generations of javacard were voluntarily adopted for re-application, re-purposing, etc. For one HSPC project, one of my suppliers built a non-javacard + GP2.1 PIV-compliant ICC, with the advanced GP security management features as optional modules. But it was not the same, once you cannot use standard tools to program. _____ > From: [EMAIL PROTECTED] > Subject: Re: [Muscle] debugging muscle? > Date: Mon, 27 Nov 2006 09:15:32 -0500 > To: [email protected] > > Iain, > > Correct - the MuscleCard support for OpenSC actually places a PKCS#15 > structure on the MuscleCard applet's filesystem (single level) > libmusclecard, the plugins, and the PKCS#11 module for MuscleCard > could then be phased out over time - placing the multi-card support > under > the OpenSC PKCS#11 module. > > This makes the most sense since the Muscle framework, applet, etc was > designed for JavaCards only and OpenSC is a bit more generic. > > Thanks, > Dave > > > > On Nov 26, 2006, at 5:42 PM, Iain MacDonnell wrote: > > > > > > > Andreas Jellinghaus wrote on 11/26/06 02:12 PM: > >> Iain MacDonnell wrote: > >>> The "muscletest" tool that is built with libmusclecard (but not > >>> installed anywhere by default - find it in src/.libs) will > >>> list objects, > >> thanks, will have a look. > >>> but I'm not sure how the PKCS#15 files for OpenSC > >>> get implemented as MuscleCard objects... is there a 1:1 mapping? > >> directories get the object id of the dir name, files the object > >> id of the dir+file name. so it somehow emulates a real filesystem. > >>> muscleTool should be able to list objects too... > >>> http://muscleapps.alioth.debian.org/ > >> ok, thanks. > >>> Those are plugins for libmusclecard - if libmusclepkcs11 is > >>> obsolete, > >>> then libmusclecard may be too (if there's no PKCS#11 interface, > >>> it's not > >>> of much value, IMO). > >> no, the idea is to merge opensc and muscle, to have one library > >> that can speak to all smart cards. applications can use > >> opensc-pkcs11 then. I think it is better to have one firefox and > >> ssh and pam module that can use opensc-pkcs11 that works with many > >> cards, then to have specialised software for some cards only. > > > > My point is that if we're going to use OpenSC, libmusclecard (and > > associated plugins) are no longer of any value. OpenSC's support for > > MuscleCards doesn't use libmusclecard (AFAIK?). > > > > > >> easier for users and distributions at least I think. > >>> CFlexPlugin is (was?) for *Crypto*Flex, not CyberFlex. > >> ah, thanks. I didn't know you could put plugins on cryptoflex > >> cards at all. (it is meant to be loaded on the card, right?) > > > > No, the plugins don't go on the card - they are to libmusclecard what > > "card drivers" are to OpenSC - MCardPlugin knows how to talk to > > JavaCards with the MuscleCard plugin, CFlexPlugin knows how to talk to > > CryptoFlex cards and AuthICPlugin knows how to talk to Oberthur > > AuthentIC cards. > > > > ~Iain > > > > > > > > > > > > _______________________________________________ > > Muscle mailing list > > [email protected] > > http://lists.drizzle.com/mailman/listinfo/muscle > > > > ------------------------------------------------------------------------ > ------------ > David Corcoran corcoran at identityalliance dot com > Identity Alliance http://www.identityalliance.com > phone: 260-399-1648 fax: 260-488-2455 > > Smart Cards, Biometrics, Training, Identity Management > ------------------------------------------------------------------------ > ------------- > > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle _____ Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today! Try it now! <http://get.live.com/toolbar/overview>
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
