Re: [WebCrypto.Next] Any ideas on how to proceed?

On 02/18/2015 08:59 AM, David Leon Gil wrote:
> W.r.t. WebCrypto-Next:
> It would be wonderful to see a few useful algorithms added to the spec:
> - a modern VOF (e.g., SHAKE256)
> - a fast hash function (e.g., BLAKE2b)
> - a sequential-hard KDF (e.g., scrypt)
> - some non-NSA curves

New algorithms are definitely within charter for the existing WebCrypto WG.

Note that we are aware and have the formal dependencies for the IETF
CFRG recommendation in terms of non-NIST curves.

For SHAKE256, BLAKE, and scrypt I suggest asking the WebCrypto WG if
they have any opinion and if such code can already be accessed via calls
to underlying platform (NSS/Windows/etc.) or would new underlying code
have to be written and distributed.

> as well as a slightly higher-level interface that makes it less
> complicated to do things like (cryptographically sound) ECDH without
> shooting yourself in the foot repeatedly. (I tried with the current
> API, and I have fewer toes.)

Yes, this is a design goal once we have the supported browser profile
properly worked out. I'd love to hear more about your thoughts and
experiences on this.

> There are some other things that would be great to see standardized in
> this area, but WebCrypto may not be the appropriate WG.

I believe there will be a survey shortly - again, this a discussion for
general Web Security, so whether or not something goes in WebCrypto or
not is not the most important question, the question is whether or not
we can get consensus for doing it, and if so, then we can find the most
appropriate existing Working Group or create a new one.

> On Tue, Feb 17, 2015 at 10:30 PM, Anders Rundgren
> <> wrote:
>> As you probably noted, all proposals related to
>> were shot down.
>> Are we waiting on something, and if so is the case, exactly what?
>> Is the idea of building on an already semi-established solution like Chrome
>> Native Messaging unacceptable?
>> Or should this disparate community rather standardize on U2F?
>> Another solution (IMO "workaround") is using local services supplying
>> "Security Services" through Redirects, XHR or WebSockets.
>> Since the (in)famous plugins were simply removed without any thoughts of the
>> implications, it seems that the browser vendors currently "own" this
>> question.
>> Anders

Received on Thursday, 19 February 2015 21:57:38 UTC