Gemalto. Was : Web Cryptography Working Group scoping progressing...

Hi Virginie,

A MAJOR problem for many customers is that there is no solution for enrollment/provisioning
of smart cards from Web Browsers which makes smart cards a poor competitor to passwords.
Physical card distribution is OK for the US government but sucks for most other parties.

IMO there will be no breakthrough 2012/2013 (or ever), until this has gotten a suitable solution.

What's Gemalto's take on this?

DomCrypt does not address this issue although some people seems to believe so.
Adding an API or two would not help either because you need an entirely new model
than for example offered by <keygen> and "CertEnroll" since they do not
even provide PIN-code deployment!

Regards,
Anders Rundgren

On 2011-11-08 20:24, GALINDO Virginie wrote:
> Hi David, and all
> 
> ** on the charter, first paragraph
> [david] 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.
> [virginie] actually this was my intention, not changing the scope, just rewording and harmonizing  classification of crypto features. 
> 
> 
> ** on the usecase targetted
> [david] 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] how do we then balance the features ? personnaly I think that the trusted user interface (i mean enforced by hardware and software) may enter the market in 2012/2013, so it should be important to make sure we actually adress  it for this time. I did not see any draft timing in the charter, and I am not (yet) familliar with W3C delivering processes.  Harry, any rough dates  ?
> 
> More comments to come on the rest of the proposal. 
> 
> Regards,
> virginie
> 
> ________________________________________
> De : David Dahl [ddahl@mozilla.com]
> Date d'envoi : lundi 7 novembre 2011 18:11
> Ŕ : GALINDO Virginie
> Cc : hhalpin@w3.org; public-identity@w3.org
> Objet : 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 Tuesday, 8 November 2011 19:54:29 UTC