W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

Re: Comments on RSA-PSS - March 7 Editors Draft

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 10 Mar 2014 14:30:38 -0700
Message-ID: <CACvaWvb0pYcJZpswEpoLHStkXV894ZxreWpYj1PqOTOvgv3Mkg@mail.gmail.com>
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Cc: Mark Watson <watsonm@netflix.com>, Jim Schaad <ietf@augustcellars.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Mar 10, 2014 at 2:13 PM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

>  Yes, we’re talking about NCryptSecretAgreement + NCryptDeriveKey.
>
> Ø  If Microsoft does not plan to implement this functionality, it would
> be an excellent time to register the feedback. Its entirely reasonable to
> provide that feedback - IndexedDB's sync interfaces, which Israel also
> mentioned previously, are something in the spec but not widely implemented,
> so it's not unprecedented.
>
> More precisely, I’m saying that this functionality is not currently
> possible to implement on top of the OS crypto libraries in existing Windows
> OS platforms. We had originally expressed this as a goal of WebCrypto (i.e.
> not to have browsers implement crypto but to give access to the underlying
> OS crypto for scripts), so this is an issue.
>
>
>
> That said, I don’t think that this is really that big of an issue. Maybe
> it would be good to get feedback from the community on whether anyone cares
> deeply about running deriveBits with (EC)DH, and that could then be used to
> determine how to prioritize it.
>

It's entirely possible we punt this as a general "Polyfills as second class
citizens", as we've done for RSA/ECDSA (by virtue of not allowing pluggable
hash functions or 'raw' primitives). It's the same implementation choice
that prevents a JS polyfill of something like RSA-KEM, since the RSA
primitive isn't exposed.

The use case here is for implementing something like ZRTP -
http://tools.ietf.org/html/rfc6189#section-4.4.1.4 - in JS. One can totally
implement the ZRTP KDF in JS "securely" (that is, without the risks of
timing that generally underscores polyfill risks), even if the DH secret is
(briefly) exposed to JS.

We're looking at this *not* simply as a "Web" API - but also representing
the set of cryptographic primitives exposed to Apps/Extensions, which in
W3C terms is "SysApps" - http://www.w3.org/2012/sysapps/

The alternative to exposing deriveBits means the UA having to implement the
ZRTP KDF.
Received on Monday, 10 March 2014 21:31:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC