RE: ECC vs RSA, and Similar Conflicts

Dear all,

I am not sure it is the role of our WG to force the developers to use the state of the art of the cryptography. Furthermore, in order to address smooth migration of existing services, we might have to accept referencing "older" cryptography technology, the ones systems and people are used to at the moment. This will not prevent us from recommending in a separate guideline the good practices, as our charter allows us to do. 

The list of algorithms/key lengths will have to be discussed anyway. As support, we can use the official recommendations of regional security department, or industry specific recommendations. And rely on our own experience regarding current technologies used in the different markets we target. 

Regards,
Virginie 
gemalto  

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Thursday, May 10, 2012 6:58 AM
To: Nadim
Cc: public-webcrypto@w3.org
Subject: Re: ECC vs RSA, and Similar Conflicts

On Wed, May 9, 2012 at 10:33 AM, 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.

I don't really think it's a good idea to design a system which can't interoperate with the vast majority of signed data objects on the Internet, which use
SHA-1 and RSA.

-Ekr

Received on Thursday, 10 May 2012 09:24:42 UTC