Mike,
It touched on the questions you proposed. It also touched on a company that introduces standards. You are questioning why the standards aren't better and I was touching on the company you work for that develops one of the standards ! I think there were only two questions that related to that. Are those questions out of hand ? Since you are a Sun employee why not push for ISOing Java ? You are a Sun employee that carries more clout than an "average Joe". That offends you ? That's a corporate attack ? geesh, I'm sorry if the response offends you. "Sun sucks, Sun ruined JC, and you as a Sun employee are the root of all evil on earth" is offensive and a corporate attack that I never said or would state such a statement.
Read near the end, did you not see the apology ?. Your right, the document is disorganized because of all the questions and answers that were in the replies. Don't read it, don't waste your time. It's garbage and answers, what I think, are your points. I guess next time someone raises a debate, then I'll ignore it for fear to offend with the responses.
Just so you know, I didn't stir up the pot to slink away, Sir. I responded to your points that I felt needed more guidance. As did others. I'm not going to find your comments offensive because that's not what debates are.
Good day to you,
Joseph Smith
----------------------
Joseph Smith
----------------------
>From: Michael Bender <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [OCF] Serial number >Date: Mon, 21 Jul 2003 22:08:11 -0700 > >I realize that my most recent post here may be confusing, since the >post by Joseph Smith that I was replying to was not sent to the >opencard.org mailing list due to an e-mail addressing error (I am >presuming). > >Here is his original post that I believe was meant to go to the >list and was a response to posts that I and Sylvain made on this >topic. > >mike > >-------- Original Message -------- >Date: Mon, 21 Jul 2003 23:25:33 -0400 >From: Joseph Smith <[EMAIL PROTECTED]> >Subject: Re: [OCF] Serial number >X-Originating-IP: [68.86.186.41] >To: [EMAIL PROTECTED], [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > >Whoa, wait a minute. .... >Why can't you go to the hardware store and buy smartcards ? You are >kidding >right ? How about because users don't know what smart cards are used >for. >How many everyday users can walk into Target and know exactly the >kind of >cards needed for their machine ? Most users don't know what a >gigabyte is >much less what the megahertz in their machine is. But they do know >what >Intel is. > >So based on that, they would walk into Radio Shack and get a GemSafe >card. >Oh, wait, they need a 7816 compliant / PCSC reader. Okay, now, they >are >reading the box and it states that the card will work with Outlook. >Great. >But what am I doing with it in outlook ? I can store a X.509 >Certificate on >it. Yea, like they know what that means. Oh, and the box states that >you get >a CSP with it to use with IE. Now, their eye's are glossing over. >But wait, >there's more. If you use a third party P11 library you can integrate >it with >Netscape. Huh ? So essentially the box would state, " will work >with most >applications." Translation. Good F'ing luck. After the "cool" factor >wears >off, they cards will become a novelty collecting dust on their desk. > That >doesn't have anyting to do with card vendors but complex >technologies >surrounding it. This would be the same issue if you use a Rainboy >token key. >How is that the blame of the card vendors ? > > >Why can't you read a serial number ? In global platform, I like that >fact >that you must authenticate to the card to have access to a serial >number. >Consider me a bit paranoid, but that added security makes me feel >better >about the cards. What end-users needs to know the serial number of >their >card ? Even the DoD CAC card prints a serial number on the back of >the card, >but they don't know anything about it. >How is that the fault of the card vendors ? > >You are trying to move your techie knowlege into the masses and it >doesn't >work. As a Sun employee you should know that. How many people that >ordered >Dell last week gave a hoot if it contained Java or not ?Let alone >know the >difference between MSFT Java or Sun Java. They wanted XPHome, AOL, >Works, >and "that cool mouse with the red laser" ! How many people that >ordered >Dell computers in the last year cared about the Sun v. MSFT lawsuit >? Only >the tech-savvy. Only those of us that do web technology, not people >that use >their computers for Quicken, Hotmail, and AIM. Now they are told >there is >technology to protect their .doc file. In all honesty, do you think >they >care ? They just want to download a jpg of the grandkids and open it >fast ! > >So, how many people are actually ordering Dell computers that have >attached >readers? Or better yet, have biometric readers attached ? How many >are >ordering Cherry keyboards that combine the readers ? >Speaking of a lack of standard, dive into biometric and you'll >appreciate >the standards that do exists in smart cards. > >I work for a government consulting firm with over 120,000 employees >and they >aren't sure what to do about security, but they know they want a >smart card >as the token. The ole "flip the switch" methodology. Not realizing >all the >technology behind it. When the prices add up, like certificates, >provisioning, SSO, VPN, the idea of security, could take a back >seat. That's >not the fault of the card vendors. > > >I hope you aren't complianing about the JC standard ? If there >wasn't a >Java Card standard, how would you use it on the Sun Ray ! That >standard hurt >the card vendors because they no longer have a way of keeping you as >a >customer. You can order 100 cards from Gemplus and then find cheaper >ones >from SLB. Of course, there might be a little tweaking required, but >imagine >the head ache if they were proprietary file system cards. The >standard you >refer to, ISO, was *created* by the vendors. ISO allowed proprietary >cards. >Who wouldn't want to adopt that ? Again, you as a Sun employee >knows Sun >has no intention of ISOing Java ! If you don't like the way the >smart card >standard is, then ISO Java ! > > > >>Still some cards use A0000000030000 and others A000000003000000 >but > >>selection with partial AID is supported by most of them so >"A000000003" > >>can work as well. >That "hack" as you referred to it isn't a hack. If you had to enter >the >whole AID every time you selected the applet, you would complain >that there >should be a way to enter a partial. Besides, I've never seen >partials used >in deployment, only in developement when it's a pain to type the >complete >AID. In deployment, the middleware will know the full AID. Again, >that has >nothing to do with the user at Radio shack, but the techies. How is >that >the fault of the card vendors ? But isn't that partail an adoption >of the >standard anyway ? > > >Why not set it in stone in a standard that specifically and >unambiguously > >spells out what every card must do to identify itself? >There is. Look at the Global Platform. In other words, if you want a >Global >Platform Java Card, there is a standard on what every card must do. >It's up >to the vendors to follow it. That's not a card vendor issue, but a >compliance issue. Gemplus doesn't even follow the GP standard for >the CM AID >! Also don't think a standard assembled by a body of experts is >correct. In >the PCSC specification, they treat a card's ATR as the serial >number. We all >know that's incorrect. > > >I'm sorry, but I believe that my point is correct - there is no > >one single standard in the smartcard industry that all cards >follow > >in the area of identification and serial number/unique ID >extraction. >That's because there are different kinds of smart cards. Just like >there are >different cars out there, they all are cars, but some take higher >octane, or >have different sized engines, larger cargo, rag top etc. You need to >be more >specific in your statement. Are you referring to JC or Filebased >cards,T1 or >T0, SIM cards, laser cards,contactless, 14443A or 14443B, Mifare, >Desfire, >usb cards, etc. In my opinion JC has done a good job in it's attempt >to >merge some of those technologies into one. But I fail to see how >that's a >card vendor issue. > > >Let's talk about GetResponse processing for example - why are > >there so many possible status words that the card can return, > >and why is there no concrete statement that specifies where > >such processing is supposed to be done - in the terminal, in > >some middleware software stack component, by the application? > >What possible justification can *anyone* provide for this mess? > >Who stated what a GetResponse *has* to return ? It's good practice >to follow >what ISO does for return codes. But, ( I don't have docs in front of >me ) I >believe ExAuth return codes is different from ISO and GP. Whos the >blame for >those situations ? > > >The responsibility here is with the technology providers, but what > >you say is typical of all the card vendors that I have worked with > >over the years - everyone just passes the buck and says "it's not > >my problem, my customer wants it this way". > >Exactly ! I work in the government industry and believe me, thats >how they >operate. One agency wants a smart card for one thing, and can care >less >about all the other "standards" like GP. Another is interested in >using the >smart card as a token and can care less about contactless, and so >on. Face >it, the smart card industry, much like the biometric industry >survives >because of entities with endless money. Well that is government. ( >and big >ass banks )And these card vendors only deliver what they are asked >to. Let >me give an example. Match-On-Card, sounds like cool technology. The >capabilities to store a biometric and match it while all in the >secure >domain of the card. Well guess what? The government would love to >use it but >isn't, because studies have shown it not feasible. So they are >matching off >card. So the card vendors and chip manufacturers are starting to >scramble to >speed up the cards to allow that technology to work all while >staying cheap. >The government is driving the market and you might see a standard >come out >of it. ( I doubt it ) You won't see the government adopt the BAPI by >MSFT/ >IOSoftware, but something more neutral like BioAPI. So where do you >think >the vendors will shift focus ? "The customer wants it this way." ! ! >! ! ! > > >Yes, that may very well be, but it could be a much larger market > >if the industry was willing to come up with reasonable, rigid > >and non-proprietary standards. > > > >>The main reasons that prevent cards to be used in public is more: >leak > >>of readers, why M$ does not list smartcard reader as a required >device? >Allow me to reverse the question and ask you this. Do you have a >AmEx Blue >card ? Any Smart Visa Cards ? Target Visa Smart Card ? If you do, >what are >you doing with it ? Have you ordered the free readers that come with >the >cards ? Think of this scary thought as well, over the weekend, take >a mental >note of how many mag stripe readers there are. I mean every place >you can >use your debit/ATM card to where you can make purchases with a >credit card, >even the hotel room ! Now ask yourself this, WHO is going to cover >the cost >of switching them out for dual readers ? Good luck convincing them >the cheap >pennies the mag stripe cost will now cost in the dollars just for >the smart >card ! They have to be duel to accomadate the legacy mag stripe >customers >that won't have a smart card. Then think about the systems that will >need to >be reprogrammed to understand the dual readers. And trust me on this >one, >who's going to train the consumer how to use it ? In the US, we >still like >to open our wallets and see how much money we have for the night. If >someone >told me there was money on my card, how do I know how much ? I >recall this >weekend I was pissed because I was behind someone that wrote a check >and I >was thinking if she would use her debit card we could be done by >now. Now >who's going to train that person it's better to switch to a smart >card when >they aren't even using a mag stripe card ?! How many are using smart >cards >for online purchases ? You can't even use a smart card to encrypt >your >Hotmail/Yahoo mail. How many non-techies even know there is a smart >card in >their mobile phone ? > > >Is Microsoft the only opeating system vendor in the world? > > >Yes. In the "big boy's" world they are deployed on a lot of boxes. >Again, >peek at the government. Think of all the laptops, desktops, etc. >They are >all deployed with MSFT. Some shops are still running Win95 ! In the >techies >world, no. But with the exception of Linux PCSC, how do you suppose >you >would communicate to the CAD ? Proprietary libraries ! ! ! Also ask >yourself >this, how many reader vendors support OS other than MSFT ? Wanna >know >something funny ? G&D SmartCafe Kit doesn't even support PCSC ! > >You are right that the standards aren't as mature as they should be, >but >it's a standards body issue not a card vendor. Why don't we have >compliance >testing results on vendors that state they are Global Platform >Compliant ? >You are Sun employee, so answer this, why don't we have results of >Java Card >compliance tests ? How do we "truely" know vendorX card is truely >compliant >to Java Card specifications ? I know a card vendor that was >deploying a 2.1 >Java Card that didn't follow the specs on transient arrays. I know >another >card vendor that had a flaw in their RSA implemention on the card ! >Where >was the compliance testing ? THey followed the standards, so they >say ! >Not to keep bringing Bio into the mix, but read the conformance on >BioAPI. >There isn't any. If a vendor states they comply, that's all we've >got to go >on ! Like I stated, the standards in smart card are way better than >you >think ! > >If I came off a bit harsh I apologize. I hear this quite often from >people >and I think we get caught up in the wrong thing. Instead of trying >to force >a standard of all other standards, we need to figure out a way to >speed up >adoption. Do you think the guy buying a pack of cards to go with his >Dell >cares about Java Card RMI ? Do you think that same person knows what >ISO is >? The techie that wants to store the Wi-Fi key on his card might. >The corp >execs that want to encrypt email about a merger might. Have you >seen the >Britney Spears Smart Card ? Do those kids buying that card care >about the >standard or collecting all the cards ? > >The bottom line, the card vendors care about SELLING CARDS. So, >standards >schmandards, what do I have to do to get you to buy my cards ? ! ! > >---------------------- >Joseph Smith >www.javacard.info >---------------------- > > > > > >From: Michael Bender <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: Sylvain Ferey <[EMAIL PROTECTED]> > >CC: H�seyin ORTAOVALI ><[EMAIL PROTECTED]>,[EMAIL PROTECTED] > >Subject: Re: [OCF] Serial number > >Date: Mon, 21 Jul 2003 15:50:13 -0700 > > > >Sylvain Ferey wrote: > >>At 14:40 21/07/2003 -0700, Michael Bender wrote: > >> > >>>H�seyin ORTAOVALI wrote: > >>> > >>>Shame on the smartcard industry for not providing a universal >way to > >>>identify a card tpye and to extract a unique ID. This isn't >exactly > >>>a new concept in the field of electronics and computer-connected > >>>devices. > >> > >>Smartcard industry mainly complies with standards it has to >follow > > > >The smartcard industry *creates* the standards that it follows, > >so that's not really a good justification for a lack of a >universal > >scheme to identify cards. > > > >>if you except an unique ID for all GSM, banking, ID (memory?) >cards > > > you may indeed fail to find one since these standards are >differents > > > (actually nearly all cards but GSM provide a CPLC string as per > > > EMV96 or VIS1.x.x) > > > >A mechanism for identifying hardware as to vendor, type, model > >and providing a unique ID has been developed for many other > >computer technologies that are governed by standards that are > >developed by numerous technology companies, many of them > >competitors. Consider the following technologies: > > > > EISA > > PCI > > PCMCIA > > USB > > Ethernet > > 802.11* (wireless) > > Serial Plug-and-Play > > IEEE 1394 > > > >>>Oh, and double shame on the industry for allowing different AIDs >for > >>>OpenPlatform/GlobalPlatform Card Manager applets so that what >could > >>>have been a reasonable way to determine card type and serial >number > >>>information doesn't work in many cases. > >> > >>one provider uses a proprietary AID, it isn't a rule. > >>Still some cards use A0000000030000 and others A000000003000000 >but > >>selection with partial AID is supported by most of them so >"A000000003" > >>can work as well. > > > >Yes, but why do we even allow this "partial AID" selection hack > >and allow manufacturers/issuers to use different CM AIDs? Why no > >set it in stone in a standard that specifically and unambiguously > >spells out what every card must do to identify itself? > > > >>>IMHO, the industry has reaped what it has sowed over the past >twenty > >>>or so years by steadfastly refusing to work together and >continuing > >>>to propogate proprietary solutions for no good reason. > >> > >>I'm afraid your point is definitively wrong. All GSM cards comply >with > >>11.11 & 11.14, all banking cards comply with EMV certification - >meaning > >>aroud 99% of issued cards !... > > > >I'm sorry, but I believe that my point is correct - there is no > >one single standard in the smartcard industry that all cards >follow > >in the area of identification and serial number/unique ID >extraction. > > > >>considering that card providers can do their own stuff is a mess, >they > >>do what specification issuers request, and they request the same >to all > >>card providers. > > > >The responsibility here is with the technology providers, but what > >you say is typical of all the card vendors that I have worked with > >over the years - everyone just passes the buck and says "it's not > >my problem, my customer wants it this way". > > > >>>Think about this - what if when you went to your local computer >store > >>>and bought a PCI card, say a VGA card or a sound card or some >other > >>>peripheral card when you plugged it into your system the system > >>>had no way to identify the card nor what resources it needs, and > >>>you needed custom manufactuer-provided software to just get to >the > >>>point where the system knos that it's a VGA or sound or modem >card, > >>>and in the process of running that custom software you had a >good > >>>chance of crashing the system or scrambling other cards in the >box? > >>>No one would stand for this in today's computer world, yet we >can't > >>>seem to get the smartcard industry to even agree on a simple, > >>>universal identification scheme that doesn't require poking >random > >>>APDUs into unknown cards to see what happens. > >> > >>the comparison sounds strange !! a GSM card is as different than >a banking > >>one than a video card is different than sound card, PC industry >had > >>defined its own standards to (of course recognize these cards >and) use > >>them for a specific function; smartcards behaves the same: they >behave as > >>expected when plugged in the dedicated device. > >>does your VGA card runs well in a hi-fi systems ? > > > >You miss my point completely - my example of PCI cards is that > >*all* PCI cards will identify themselves using the same mechanism. > >They all provide vendor/model/ID and resource requirements > >information. I can write one piece of software that will query > >any PCI card produced and get basic information on the card. > > > >That is simply not possible with a smartcard. > > > >As to whether a VGA card runs well in a HiFi system, my answer > >to that would be - maybe, if the HiFi system is computer based > >and has a connector for a VGA card that provides the display > >for the HiFi system. > > > >As for the VGA case specifically, the computer industry has > >even gone so far as to define the basic set of VGA operations > >and parameters that all cards must follow in order to produce > >a usable video signal. That is way beyond simply identifying > >the card as to type and ID. > > > >Where are we in this regard in the smartcard space? > > > >>>Think about the ATR - what an absolutely wonderful place that >would > >>>have been to embed a multi-byte product/family/vendor code as >well > >>>as a unique ID; you reset the card, and then you get all the >info > >>>you need in a single transaction to know if the card in the >reader > >>>is one that you can work with. > >> > >>yeah, could be great, but again ATR is defined by ISO 7816-3 & 4, >not by > >>card providers, and ISO didn't define a card manufacturer tag (a > >>"pre-issuance data" field still exists). > > > >Who defined ISO 7816? Was it handed down from the sky by some > >cosmic entity or by space aliens from the Planet X? > > > >Come on, the smartcard industry defined ISO 7816, so it's really > >disengenuous for you to say that the smartcard industry is only > >following the standard, when they defined the standard in the > >first place, and because of their lack of technical foresight > >and nationalistic pride and unwillingness to produce anything > >by closed, proprietary systems, we have an ISO standard that is > >regarded by many as a document that describes *exceptions* > >rather than one that is truly a standard. > > > >Let's talk about GetResponse processing for example - why are > >there so many possible status words that the card can return, > >and why is there no concrete statement that specifies where > >such processing is supposed to be done - in the terminal, in > >some middleware software stack component, by the application? > >What possible justification can *anyone* provide for this mess? > > > >>>I know, I'm probably preaching to the chior, but I have very >little > >>>patience when I hear the industry complaining about how >smartcards > >>>have not been as embraced by the general public for general >computing > >>>applications. > >> > >>I think smartcard industry does not complain about that, it's a >1-3% > >>market!! > > > >Yes, that may very well be, but it could be a much larger market > >if the industry was willing to come up with reasonable, rigid > >and non-proprietary standards. > > > >>The main reasons that prevent cards to be used in public is more: >leak > >>of readers, why M$ does not list smartcard reader as a required >device? > > > >Is Microsoft the only opeating system vendor in the world? > > > >How about the fact that I can't go down to my local computer store > >and buy a ten-pack of Schlumberger smartcards today, and buy a ten > >pack of Oberthur smartcards tommorrow, and have exactly the same > >code work on both sets of cards? I think it's because the industry > >is more interested in selling ten million cards to a government > >tansportation agency than selling ten cards to a million small > >time developers. Hey, that's a business decision that I don't >agree > >with, but I am not a card manufacturer or issuer, so I can only > >have an opinion on the matter. > > > >>leak of application standards, OCF is great but is it better than >CSP ?, > >>would I use PKCS#11 ? most of software developers are not >interested in > >>smartcards (for security, license management, authentication, > >>identification, data storage, ....) just because they can't rely >on a > >>mature API to provide these features. > > > >The whole host-side API mess has not been helped by the two >distinct > >camps - PC/SC on one side and OCF/Java on the other. As a >developer of > >host-side smartcard applications, it makes it really hard for me >to > >release one piece of code that will work on all systems; I've >given > >up the OCF torch and am doing PC/SC these days. > > > >>sorry for this out of (list) subject mail. > > > >Well, it's better than reading yet another post from Sam Goldsmith > >advertising 10,000 Gemplus readers for sale, so thank you for the > >diversion :-). > > > >mike > > > >-- > >---------------------------------------------------------------------------- > > Michael Bender E-Mail: >[EMAIL PROTECTED] > > Sun Microsystems, Inc. Tel: 831-401-9510 > > 14 Network Circle Tel: x.31807 > > Menlo Park, Ca. 94025 > > Mailstop: UMPK14-260 MD: VPN/IMAP > > > > Never give up! Never surrender! > > > >---------------------------------------------------------------------------- > > > > > >--- > >>Visit the OpenCard web site at http://www.opencard.org/ for more > >>information on OpenCard---binaries, source code, documents. > >>This list is being archived at >http://www.opencard.org/archive/opencard/ > > > >! To unsubscribe from the [EMAIL PROTECTED] mailing list send >an email > >! to > >! [EMAIL PROTECTED] > >! containing the word > >! unsubscribe ! in the body. > > > >_________________________________________________________________ >The new MSN 8: smart spam protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > > >-- >---------------------------------------------------------------------------- > Michael Bender E-Mail: >[EMAIL PROTECTED] > Sun Microsystems, Inc. Tel: 831-401-9510 > 14 Network Circle Tel: x.31807 > Menlo Park, Ca. 94025 > Mailstop: UMPK14-260 MD: VPN/IMAP > > Never give up! Never surrender! > >---------------------------------------------------------------------------- > > >--- >>Visit the OpenCard web site at http://www.opencard.org/ for more >>information on OpenCard---binaries, source code, documents. >>This list is being archived at >>http://www.opencard.org/archive/opencard/ > >! To unsubscribe from the [EMAIL PROTECTED] mailing list send an >email >! to >! [EMAIL PROTECTED] >! containing the word >! unsubscribe ! in the body. >Tired of spam? Get advanced junk mail protection with MSN 8. --- > Visit the OpenCard web site at http://www.opencard.org/ for more > information on OpenCard---binaries, source code, documents. > This list is being archived at http://www.opencard.org/archive/opencard/ ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email ! to ! [EMAIL PROTECTED] ! containing the word ! unsubscribe ! in the body.
