- From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Date: Tue, 8 Nov 2011 20:24:44 +0100
- To: David Dahl <ddahl@mozilla.com>
- CC: "hhalpin@w3.org" <hhalpin@w3.org>, "public-identity@w3.org" <public-identity@w3.org>
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 Tuesday, 8 November 2011 19:25:12 UTC