- From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Date: Wed, 9 Nov 2011 20:48:15 +0100
- To: Anders Rundgren <anders.rundgren@telia.com>
- CC: David Dahl <ddahl@mozilla.com>, "hhalpin@w3.org" <hhalpin@w3.org>, "public-identity@w3.org" <public-identity@w3.org>
Dear Anders, and all, I think we are sharing the same analyisis on the smart card accessability for Web Browser. And this is exaclty the reason why gemalto has decided to join W3C : to try to make available trusted technologies such as smart card or Trusted Execution Environment or TPM/MTM to webapp. Please note that we believe that different markets will require different security levels and thus each of those technologies are relevant for us. At the moment, those technologies are available to 'native applications', for different devices, such as PC, smart phone and TVs, thanks to standard 'drivers or APIs'. - access to smart card in PC is described by the old PCSC; - access to secure element (such as UICC or SIM card, or µSD, or embedded secure element) in mobiles is described by an Open Mobile API delivered this year by SIMAlliance, and is starting to be integrated in smart phones (see simalliance.org for more info) - access to TEE is described by a TEE Client API delivered by GlobalPlatform mast year, and is starting to be integrated in smart phones and tablets (see http://www.globalplatform.org/specificationsdevice.asp for more info) - acess to TPM or MTM is described by TCG (that you know well) is starting to be integrated in PC, mobile and tablets (see http://www.trustedcomputinggroup.org/) Gemalto believes that smart card access in mobile, TEE and TMP/MTM will become common features in devices in 2012/2013 and thus the open web platform may be able to get benefit from it, if prepared. The work which is related to Web Cryptography Working Group may overlap with this problematic, but i think that the key point today, is to make sure that "something under the Browser" is able to generate and garantee a proper key management. The challenge is to make sure that one of the possible "something under the Browser" may be a smart card, a TEE or a TPM/MTM (but not limited to), thanks to the APIs mentionned above. Hope this answers your direct question. Anyway, as mentionned previously, i am still not that comfortable with the complete charter and will come back with more comments in few days. Regards, Virginie ________________________________________ De : Anders Rundgren [anders.rundgren@telia.com] Date d'envoi : mardi 8 novembre 2011 20:53 Ŕ : GALINDO Virginie Cc : David Dahl; hhalpin@w3.org; public-identity@w3.org Objet : Gemalto. Was : Web Cryptography Working Group scoping progressing... Hi Virginie, A MAJOR problem for many customers is that there is no solution for enrollment/provisioning of smart cards from Web Browsers which makes smart cards a poor competitor to passwords. Physical card distribution is OK for the US government but sucks for most other parties. IMO there will be no breakthrough 2012/2013 (or ever), until this has gotten a suitable solution. What's Gemalto's take on this? DomCrypt does not address this issue although some people seems to believe so. Adding an API or two would not help either because you need an entirely new model than for example offered by <keygen> and "CertEnroll" since they do not even provide PIN-code deployment! Regards, Anders Rundgren On 2011-11-08 20:24, GALINDO Virginie wrote: > Hi David, and all > > ** on the charter, first paragraph > [david] I am not sure you are making too much of a distinction between what has been written and what you propose here. You specifically mention "web apps", which seems to be the difference. > [virginie] actually this was my intention, not changing the scope, just rewording and harmonizing classification of crypto features. > > > ** on the usecase targetted > [david] Yes, there will be a balancing act here: A general purpose API vs a large number of use-cases. Trying to appease too many use cases will hamper progress. > [virginie] how do we then balance the features ? personnaly I think that the trusted user interface (i mean enforced by hardware and software) may enter the market in 2012/2013, so it should be important to make sure we actually adress it for this time. I did not see any draft timing in the charter, and I am not (yet) familliar with W3C delivering processes. Harry, any rough dates ? > > More comments to come on the rest of the proposal. > > Regards, > virginie > > ________________________________________ > De : David Dahl [ddahl@mozilla.com] > Date d'envoi : lundi 7 novembre 2011 18:11 > Ŕ : GALINDO Virginie > Cc : hhalpin@w3.org; public-identity@w3.org > Objet : Re: RE : Web Cryptography Working Group scoping progressing... > > ----- Original Message ----- >> From: "GALINDO Virginie" <Virginie.GALINDO@gemalto.com> >> To: hhalpin@w3.org, public-identity@w3.org >> Sent: Friday, November 4, 2011 12:41:21 AM >> Subject: RE : Web Cryptography Working Group scoping progressing... >> Dear all, >> >> here are few comments related to the charter proposed for the Web >> Crypto WG and some answers to comments raised by the members on the >> mailing list. >> >> *** on the charter >> I would suggest the following amendments in order to harmonize the >> vocabulary used in the charter. >> >> “The primary features in scope are encryption, decryption, digital >> signature generation and verification, hash/message digest algorithms, >> confidentiality algorithms, key transport/agreement algorithms, HMAC >> algorithms, key pair generation, and key storage on the device. In >> addition, the API should be asynchronous and must prevent external >> access to secret material. “ >> --- To be transformed into --> >> “The primary features in scope of the API offered to webapp are all >> the basic cryptographic operations such as key generation, key >> storage, data encryption, data decryption, digital signature >> generation and verification, hash/message digest generation and >> verification. In addition, the API should be asynchronous and must >> prevent access to secrets by untrusted party (e.g unauthorized >> webapp).” >> > I am not sure you are making too much of a distinction between what has been written and what you propose here. You specifically mention "web apps", which seems to be the difference. > >> “Secondary features might include strong random number generation, API >> access to control of SSL/TLS logout, extracting keys from TLS >> sessions, extracting channel binding information from SSL/TLS >> sessions, PKI path validation, destruction of ephemeral keying >> material, storage of keying material on external datastores, and >> FIPS-140 compliance. “ >> --- To be transformed into ---> >> “Secondary features offered by the API might be strong random >> generation, control of session login/logout, extraction of keys from >> TLS sessions, PKI scheme validation, destruction of temporary >> credentials, storage of secrets in tamper proof or software resistant >> container.“ >> Note 1 : I have changed the notion of external datastores into >> technologies which can be caracterized by their security assets >> (resistant to hardware or software attack) as the notion of external >> database does not prevent the storage to be weak. > > OK, that sounds good > >> Note 2 : I have deliberately removed the mention to FIP-140 as it is a >> security certification program. I do not see how this could influence >> the API design in any way, as it is more a matter of security >> implantation. >> > > Indeed, I do not see how the API design would be impacted by FIPS. > >> *** on the use cases targeted >> >From the discussion we had, we separated the Crypto API from the >>> Identity work, in order to give us the freedom to address other >>> usecases. For example the DRM usecase has been evoked. And now people >>> would like to think about corporate and banking usecases. I guess we >>> should not restrict ourselves on the targeted market. All usecases >>> will definitely require the basics of the crypto, as listed in >>> Primary features. While market specific features may fall into the >>> second features. I would then suggest that the trusted user >>> interaction (entering a pin in a protected way) to be part of the >>> second features. > > Yes, there will be a balancing act here: A general purpose API vs a large number of use-cases. Trying to appease too many use cases will hamper progress. > >> >> Virginie Galindo >> gemalto >> ________________________________________ >> De : Brian Smith [bsmith@mozilla.com] >> Date d'envoi : vendredi 4 novembre 2011 00:37 >> Ŕ : Henry Story >> Cc : public-identity@w3.org; Harry Halpin >> Objet : Re: Web Cryptography Working Group scoping progressing... >> >> Henry Story wrote: >>> "API access to control of SSL/TLS logout, " >>> >>> +1 on that one. Thanks for adding it. >> >> Actually, I disagree that this is the proper place for this to be >> standardized, since there are also non-TLS scenerios where no crypto >> is used but where a logout mechanism is needed (e.g. for HTTP basic >> auth). >> >> I would prefer for the working group to focus on the crypto API. >> >> - Brian > >
Received on Wednesday, 9 November 2011 19:48:54 UTC