RE: ECC vs RSA, and Similar Conflicts

I believe it is a very important use case to be able to create a key that is secured by hardware such as TPM or smart card. Even software keys isolation (i.e. keeping key material in a separate process from the application that is using it) will be useful. For example, if an application is compromised it will not be possible to extract a key and send it somewhere for later use. 

In all of those examples, you need a model that can simply reference keys by some IDs when performing crypto operations without directly interacting with key material. 

Thank you,

Alex Radutskiy
Senior Program Manager, Windows PKI

alex.radutskiy@microsoft.com 



-----Original Message-----
From: David Dahl [mailto:ddahl@mozilla.com] 
Sent: Thursday, May 10, 2012 9:35 AM
To: Cullen Jennings
Cc: Richard L. Barnes; Nadim; public-webcrypto@w3.org
Subject: Re: ECC vs RSA, and Similar Conflicts

If you are referring to the Netflix use-case, the browser in question is an embedded webkit browser inside a blu-ray player. The Netflix use case is about identification of said blu-ray player to know what kind of streams it can accept and if it is authorized to view streams in the first place. The keys are pre-positioned by the blu-ray manufacturer.

I doubt this API will be used to decode encrypted video produced in Hollywood, I could be wrong.

David


----- Original Message -----
From: "Cullen Jennings" <fluffy@cisco.com>
To: "David Dahl" <ddahl@mozilla.com>
Cc: "Richard L. Barnes" <rbarnes@bbn.com>, "Nadim" <nadim@nadim.cc>, public-webcrypto@w3.org
Sent: Thursday, May 10, 2012 11:15:51 AM
Subject: Re: ECC vs RSA, and Similar Conflicts


I get what you are saying but I would like to push on making sure we have a complete solution. How do the private keys get into the browser? And if the private keys are for DRM protected video running in an open source browser, what does the whole system look like to make this work. 

I'm not arguing against something like this, I just want to understand the big picture so I understand the requirements for this work. 



On May 10, 2012, at 8:30 AM, David Dahl wrote:

> One of the reasons for establishing this WG is to try and provide a more secure way of using crypto on the web. Keeping the private keys private is at the top of this list. We can establish a spec that only ever references private key IDs, making this much more secure than existing JS crypto libraries that have access to private key material.
> 
> David 
> 
> ----- Original Message -----
> From: "Richard L. Barnes" <rbarnes@bbn.com>
> To: "Cullen Jennings" <fluffy@cisco.com>
> Cc: "Nadim" <nadim@nadim.cc>, public-webcrypto@w3.org
> Sent: Thursday, May 10, 2012 9:18:44 AM
> Subject: Re: ECC vs RSA, and Similar Conflicts
> 
> Note, however, that that approach would require that private keys be exposed to the JS layer.  It seems like we have at least some use cases (e.g., the Netflix cases) where maintaining the secrecy of the private key is important.
> 
> --Richard
> 
> 
> 
> On May 10, 2012, at 9:42 AM, Cullen Jennings wrote:
> 
>> 
>> One way to deal with the ECC / RSA issues is instead provide the underlining big math libraries that are needed to implement these and leave the actually IPR encumbered implementation to an JS library. If done right, this would could have approximately the same performance as a native implementation. 
>> 
>> 
>> On May 9, 2012, at 11:33 AM, Nadim wrote:
>> 
>>> Hi everyone,
>>> I think we need to have a discussion regarding whether the API will exclusively implement (and rely on) newer, faster standards (such as ECDH, ECDSA) or whether there will be a larger dependence on RSA, either for fallback or stronger compatibility reasons.
>>> 
>>> If it is eventually decided that not only the best available per-task algorithm is implemented, but rather, all possible algorithms, where do we draw the line? Do we implement SHA1 in addition to SHA2? Does that also warrant an MD5 implementation?
>>> 
>>> Personally, I believe that focusing only on the newer, more efficient standards (such as ECC) is a better idea, but I stand very humbly by my opinion and a much more interested in listening to the group's opinions.
>>> 
>>> Thank you,
>>> NK
>> 
>> 
> 
>

Received on Thursday, 10 May 2012 16:56:58 UTC