RE: ECC vs RSA, and Similar Conflicts

I don’t believe any standard that wants to be adopted widely in the near future can exclude SHA1 or RSA. A more important thing to consider is how a standard would evolve as weaker algorithms get broken and betters ones (e.g. SHA3) get developed. We should also consider geographies that have their own crypto stacks such as GOST.


Thank you,

Alex Radutskiy
Senior Program Manager, Windows PKI

alex.radutskiy@microsoft.com



From: Nadim [mailto:nadim@nadim.cc]
Sent: Wednesday, May 09, 2012 2:56 PM
To: Jarred Nicholls
Cc: public-webcrypto@w3.org
Subject: Re: ECC vs RSA, and Similar Conflicts

Here's an interesting question, then:
Let's assume, for the sake of argument, that SHA2 is widely recognized as being a better alternative to SHA1. However, SHA1 is not only far from broken, but is also as widely used as SHA2, if not more.

What happens in such a scenario? Do we implement only SHA2 (knowing it to be more secure) or do we still include SHA1, even if it's the less secure alternative?

NK


On Wednesday, 9 May, 2012 at 5:52 PM, Jarred Nicholls wrote:
On Wed, May 9, 2012 at 1:33 PM, Nadim <nadim@nadim.cc<mailto:nadim@nadim.cc>> 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

It might be difficult for the API spec to attempt to enforce certain algorithms as normative, where a vendor must implement support for that algorithm or be declared non-compliant; versus suggesting/recommending particular support.  I'll admit I am naive in this area, but I see this somewhat analogous to HTML5 <video> and codecs that browser vendors choose to support.  This is of course why the API should be as agnostic as possible, which is difficult to do and quite a different situation than HTML5 <video> & codec support.

So it is of my opinion that the browser vendor could choose to support the new standards, or RSA, or both.  The API ought to allow for this.

Cheers,
Jarred