W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2012

Re: ECC vs RSA, and Similar Conflicts

From: Jarred Nicholls <jarred@webkit.org>
Date: Wed, 9 May 2012 17:52:31 -0400
Message-ID: <CANufG2NSmNtOMyFsAML5rpwtVxNjBt7+MPnQS2_j3prm1Z=yuw@mail.gmail.com>
To: Nadim <nadim@nadim.cc>
Cc: public-webcrypto@w3.org
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
Received on Wednesday, 9 May 2012 21:53:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC