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

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

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Mon, 10 Mar 2014 21:44:40 +0000
To: Ryan Sleevi <sleevi@google.com>
CC: Mark Watson <watsonm@netflix.com>, Jim Schaad <ietf@augustcellars.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <5f8c68b235ec419eae39cff7ca074038@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
At least for ZRTP, it might be easier to do without deriveBits. CNG already implements the SP 800-108 KDF so this could potentially be hooked up without exposing the secret to JS.

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, March 10, 2014 2:31 PM
To: Vijay Bharadwaj
Cc: Mark Watson; Jim Schaad; public-webcrypto@w3.org
Subject: Re: Comments on RSA-PSS - March 7 Editors Draft



On Mon, Mar 10, 2014 at 2:13 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto: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:45:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:41 UTC