Re: RE : Web Cryptography Working Group scoping progressing...

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