Re: Algorithm support - "Native" versus "Polyfilled"

It does not.

That said, there are two levels of "not supported" here. If the U-A
supports it and is implemented in terms of providers (and not all libraries
are or U-As will be), it can export the key material from one provider and
import it into the other, all without giving the raw key material to JS.

The second level is where the U-A doesn't support the KDF at all, at which
point, to poly fill in JS, the JS *MUST* have the key material.

Both of these are understood and fit within the design requirements, but
thank you for noting. This is no different than how "native" code behaves
today.
On Dec 3, 2012 11:33 PM, "Anders Rundgren" <anders.rundgren@telia.com>
wrote:

> The Web Crypto API doesn't rely on a provider concept like most other
> cryptographic APIs do.
>
> A provider only supports a specific set of algorithms and it is usually
> impossible to expand the set without exporting the key material in clear.
>
> Let's say that you want to do a ECDH operation with a specific KDF and the
> provider doesn't support the KDF you want to use.  AFAICT you are stuck
> unless the provider also supports "raw" ECDH which allows polyfilling of
> the missing KDF.
>
> I don't quite understand how the Web Crypto API deals with this issue.
>
> Anders
>
>