- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Tue, 20 Mar 2012 22:13:32 +0100
- To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- CC: Harry Halpin <hhalpin@w3.org>, "public-identity@w3.org" <public-identity@w3.org>
Hi Virginie, Regarding standardization of key provisioning I'm advocating a solution that covers 80% of the (perceived) market. The 20% case will most likely lead to a crummy design and is better covered by custom solutions. In reality cost factors will probably make coverage 95% and that is in my mind a 100% success :-) Anders On 2012-03-20 15:44, GALINDO Virginie wrote: > Dear all, > > Few things about this conversation from gemalto perspective: > > * Call to discussion in IETF > Unfortunately gemalto will not attend next week IETF meeting, but would be pleased to get feedback from the planned discussions. Harry, we rely on you to share the expressed requirements to feed discussions in the Web Crypto API WG, when kicked off... > > * Secure storage > Several means to perform secure storage are existing depending on the targeted storage. As an example, invoking storage in trusted execution environment is described in GlobalPlatform specifications related to TEE [1], storage in secure element inserted in a mobile device is described in Open Mobile API delivered by the SIMAlliance [2] , and storage in TPM/MTM are described in TCGs specifications [3]. And in addition each operating system is providing some specific APIs to store locally some data . As a first step, an API providing an abstract layer to those different type of storage would definitely be beneficial to the industry, and this is why gemalto is supporting this activity in W3C (but as I have already mentioned in this mailing list, this will not help if we stop in the middle of the road, we might get this API rich enough to allow any type of storage, taking into account their security resistance). > > * On availability of smart card > SDKs and smart card samples are available on any smart card vendor (and not only gemalto one). Getting samples is just a matter of having the right contact, (me for example :-). Feel free to contact me, to see how we can support you. > > * on the standardization of key provisioning > As security provider, we have a certain experience of "enrollment and key provisioning in tokens", and something we learned by serving our customer is that key provisioning can sometimes have benefits to be 'standard', but need also to be flexible enough to answer specific customer requirements/injection constraints/certification schemes. And this is where you realize that it is a real job, not just a matter of having an API ;-) > In the recent past, the security industry has been standardizing the generation of keys in a token for third parties who do not want the token issuer to see the keys. This is described in GlobalPlatform "Confidential Card Content Management Card Specification v2.2 - Amendment A Version 1.0.1" [4], but it is the maximum that industry has accepted to standardize. Scenarios for pushing or pulling new keys in the token may look like ideas/principles captured by Mo blog. > > Hope it clarifies some points. > Regards, > Virginie > Gemalto > +33613232003 > > [1] http://www.globalplatform.org/specificationsdevice.asp > [2] http://www.simalliance.org/en/resources/specifications/ > [3] http://www.trustedcomputinggroup.org/ > [4] http://www.globalplatform.org/specificationscard.asp > > > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org] > Sent: mardi 20 mars 2012 13:50 > To: Anders Rundgren > Cc: public-identity@w3.org > Subject: Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83 > > On 03/20/2012 06:22 AM, Anders Rundgren wrote: >> On 2012-03-19 23:03, Harry Halpin wrote: >> >> I won't make it to IETF 83. Here comes a short presentation >> on how I envision that keys will be dealt with in the future: >> >> http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-com >> bo.pdf >> >> There is a Reference Implementation as well: >> http://code.google.com/p/openkeystore/source/browse/trunk/library/src/ >> org/webpki/sks/twolayer/se/SEReferenceImplementation.java >> http://code.google.com/p/openkeystore/source/browse/trunk/library/src/ >> org/webpki/sks/twolayer/tee/TEEReferenceImplementation.java >> > > Thanks Anders, I'll give this a look over before the meeting! > >> thanx, >> Anders Rundgren >> http://webpki.org/auth-token-4-the-cloud.html >> >>> Not sure how many people are making it to IETF83, but W3C is hosting >>> an onsite meeting on Thursday to discuss OAuth, BrowserID, OpenID, >>> and the upcoming W3C Web Cryptography Working Group. Everyone is invited! >>> >>> ==Beyond HTTP Authentication: OAuth, OpenID, and BrowserID== >>> >>> =Time and Location= >>> >>> Thursday lunchtime (1130 to 1300) in room 252A just between the SCIM >>> BoF and OAuth WG as part of IETF83 in Paris. >>> >>> = Problem Statement= >>> >>> While OAuth has solved the authorization problem, currently >>> authentication on the Web is still insecure as it has yet for the >>> most part failed to go beyond user-names and passwords. However, at >>> this point a number of new client-side capabilities, including the >>> possibility of W3C standardized Javascript cryptographic primitives, >>> are emerging and a number of specifications such as OpenID Connect, >>> BrowserID, and discussions over the future of HTTP Auth have shown >>> that there is interest in understanding better how client-side key >>> material can be used to enable a more secure Web authentication. >>> However, there has yet to be consensus on how client-side >>> cryptography can enable higher-security OAuth flows. The purpose of >>> this side meeting is to look at a more coherent picture of how >>> technologies in the space of identity, authentication, and >>> authorization combine and interact and to help frame future work in Web authentication. >>> >>> This informal meeting will present a number of proposed technical >>> proposals in brief, including relationships to other existing work >>> (such as RTCWeb and the upcoming W3C Web Cryptography Working Group), >>> and to help frame future work in the area.and then precede with open discussion. >>> >>> For any questions, please contact Harry Halpin (hhalpin@w3.org) >>> >>> =Schedule:= >>> >>> 11:30-11:45 Lightning presentations to "level-set" participants. >>> >>> Mike Jones (Microsoft) will present the latest work from JOSE and >>> OpenID Connect Eric Rescorla (Mozilla hat on) will present Mozilla >>> Persona and RTCWeb/WebRTC work Blaine Cook will present OAuth 2.0 >>> Harry Halpin (W3C) will present the upcoming W3C Web Cryptography API. >>> >>> 11:45-13:00 Open discussion on co-ordination between OAuth, HTTP >>> Auth, OpenID Connect, BrowserID, and W3C. >>> >>> > > > >
Received on Tuesday, 20 March 2012 21:14:14 UTC