RE: [W3C Web Crypto WG] Deciding the algorithms supported by the API

I would agree with Eric. I don't think it is prudent to restrict the API to EC. Not having support for RSA will be big limitation, not only for backwards compatibility with existing systems, but also for developing new ones.

Regards,
--- asad 

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Monday, May 21, 2012 11:17 AM
To: Zooko Wilcox-OHearn
Cc: public-webcrypto@w3.org
Subject: Re: [W3C Web Crypto WG] Deciding the algorithms supported by the API

On Tue, May 15, 2012 at 9:44 AM, Zooko Wilcox-OHearn <zooko@leastauthority.com> wrote:
> The list of algorithms in your message, Virginie, looks like a good 
> selection of algorithms to me. It provides message authentication, 
> digital signature, public key encryption, and authenticated 
> encryption.
>
> I'm going to suggest a subset of that set, below.
>
> I don't yet understand what the use cases are, though, and I suspect 
> that we can't define a set of high-level algorithms that can satisfy 
> most of the needs of our ultimate users. Therefore, I think we'll have 
> to provide a low-level API if we want to facilitate those unknown, 
> future uses. (Which I do.)
>
> For example, if we standardize an AES block encryption function then 
> programmers could implement their own modes of AES encryption such as 
> CTR or OCB mode.
>
> But leaving aside that question for the moment, what set of algorithms 
> should we offer in the high-level API discussed here? One answer to 
> that could be that we need to offer algorithm X or Y in order to allow 
> interop with other systems or in order to allow compliance with other 
> standards or regulations. There are so many! There are a lot of 
> possible other systems, many standards and regs, that some future user 
> might need to accomodate. If we're going to try to help them with 
> that, we should start developing a catalog. But it will be huge. I 
> don't think it is a good approach to provide everything in the catalog
> -- instead I think we should provide the low-level API, which people 
> can then use to implement the specific algorithms that they have to.
>
> But I'll leave aside that question for now too.
>
> Having punted on the two hard questions, I'll now turn to a nice and 
> easy question: what is a set of good high-level algorithms?
>
> I think the list in your strawman has some redundant alternatives in 
> it. Here's my even slimmer strawman in which I omit all of the 
> suggestions that I think are redundant.
>
>> For signing/MAC:
>>    | HS256              | HMAC using SHA-256 hash algorithm            
>> |
>>    | ES256              | ECDSA using P-256 curve and SHA-256 hash     
>> |

Hmm... I realize that many people would prefer we only use EC, but I'm having a lot of trouble understanding the usefulness of a crypto API which can't interoperate with the vast majority of cryptographic systems in current deployment, which generally use RSA and/or DH.

-Ekr

Received on Monday, 21 May 2012 16:57:00 UTC