Re: Web Cryptography Working Group scoping progressing - gemalto comments - part 2

> Dear all,
>
> as promised, some further comments on the charter available under :
> http://www.w3.org/wiki/IdentityCharter#Web_Cryptography_Working_Group_Charter
>
> * about the availibility of several key containers in the same device
> I would like to make sure that the deliverable the  group will issue will
> take into accoutn the fact that on a device several key containers may be
> the target  for key management. As an example, on the mobile security
> side, we are facing today the growth of multiple secure elements being
> present at the same  time on the same device, the PC/tablet will soon face
> the same situation with TPM co-existig with hardware secure elements. I
> think that we should help the application developers and browser makers to
> manage such situation. I do believe that it would be of interest for them
> to explicitely choose between a removable or a non-removable security key
> container, or a software based or hardware based container.
> --> I will suggest a sentence in that sense if I do not receive strong
> opposition.
>
> * about the out of scope paragraph of the charter
> I do not see how we can exclude the key identifer schemes from this API.
> What will happen if several applications from different service providers
> are managing their keys in the same container (which would be good,
> demonstratating the success of such API :-). How will the application
> invoke the right key, if provisionned in a previous session ? We
> definitely need a key identifier scheme, or an origin based key
> invokation, or something to ensure the multiple application scheme.
> --> I  would then suggest to remove this from the 'out of scope
> paragraph'.
>

I've added "non-opaque key identifiers (assuming by default all key
identifiers are opaque in the normal case), the availibility of multiple
key containers (in either hardware or software)" to secondary features we
*might* include. That would depend on time and discussion of the WG. Does
that work?

The point of the charter is to figure out more definitely what the WG will
not include so to keep the Working Group from wandering into new and
exciting rat-holes :) However, its important for us to cover the crucial
use-cases.

> Stay tuned, I might have other comments ;-)

Keep up the great comments! And feel free to add whole new sentences if
those I suggested don't cover your concerns.

>
> Regards,
> Virginie GALINDO
> gemalto
>
>
>
> ________________________________________
> De : Harry Halpin [hhalpin@w3.org]
> Date d'envoi : vendredi 11 novembre 2011 11:39
> À : David Dahl
> Cc : GALINDO Virginie; public-identity@w3.org
> Objet : 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 Thursday, 17 November 2011 15:10:40 UTC