W3C takes on Web+SecurityElements

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

W3C takes on Web+SecurityElements

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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Andreas Schwier (ML)
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.

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
> [hidden email]
> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

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
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

NdK-3
Il 03/10/2012 13:23, Anders Rundgren ha scritto:

> What do you decipher from the following?
> http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html
That Gemalto is interested in being an early player? :)

BYtE,
 Diego.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Andreas Schwier (ML)
In reply to this post by Anders Rundgren
Hi Anders,

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").

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.

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).

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
>>> [hidden email]
>>> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Douglas E. Engert
In reply to this post by Andreas Schwier (ML)


On 10/3/2012 5:08 AM, 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.

The approach we are taking for SSO is Shibboleth.

http://shibboleth.net/

Using the X509 login handler:

https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler

OpenSC provides the client cert and key for TLS authentication to the IDP.

Shibboleth is all SAML based, and can work with other SAML based
services.

Support for OTP or whatever then is only needed in the IDP.


>
> 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
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Anders Rundgren
In reply to this post by Andreas Schwier (ML)
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
>>>> [hidden email]
>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>>
>>>
>>
>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Andreas Schwier (ML)
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
>>>>> [hidden email]
>>>>> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Andreas Schwier
In reply to this post by Douglas E. Engert
Hmmm, so why would I want an IDP if I could prove my identity
(certificate) and authenticity (client signature in SSL) with the
credentials I have on my card ?

Is it because SAML is easier to integrate than SSL client authentication
? Or is it because I want my IDP (e.g. Google / Facebook) to know what
I'm doing ?

The IDP model is perfect for username / password, but IMHO it's of less
use when you use keys and certificates. In the later case the CA is your
IDP by providing you with a certificate you can use to authentication
towards others (who trust that certificate issuer as they would trust
the IDP). And just lets wait for the first Diginotar incident at an IDP
- ops they've copied our SAML signing keys...)

Andreas

Am 03.10.2012 15:44, schrieb Douglas E. Engert:

>
> On 10/3/2012 5:08 AM, 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.
> The approach we are taking for SSO is Shibboleth.
>
> http://shibboleth.net/
>
> Using the X509 login handler:
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler
>
> OpenSC provides the client cert and key for TLS authentication to the IDP.
>
> Shibboleth is all SAML based, and can work with other SAML based
> services.
>
> Support for OTP or whatever then is only needed in the IDP.
>
>
>> 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
>>> [hidden email]
>>> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Anders Rundgren
On 2012-10-03 20:45, Andreas Schwier wrote:

> Hmmm, so why would I want an IDP if I could prove my identity
> (certificate) and authenticity (client signature in SSL) with the
> credentials I have on my card ?
>
> Is it because SAML is easier to integrate than SSL client authentication
> ? Or is it because I want my IDP (e.g. Google / Facebook) to know what
> I'm doing ?
>
> The IDP model is perfect for username / password, but IMHO it's of less
> use when you use keys and certificates. In the later case the CA is your
> IDP by providing you with a certificate you can use to authentication
> towards others (who trust that certificate issuer as they would trust
> the IDP). And just lets wait for the first Diginotar incident at an IDP
> - ops they've copied our SAML signing keys...)

I think one of the reasons is that the folks that created TSL-client-certificate-authentication
forgot to implement logout in a way that works for web applications.

They claim that this is a "feature" and that I'm just to understand understand the beauty of it :-)
So everybody has to write local IDPs using SAML or cookies even if they have
PKI if they want to build anyhthing that looks like a real web app.

Then there are of course other a very legitimate uses of IDPs where
SAML attributes carry potentially completely alien information like
a role which often is less suitable having in a certificate.

Andes


>
> Andreas
>
> Am 03.10.2012 15:44, schrieb Douglas E. Engert:
>>
>> On 10/3/2012 5:08 AM, 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.
>> The approach we are taking for SSO is Shibboleth.
>>
>> http://shibboleth.net/
>>
>> Using the X509 login handler:
>>
>> https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler
>>
>> OpenSC provides the client cert and key for TLS authentication to the IDP.
>>
>> Shibboleth is all SAML based, and can work with other SAML based
>> services.
>>
>> Support for OTP or whatever then is only needed in the IDP.
>>
>>
>>> 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
>>>> [hidden email]
>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>>
>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: W3C takes on Web+SecurityElements

Douglas E. Engert


On 10/3/2012 2:04 PM, Anders Rundgren wrote:
> On 2012-10-03 20:45, Andreas Schwier wrote:
>> Hmmm, so why would I want an IDP if I could prove my identity
>> (certificate) and authenticity (client signature in SSL) with the
>> credentials I have on my card ?

The SSO aspect of the IDP... Using a smart card for every access is
an annoyance especially if you have many services a user uses on a daily
basis. It also allows for Federations. InCommon for example.

>>
>> Is it because SAML is easier to integrate than SSL client authentication
>> ? Or is it because I want my IDP (e.g. Google / Facebook) to know what
>> I'm doing ?

The IDP in our case is an enterprise IDP only usable by employees.

>>
>> The IDP model is perfect for username / password, but IMHO it's of less
>> use when you use keys and certificates. In the later case the CA is your
>> IDP by providing you with a certificate you can use to authentication
>> towards others (who trust that certificate issuer as they would trust
>> the IDP). And just lets wait for the first Diginotar incident at an IDP
>> - ops they've copied our SAML signing keys...)

Yes that is a concern.

>
> I think one of the reasons is that the folks that created TSL-client-certificate-authentication
> forgot to implement logout in a way that works for web applications.
>
> They claim that this is a "feature" and that I'm just to understand understand the beauty of it :-)
> So everybody has to write local IDPs using SAML or cookies even if they have
> PKI if they want to build anyhthing that looks like a real web app.
>
> Then there are of course other a very legitimate uses of IDPs where
> SAML attributes carry potentially completely alien information like
> a role which often is less suitable having in a certificate.

Yes, that too. We can map the certificate to an employee and pass
employee attributes. Especially helpful if the smart cards are issued by
some higher authority.

>
> Andes
>
>
>>
>> Andreas
>>
>> Am 03.10.2012 15:44, schrieb Douglas E. Engert:
>>>
>>> On 10/3/2012 5:08 AM, 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.
>>> The approach we are taking for SSO is Shibboleth.
>>>
>>> http://shibboleth.net/
>>>
>>> Using the X509 login handler:
>>>
>>> https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler
>>>
>>> OpenSC provides the client cert and key for TLS authentication to the IDP.
>>>
>>> Shibboleth is all SAML based, and can work with other SAML based
>>> services.
>>>
>>> Support for OTP or whatever then is only needed in the IDP.
>>>
>>>
>>>> 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
>>>>> [hidden email]
>>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>>>
>>
>>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel