RE: Comments on last call

On May 5, 2014 7:04 AM, "Salz, Rich" <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; Twitter: RichSalz
>
>