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).”

“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.
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. 

*** 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. 

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, 4 November 2011 16:19:03 UTC