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:[email protected]] > Sent: mardi 20 mars 2012 13:50 > To: Anders Rundgren > Cc: [email protected] > 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 ([email protected]) >>> >>> =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. >>> >>> > > > >
