W3C home > Mailing lists > Public > public-web-security@w3.org > October 2014

Re: Web Crypto - GlobalPlatform collaboration proposal

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 24 Oct 2014 17:23:22 +0200
Message-ID: <544A6EEA.5060606@gmail.com>
To: Colin Gallagher <colingallagher.rpcv@gmail.com>
CC: public-web-security@w3.org, noloader@gmail.com
On 2014-10-24 17:07, Colin Gallagher wrote:
>
> It would seem "the key" :-) to this is to ensure that no hardware/browser interaction or firmware/software upgrade would ever expose your private keys - transactions offline example http://www.bitcointrezor.com - (Sent from my mobile) -cg
>

It sure is hard to disagree on that :-)

Anders

> On Oct 24, 2014 7:33 AM, "Anders Rundgren" <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     <snip>
>
>         +1. Please don't do Key Transport. Coughing up a secret to any server
>         that answers is still a bad idea. Please don't back door it with
>         overrides and then claim they are "user approved".
>
>
>     Jeff,
>     What would the use-case be for "Coughing up a secret to any server"?
>
>     Anders
>
>
>         Jeff
>
>         On Thu, Oct 23, 2014 at 10:57 AM,  <gil.bernabeu@globalplatform.org <mailto:gil.bernabeu@globalplatform.org>> wrote:
>
>             Dear all
>
>             Following the W3C WebCrypto.next workshop that showed strong focus and
>             support for accessing HW security tokens, GlobalPlatform believes that there
>             are different use cases that need to be supported for Web applications, and
>             that different solutions should be considered jointly.
>
>
>             - Accessing to a crypto engine
>             -> W3C Webcrypto.next should allow selecting different crypto environment
>             such as software, Trusted Execution Environment (TEE) based, Secure
>             element(SE) based , ….this will allow a web app to perform the crypto
>             function in a environment compatible with his own risk management if
>             available in the device.
>
>             - Accessing to standardized services (eg FIDO, webpki ...)
>             - > W3C should create an unique API that combined with a specific middleware
>             automatically deployed (eg service or crypto environment specific) will
>             allow a Web App to be as independent as possible from each specific
>             implementation of the service
>
>             - Accessing to secure services that are not standardized (eg most of the SE
>             or TEE services today)
>             As part of the security rules, end 2 end security requirements doesn’t allow
>             the browser to create or modify an encrypted command to access a secure
>             services hosted in a TEE or in SE. The commands to be sent to an application
>             hosted in a TEE or in SE are created in a secure cloud and only needs to be
>             forwarded to the secure component. To support this market requirement, web
>             app needs to have a simple layer to pass command to the secure component.
>             W3C should allow web app to access to similar service as proposed by TEE
>             client API for the TEE or Open Mobile API for the SE presented by Herve
>             during the Workshop.
>
>             - Control of access HW security services – just as there are requirements on
>             control of access to a Secure Application from an OS, for instance
>             permissions based on identification of the client application, a similar
>             solution should be deployed to control access from websites to Secure
>             Applications.
>
>             GlobalPlatform is ready to provides with such web app open source APIs is
>             full collaboration with W3C environment.
>
>             Best Regards
>             ----------- Gil BERNABEU ---------------
>             GlobalPlatform Technical Director
>             http://www.globalplatform.org
>
>
>
>
Received on Friday, 24 October 2014 15:24:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:33 UTC