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

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