Hi Anders, of course I know your concept around SKS.
My point is, that the security of the key provisioning mechanism must be grounded in the device itself. And because it is a limited device, the mechanisms must be a little more smart card friendly. That's why we designed the solution using standard based chip authentication, secure messaging and card verifiable certificates as they are widely used in passports, eID cards and electronic driving licenses. Rather than reinventing the wheel, we allow CAs to use what they already have (e.g. have an EJBCA with support for CVCs). Andreas Am 03.10.2012 16:44, schrieb Anders Rundgren: > 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 >>>> >>>> >>> >> >> > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
