On 2012-10-03 14:42, Andreas Schwier (ML) wrote: > Hi Anders, Hi Andreas,
> > fine, just another API to access smart cards, token or secure elements - > this time using APDUs from within JavaScript. Why not ? > > I just don't see the application for it. What problem are they going to > solve ? > > Would I trust some foreign JavaScript code in my browser to freely > access my smart card ? > > The only real justification left for smart cards, token or secure > elements is to manage cryptographic keys and to perform operations that > require some kind of trusted execution environment (e.g. card based risk > management in EMV, totalling VAT in a fiscal meter). Storing plain data > on smart cards is a left-over from the early off-line days and is pretty > much useless in an always on-line world. > > Given that, there are two problems to solve: > > a) Allow applications (on the desktop, on the web or as app) to access > keys on the smart card, token and secure element. > > b) Manage (create, certify, import, export and delete) keys on the smart > card, token and secure element. > > a) is pretty well solved using standards like PKCS#11, CSP Minidriver or > JCE. However, controlling access to the keys needs to be carefully > managed (using PIN-PAD readers or educating users to "don't leave the > key in the lock"). We might mot agree on all this but you're IMO basically right. > b) is a little more tricky, as it requires a certain level of trust in > the device where keys are to be stored. This trust level can be either > based on the central model "I - the CA - purchase the device and put the > keys into it" or the de-centralized model "I trust the manufacturer or > issuer of the device to create a genuine device". > > The central model is pretty much what PKI operators are doing today: > They purchase a device and - in a trusted environment - put keys and > certificates into it. > > The de-centralized model is little more complicated, as the issuer might > be a national authority, a mobile network operator, a mobile device > manufacturer, a bank or a private operation. Quite often these issuers > have no interest to allow others to issue certificates for keys on the > device they had to paid for - or they just don't see the benefit of the > next big think. > > Here comes the user centric model: Let the user decide where to store > the keys and allow the CA to determine how trustful that device is: > Might be a software token, a hardware token or a hardware token with a > trusted provisioning mechanism. If the CA knows, that the keys are > stored on a genuine device and asserts that a validated identity is > linked to that key, then we don't need any further identity management > scheme. yes, this is exactly the thinking behind SKS/KeyGen2: http://webpki.org/auth-token-4-the-cloud.html > I pretty much like the StartSSL approach: Once you've proved your > identity by submitting copies of two id documents, paying a fee and > answering a phone call, they will issue certificates for "things you > own" like domains and e-mail addresses. The next level could be "keys > you own, that can not be duplicated and only stolen physically". > > I guess the trusted provisioning mechanism is what we need to work on > (and already do as far as we are concerned). You should consider SKS a contender in this space. However, SKS is also about creating a standardized SE, something the smart card industry has proved very unwilling to do (they sort of live on NDAs...). IMO, *a standard SE is a requirement for success*. Jean-Michel, do you hear me? :-) :-) Anders > > Andreas > > > Am 03.10.2012 13:23, schrieb Anders Rundgren: >> On 2012-10-03 12:08, Andreas Schwier (ML) wrote: >>> So why do you think the smart card industry has never managed to get >>> their stuff "web compatible" ? >>> >>> Isn't OpenSC the best example that "Yes, you can access a protected >>> website / webapplication / webservice using a smart card and standard >>> based technology" works ? >>> >>> The issue really is, that the topic at hand (PKI) is way to complex for >>> the average Doe to manage. That's always the downside: Security often >>> means complexity and comes with a price tag. And if it is complex, hard >>> to understand and someone offers some cheaper snake-oil, I probably go >>> for that. >>> >>> Rather than exposing the complexity of the matter with a zoo of options >>> you can choose from, we need to focus on a single generic mechanism and >>> a well designed user experience. >>> >>> It's all there (meaning S/MIME and TLS), it just needs to become a >>> little simpler to manage. So rather than re-inventing the n-solution for >>> Web-ID, SSO or One-Time-Passwords, we - as a community - should improve >>> what is already existing. >> >> What do you decipher from the following? >> >> http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html >> >> Anders >> >> >>> >>> Andreas >>> >>> >>> >>> >>> >>> >>> Am 03.10.2012 11:09, schrieb Anders Rundgren: >>>> http://www.w3.org/2012/09/sysapps-wg-charter >>>> <http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charter&urlhash=Tqzg&_t=tracking_disc> >>>> >>>> Since the smart card industry have never managed making their stuff "web >>>> compatible" before, I assume they will fail this time as well. >>>> >>>> Anders >>>> _______________________________________________ >>>> opensc-devel mailing list >>>> opensc-devel@lists.opensc-project.org >>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >>> >> > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
