Re: ECC vs RSA, and Similar Conflicts

As you know, SHA2 issues were already solved of most of web modern browsers
except Windows XP SP2 or older users. Most of them support SHA2 based EV
SSL certificates and  recommend upgrade of older browsers. As Jarred said,
the force of agent implementation is risk.

Instead of, we can recommend SHA2 for Javascript hash example in spec. It
already includes RSA2048 and SHA512 in
http://www.w3.org/2012/webcrypto/WebCryptoAPI/

Thanks,

Channy
---------------------
Mozilla Korea Community, http://www.mozilla.or.kr
Technology Evangelist, Daum Developers Network & Affiliates
http://dna.daum.net






2012/5/10 Nadim <nadim@nadim.cc>

>  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> 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
>
>
>