- From: Harry Halpin <hhalpin@w3.org>
- Date: Fri, 11 Nov 2011 11:39:09 +0100
- To: David Dahl <ddahl@mozilla.com>
- CC: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, public-identity@w3.org
On 11/07/2011 06:11 PM, David Dahl wrote: > ----- 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've kept the original text as it seemed to be clear enough. However, I have added this sentence re scoping: "The main deliverable of the Working Group will be an API that offers cryptography primtivies to Web Application developers." > 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 that Virginie's text is now part of the charter. I also added re Channy that "management and validation of certificates" are out-of-scope. Anyone feel otherwise? >> 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. Agreed. Note that the smartcard based use-cases can be dealt with on a level of abstraction re generic key storage in the API. That will be tricky to do right, but much better I think than hard-coding smartcard requirements into the charter. >> 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 Friday, 11 November 2011 10:39:08 UTC