Martin Paljak wrote: > On Apr 19, 2010, at 10:55 , Anders Rundgren wrote: > >> Regarding what is ready and what's not, it is entirely clear that >> card initialization is NOT READY for mass-market adoption. OpenSC >> does currently not support end-to-end security initialization so IMO >> it is not suitable as is and I also believe that the symmetric key >> card solutions that you can buy are useless on the Internet.
> What your comments imply is that there is a need for the <keygen> style > enrollment in the first place. IMHO, there are two target groups for smart > cards: > > a) centralized - like eID rollouts, where the actual RA has requirements > other than purely technical > b) "home user" - like people using pkcs15-init to store "their" keys > > a) has already solutions that work and don't really depend on what is > available on the > "edge" of the network (client computers) for initialization part > b) works with whatever is possible with the card at hand, like OpenSC. I think you can extend this a bit. I was recently involved in the development of a PKI credential enrollment system for a large government body's mobile phone fleet. Du to the unavailability of a built-in <keygen> mechanism, considerable efforts were spent on developing proprietary counterparts. Mobile C2G services have similar problems: eID doesn't fit in the phone. However, using the eID as "bootstrap credential" could make this a nice combo. If there *was* a <keygen>[1] that is. I would not characterize non-eID users a "home users". The problem here is that you need specific "card management" software in order to use smart cards. I.e. smart card initialization is incompatible with the web! I consider this a *major* shortcoming. Well, of course you can *buy* various "plugins" but these typically only work on specific versions of Windows as well as are all over the map. Putting this in another perspective: the IETF just finished a 40 month KEYPROV effort. The KEYPROV spec does not support browsers but all the vendors' implementations do. Naturally the participating vendors' browser-interfaces require NDAs if you want the details. Feels like "card vendor" spirit... To me it looks like there is a *huge* opportunity introducing a web token based on open technology. It doesn't have to be "standardized", open is good enough at this humble stage. GlobalPlatform say they will solve this by making the *card* a web-server (ETSI standard) with XML processing capability. Personally I think this is the wrong way, leading to an even more diverse set of card interfaces. How does OpenSC match with GP BTW? Anders 1] Not Mozilla's <keygen>, it is totally useless except for low volume production of "administrator cards" or similar. Microsoft's counterpart is more powerful but still non-standard and does not address the end-to-end security stuff either. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
