Re: Crypto HW. Re: Web Cryptography Working Group scoping progressing...

On 2011-11-28 22:31, Frederick.Hirsch@nokia.com wrote:
> +1 to concerns raised by Stephen and Anders.

Thanx!

> related to original proposal to provide API to provide info about device, 
> that opens yet another door for fingerprinting privacy attacks.

This is indeed a correct observation.  My suggestion (and implementation...)
builds on a scheme that permits fairly extensive device privacy at the expense
of secure device binding.  I.e. when the issuer requests a "keygen" operation
the user will be alerted if the request specifies that it needs the device ID.

> (perhaps the situation is now such that it does not matter, given the
> wealth of information already available).

I added the privacy enabled option to not limit the scheme to banks, governments,
and employers.  Critical mass is everything :-)

> Establishing level of key protection, processing etc via API might
> make things somewhat complex... Maybe there is a v1 vs v.next approach
> needed here.

I have always toyed with the idea that we need an *architecture* that allows
different level of protection while keeping the API/Protocol/GUI/BrowserBinding/Middleware
intact.  This is also what the TrustedComputingGroup have selected for TPMs.

Regards
Anders

> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Nov 22, 2011, at 2:19 PM, ext Anders Rundgren wrote:
> 
>> On 2011-11-21 23:51, Stephen Farrell wrote:
>>>
>>> Personally, I'd be surprised if its sufficiently easy to support
>>> crypto h/w that javascript programmers will find it usable.
>>
>> It is worse than that.  If you take a look on the Java API referred to below
>> this API was designed to be used by "trusted applications".  Downloaded
>> JavaScript running in a browser window is by definition not trusted and
>> essentially every call would require a GUI alert.  If you go down one
>> level and target ISO 7816 APDUs the number of alerts would make the
>> system completely useless.
>>
>> If the smart card industry wants an API callable from a browser window
>> they need a plan.  We'll probably have to wait forever on that one.
>>
>> Microsoft spokesmen claim that their "MiniDriver" is the answer.
>> If that actually is the case one wonder why they haven't come up
>> with some kind of spec.
>>
>> Anders
>>
>>
>>
>>>
>>> Maybe develop one spec that ignores h/w and one that doesn't and
>>> see if the latter is really as simple as the former. I expect
>>> those with an interest in h/w would be happy to work on that and
>>> demonstrate that their requirements can also be met with a "simple"
>>> API. (But I believe they'll fail.)
>>>
>>> S
>>>
>>> On 11/21/2011 04:15 PM, Axel.Nennker@telekom.de wrote:
>>>> I agree that implementing access to smart cards and SIM cards is difficult but on the other hand why shouldn't we provide a javascript API that makes it possible? If somebody implements HW access then it should be done through an API defined by this group.
>>>>
>>>> We could define an optional parameter that identifies the HW (Type, Provider, ...)
>>>>
>>>> Axel
>>>>
>>>> http://download.oracle.com/javase/6/docs/api/java/security/KeyPairGenerator..html
>>>> static KeyPairGenerator<http://download.oracle.com/javase/6/docs/api/java/security/KeyPairGenerator.html>  getInstance<http://download.oracle.com/javase/6/docs/api/java/security/KeyPairGenerator.html#getInstance%28java.lang.String%29>(String<http://download.oracle.com/javase/6/docs/api/java/lang/String.html>  algorithm)
>>>>           Returns a KeyPairGenerator object that generates public/private key pairs for the specified algorithm. static KeyPairGenerator<http://download.oracle.com/javase/6/docs/api/java/security/KeyPairGenerator.html>  getInstance<http://download.oracle.com/javase/6/docs/api/java/security/KeyPairGenerator.html#getInstance%28java.lang.String,%20java.security.Provider%29>(String<http://download.oracle.com/javase/6/docs/api/java/lang/String.html>  algorithm, Provider<http://download.oracle.com/javase/6/docs/api/java/security/Provider.html>  provider)
>>>>           Returns a KeyPairGenerator object that generates public/private key pairs for the specified algorithm. static KeyPairGenerator<http://download.oracle.com/javase/6/docs/api/java/security/KeyPairGenerator.html>  getInstance<http://download.oracle.com/javase/6/docs/api/java/security/KeyPairGenerator.html#getInstance%28java.lang.String,%20java.lang.String%29>(String<http://download.oracle.com/javase/6/docs/api/java/lang/String.html>  algorithm, String<http://download.oracle.com/javase/6/docs/api/java/lang/String.html>  provider)
>>>>           Returns a KeyPairGenerator object that generates public/private key pairs for the specified algorithm.
>>>>
>>>>
>>>>
>>>>
>>>> From: Channy Yun [mailto:channy@gmail.com]
>>>> Sent: Montag, 21. November 2011 16:44
>>>> To: Anders Rundgren
>>>> Cc: public-identity@w3.org
>>>> Subject: Re: Crypto HW. Re: Web Cryptography Working Group scoping progressing...
>>>>
>>>>
>>>> 2011/11/22 Anders Rundgren<anders.rundgren@telia.com<mailto:anders.rundgren@telia.com>>
>>>> On 2011-11-21 15:08, Richard Barnes wrote:
>>>>> Hey Harry,
>>>>>
>>>>> I think that's about the right balance.  It seems like what this API should
>>>>> do is provide a set of primitives that can be provided by different types of
>>>>> cryptographic services:
>>>>> -- The browser
>>>>> -- The OS
>>>>> -- A TPM
>>>>> -- A smart card
>>>>> -- An HSM
>>>>> -- Etc.
>>>> I think this is a somewhat dangerous conclusion.
>>>>
>>>> DomCrypt (AFAICT) supports the *Creation* and *Usage* of cryptographic keys
>>>> in some kind of "browser storage".  Extending the *Creation* part to the
>>>> set of containers listed would extend the scope by a mile.
>>>>
>>>> +1
>>>>
>>>> But, I agree there is a need of interface for import/export of certificates from security devices.
>>>> In Firefox, the validation of security device based on FIPS is already possible. (Other browser?)
>>>> I guess Web Certificate Service API is needed to treat this kind of interfaces in future.
>>>>
>>>> Anyway we have better focus on primitive APIs for light-weight usecases.
>>>> Because all browsers have own key stroage. :)
>>>>
>>>> Channy
>>>>
>>>>
>>>> In addition, DomCrypt isn't suited for *Usage* by traditional kinds of tokens,
>>>> particularly not for signature operations.
>>>>
>>>> That you could implement "browser storage" in a TPM is IMO an entirely
>>>> different thing and *IS* of course within scope.  That would though be
>>>> a platform/configuration issue and not require any user interaction.
>>>>
>>>> With "browser storage" I mean storage that is domain-oriented.  Traditional
>>>> tokens are unrestricted, at least from a crypto client point of view.
>>>>
>>>> *If* some implementers still believe that "container selection" is a
>>>> good idea for a light-weight domain-oriented solution, they can of
>>>> course add such a (confusing) step without touching the API.
>>>>
>>>> Anders
>>>>
>>>>>
>>>>> The one thing that seems like it would be required, though, is some way for applications to choose between these options, or at least know which of them is providing its crypto.  This would seem to call for a way for these things to be identified, probably by time (e.g., in something like the above taxonomy) and by instance (e.g., some identifier for a smart card).
>>>>>
>>>>> Suggested text for an item in scope: "Identification of the hardware or software service that is providing cryptographic services".
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Nov 17, 2011, at 9:48 AM, Harry Halpin wrote:
>>>>>
>>>>>>> IMO it doesn't make sense to include explicit support for Crypto HW
>>>>>>> in a W3C WG.
>>>>>>>
>>>>>>> Rationale: This is already a lost case since the smart card industry
>>>>>>> haven't even begun thinking about this issue although quite a bunch
>>>>>>> of their favorite customers including the financial sector and
>>>>>>> Government actually do request solutions that allow them to get
>>>>>>> away from all the proprietary plugins they currently use.
>>>>>>>
>>>>>>> These guys have developed a "de jure" standard:
>>>>>>> http://www.w3.org/2008/security-ws/papers/ISO24727-for-secure-mobile-web-applications-2008-10-30.pdf
>>>>>>> Nobody outside of their backyard cares about it.
>>>>>>>
>>>>>>> BTW, I have yet to see a single proposal that bridges the gap
>>>>>>> between the JS/JSON people and the ISO-7816/GP folks.  They have
>>>>>>> probably never met :-)
>>>>>>>
>>>>>>> Please don't take this as criticism, it is just a friendly advice.
>>>>>>
>>>>>> Currently the charter does not explicitly include smartcard support or
>>>>>> reference to any of the ISO standards around smartcards.
>>>>>>
>>>>>> However, the charter does include "key storage on the device" but puts out
>>>>>> of scope "device-specific access to keying material" [1]
>>>>>>
>>>>>> The idea is that through some platform-specific tool, it might be possible
>>>>>> to load a key from a smartcard from the JS API, but that the API itself
>>>>>> would not include "special smartcard" specific instructions. Thus, the
>>>>>> burden of doing that would lie on the smartcard programmers, not the
>>>>>> browsers.
>>>>>>
>>>>>> Is that enough? Is there any different terminology you would prefer?
>>>>>>
>>>>>>            cheers,
>>>>>>                harry
>>>>>>
>>>>>> [1] http://www.w3.org/wiki/IdentityCharter
>>>>>>
>>>>>>>
>>>>>>> Anders
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 
>

Received on Wednesday, 30 November 2011 14:28:20 UTC