Re: Comments on last call

Regardless of the "broken crypto" concerns, just a quick note - Rich, 
are you formally requesting RC4, DES, and 3DES?

If so, can you add a quick bug to the spec:

https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=36153&product=Web%20Cryptography

   thanks,
       harry

On 05/05/2014 04:09 PM, Ryan Sleevi wrote:
>
>
> On May 5, 2014 7:04 AM, "Salz, Rich" <rsalz@akamai.com 
> <mailto:rsalz@akamai.com>> wrote:
> >
> > The WG clearly had some metric for choosing beyond just widely 
> available in browsers; why aren't RC4, DES and 3DES in the spec?
> >
>
> Because they have not yet been requested.
>
> > Nobody is expecting the WG to keep abreast of all cryptographic 
> research, but when people like Kenny You got advice in LC (and well 
> before, from Kenny Paterson), that there are problems with the 
> algorithms you did include; 
> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2014Apr/0003.html
> >
> >  No one is expecting an all-volunteer group to keep abreast of all 
> cryptographic research, but that's not what was being suggested or 
> asked for. You asked for comments, and experts (like Kenny, Russ, and 
> Stephen; not me) responded. My brief note suggested one possible way 
> forward, by providing a read-only interface. Or, as I alluded to, add 
> a "WeakCrypto" interface and put the encryption and signing methods 
> for the weak and broken algorithms there.  How do you know what to put 
> there?  You already got world-class advice in the thread I referenced 
> above.  Please listen to them.
> >
>
> We have - which is why SubtleCrypto exists. Proposals like WeakCrypto 
> are mere smokescreens that fail to provide any meaningful boundaries, 
> but do offer long-term harm towards API maintainability.
>
> As has been discussed - repeatedly - you can't programatically 
> separate the algorithms into two (or more) namespaces, because once 
> shipped, you can *never* migrate between them, as such migrations are 
> inherently breaking API changes.
>
> There are no requirements that a UA implement all of these. There are 
> no requirements - for or against - that a UA could prompt the user, 
> or, in the case of extensions/apps, require some additional permission.
>
> This API documents how - if implemented - an algorithm will behave.
>
> >         /r$
> >
> > --
> > Principal Security Engineer
> > Akamai Technologies, Cambridge, MA
> > IM: rsalz@jabber.me <mailto:rsalz@jabber.me>; Twitter: RichSalz
> >
> >
>