- From: Ben Laurie <benl@google.com>
- Date: Tue, 8 Nov 2011 20:20:07 +0000
- To: David Dahl <ddahl@mozilla.com>
- Cc: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, hhalpin@w3.org, public-identity@w3.org
On 7 November 2011 17:11, David Dahl <ddahl@mozilla.com> 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 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. Well, it would prevent interoperability with many things - e.g. you can't use MD5 (yes, I know MD5 is being phased out, but it is not gone). > >> *** 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 20:20:41 UTC