Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

Hi all,

I like the idea of using hardware tokens in the browser, not very strange
since i work at neXus which has provided the plugin-based integration for a
long time in Sweden in cooperation with BankID and Nordea (the biggest eId
providers in Sweden).

I have made a similar proposal previously, but then it was in the light of
the old charter and deemed not to be relevant (I can agree with that).
However it might be more relevant now with the next step of web-crypto and
so on.

In short, my proposal is to bind keys to origins with certificates and a
new certificate attribute/extension that specifies which origins the keys
should be available to.

By adding a new certificate attribute/extension (x509) it would be possible
to limit the access to keys (going inline with SOP). The origin extension
should be set hard and not be extendable/changeble later. It should not be
possible to set wildcards either, what would be useful is to have support
for multiple domains when moving from one domain to another or supporting
different domains for different countries. However wildcard should not be
allowed.

Exposing hardware tokens to this solution would be done in the same way as
today through P11, CSP etc. Then the browser would filter certificates
similarly to how it does for client ssl today, but by origin extension
instead of issuer and expose the resulting keys to the scripts on the page
(via web-crypto).

Access to keys must require HTTPS since otherwise one cannot be shore what
has been loaded i.e. the loaded page and scripts should be considered as
compromised.

This solution would allow the use of certificate-bound hardware-keys in the
browser. its a quite big limitation with only certificate bound keys, but I
think that most eID schemes that has come up on the mailing list are based
on certificates so it would not be a problem for those. Then there is the
symmetric keys that cannot be certified in the same way, once again for the
eID schemas that has come up its mostly about signing and authentication
and in those cases certified keys could be enough. If one would want to
work with encryption and symmetric keys I propose that the symmetric key is
wrapped with an asymmetric and that it is unwrapped into web crypto for
usage (possible as ephemeral keys).

With this solution a key bound to a certificate could be used in one or two
domains, for eIDs that are intended to be used across multiple services
this is a limitation, to solve this I propose that eID providers builds a
signing portal that the service provider application could interact with,
either via postMessage or with a redirect scheme similar to SAML. In Sweden
the eID infrastructure is rebuilt and to create signatures a redirect flow
is used which  based on SAML and DSS. Details about the new eID
infrastructure in Sweden can be found here (
www.elegnamnden.se/svenskelegitimation/upphandlingavunderskriftstjanst.4.133ff59513d6f9ee2eb2a3d.html)
some of the documents can be found in english. Further to keep sensitive
data from the eID service only the hash is sent over in then Swedish
solution.

Privacy is a big concern, and in a way it becomes even more sensitive when
there is full name, social security etc. in the certificate. It is therefor
good that only the web-page of the issuer that can access the certificates
and keys. It can then select to only hand out the personal information to
service providers that has signed a contract to behave. Further the user
could select not to accept usage of the keys (i.e. not enter pin for the
token when asked). I know this is different from how it is handled in many
countries as Ryan mention one should not trust the government or trusted
third parties. However in some (large) parts of the world the government is
trusted and not to trust the issuer of an eID sound contra initiative to
me, if I don’t trust them I should not request an eID from them.

When It comes to issuance and enrolment of keys to hardware I think that
should be out of scope. First because it adds lots of complexity. Secondly
for the use case of eID there is often a handout process showing the
physical id card, with this process the issuance could be done outside the
scope of web-crypto. Further the connection to physical persona which is a
vital part of LoA (Level of Assurance) hard to get right with self-service
(self-enrolment) and is not possible for the highest LoAs.

I think this would be a good solution with enough flexibility for eID usage
cases. Feel free to ask if anything in the proposal is unclear.

Best regards
//Samuel




On Tue, Feb 3, 2015 at 6:11 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2015-02-03 17:49, Siva Narendra wrote:
>
>> Is payments also an overkill?
>>
>
> Hi Siva,
> Was this question for me?
>
> From my point of view
>
>     "Secure AND Convenient Payments on the Web"
>
> haven't taken a single step forward the last 20 years or so.
>
> Given the importance of e-commerce these days it has rather moved backward.
>
> So whatever the solution there will be, payments MUST be a part of it.
> I guess Jeff agrees as well:-) http://www.w3.org/2015/01/
> banker_payments.pdf
>
> Best
> Anders
>
>
>> On Feb 3, 2015 6:02 AM, "Anders Rundgren" <anders.rundgren.net@gmail.com
>> <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>>     On 2015-02-03 14:31, Rigo Wenning wrote:
>>
>>         Anders,
>>
>>         On Tuesday 03 February 2015 12:42:07 Anders Rundgren wrote:
>>
>>             Although I agree with what you are saying there's a problem:
>>
>>             None of the stuff you are referring to has ever been directly
>> connected
>>             to the [UNTRUSTED] web, they are always used with a trusted
>> App + GU.
>>
>>
>>         if everybody had already thought about it, my contribution would
>> be noise. My
>>         apologies if this is the case. This is a chartering discussion.
>> If thinking
>>         about the eGov use case is overkill, we should state that openly
>> and move on.
>>         I just want this to be a conscious decision. This enables W3C to
>> respond if
>>         asked by the various governments.
>>
>>
>>     Hi Rigo,
>>
>>     eGov is definitely not overkill, the problem as I see it is that you
>> cannot develop
>>     things of this complexity without having a "team" dealing with the
>> different aspects.
>>
>>     Fortunately there's an alternative to shoehorning legacy-crypto in
>> the UNTRUSTED web:
>>     https://lists.w3.org/Archives/__Public/public-web-intents/__
>> 2015Feb/0000.html <https://lists.w3.org/Archives/Public/public-web-
>> intents/2015Feb/0000.html>
>>
>>     Best regards,
>>     Anders
>>
>>
>>
>>
>
>