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 Monday, 7 November 2011 17:12:50 UTC