Re: MUSCLE standards
Hi, What about TCP/IP over ethernet?? That's an infrastructure just like smartcards are an infrastructure... It's the applications that a ubiquitous card/reader system would enable that are important... and I daresay required befor smartcards become ubiquitous Applications can be as diverse as the people of the world... The key issue is: If the cards and readers were ubiquitous and interoperable, a particular application could work anywhere that there was software support for it infinite flexibility... Heck, what kind of world would it be if you had to have a particular kind of computer for every website that you might want to browse?? A token ring computer for websites on token ring, a Compaq computer for websites hosted by a Compaq server?? Dave Sims On Wed, 17 May 2000, Alex Pilosov wrote: On Thu, 18 May 2000, Matthias Bruestle wrote: If you really do all this, you will have one card with one operating system. Ein volk, ein card, ein system. Sorry, I just couldn't resist ;) -alex *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE standards
David Corcoran wrote: Hi, here is a bit that I wrote up to vent on my lack of standards in the smartcard industry. Let me know if you agree or not. (and a great deal more besides). If Birmingham Aston University (UK) mounts it on their unrestricted web site, see the paper on smart card standards and e-purse originally written in 1997 by Ram Bannerjee, and greatly updated recently by myself and Steve Brunt (Steve is the senior ISO editor for ISO/IEC 10373, the smart card test standard). Smart card specifications were never designed from the top down, but just grew as a struggling technology (naked ICs embedded in a card, when everyone said they would be destroyed by static discharge) emerged from France. Bitter rivalry between suppliers, at a time when the technology was being used for closed schemes (cards and terminals being matched up by the systems integrators), a weak ISO organisation, and lack of public money for standardisation - all these contributed to the current mess. ISO gave the standardisation job to (or it was taken in by) a committee that was dedicated to defining the token, and was forbidden to look seriously at the terminal - in other words, the design work never looked at the complete system of card and terminal. The same mistakes are being made now in the contactless card standards, particularly in ISO 14443. The European Commission is trying to bring some commonality to the public use of smart cards for PKI and electronic commerce (the eEurope Initiative). RSA Labs has published a draft of PKCS#15 (interface to a PKI token, i.e. to a card) - PKCS#11 defines an API within the host system, not the interface to a device used to store the keys and permit their use in a secure manner. I will try to find time to give detailed responses to David's frustrations, but for now I generally support Matthias. Except I remind you all that EMV's T=1 is different from ISO's T=1 - both have errors in the error recovery, but the errors are different, and they also have different definitions of the fields for changing protocol parameters. Designers of this type of algorithm MUST use state diagrams as the normative definition of the processes, but ISO never makes them do that. In the UK's Contactless Standards Technical Panel, we have just been reviewing ISO 14443 part 4's draft, and we find the same problems of muddle due to there not being a state diagram. Peter Tomlinson [EMAIL PROTECTED] or [EMAIL PROTECTED] +44 117 951 4755 Iosis, 34 Strathmore Road, Bristol BS7 9QJ, UK Phone fax +44 (0)117 951 4755 Mobile +44 (0)7785 261475 Email [EMAIL PROTECTED] or [EMAIL PROTECTED] *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE standards
Hi, what if we built a smartcard "environmental system", a kind of "middleware", that deals on one side with the cards and on the other side with the (host) applications? On the cards' side, it would handle all the specifics of smartcards. On the application side, it would offer the smartcard services on a much higher abstraction level. An application could be used with any smartcard that offers the required services. (I use the term application for the program that runs on a host and talks to a smartcard; smartcards offer services.) The application just talks to the smartcard middleware. In a networked world, it could be possible for the middleware to get support from somewhere on the net in how to use a specific smartcard. The manufacturers/issuers of smartcards could provide such a help in a way that the middleware understands. Standardization efforts could concentrate on the middleware and its interfaces (to the smartcard side and the application side). No need to standardize every bit on the cards. These interfaces could even be service independant such that new services could be introduced easily, without any standardization effort. How do you think about that? Best regards, Harald On Mit, 17 Mai 2000, David Corcoran wrote: Hi, here is a bit that I wrote up to vent on my lack of standards in the smartcard industry. Let me know if you agree or not. [...] *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE standards
Mahlzeit Harald Vogt wrote: On the application side, it would offer the smartcard services on a much higher abstraction level. Are you talking about OCF? www.opencard.org Mahlzeit endergone Zwiebeltuete *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
MUSCLE BOUNCED Re: standards
hali, Standardization efforts could concentrate on the middleware and its interfaces (to the smartcard side and the application side). No need to standardize every bit on the cards. These interfaces could even be service independant such that new services could be introduced easily, without any standardization effort. first should be better to draw a map about existing systems, and i'd like very much to see the place of OpenCard Framework and smartX (XML based smart card system) on this map... (www.opencard.org, www.thinkpulse.com - i hope these are the correct addresses) the existing systems are spreaded, so _one_ standard is really hard to introduce, but in _every_ standard it is possible to plan-implement compatibility, and in the future i believe in a general reference architecture built with cubes (nice 3D models - you can hear/see about first time at Eurosmart Security Conference and on the following week at Gemplus Developers Conference) with well-defined contact types/rules, insertion and merging algorithms...and the end user or even the developer or the manufacturer will sit and use a SW: checks the required features, and the system will generate the technical sheet and a little bit more... i hope it is not a stupid idea, and with a description language through the use of ontology and building taxonomies the compatible-user_friendly world become closer :-) zoli -- Zoltán Kincses - Security and ISO manager Giro Bankcard Ltd. - http://www.gbc.hu 1205 Budapest, Mártonffy u. 25-27. HUNGARY Phone: (36-1) 421-2296, Fax: (36-1) 421-2240 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE standards
On Don, 18 Mai 2000, Matthias Bruestle wrote: Mahlzeit Harald Vogt wrote: On the application side, it would offer the smartcard services on a much higher abstraction level. Are you talking about OCF? www.opencard.org Not necessarily. OCF has a few drawbacks. It's Java-specific, local (one single VM, but I guess they're working on it), assumes that all smartcard services and their implementations are known in advance. Very small devices would have a hard time running it. (Of course, for Java applications it's well-suited.) I think the networking aspect is not taken into account as it should be. Maybe you want to take a look at http://www.inf.ethz.ch/~rohs/JiniCard/ Cheers, Harald *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE standards
unsubscribe MUSCLE end Met de vriendelijke groeten, Raymond. Treaties are like roses and young girls -- they last while they last. -- Charles DeGaulle *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
