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

CNG doesn’t implement a DH primitive – it implements a DH-based key agreement primitive which is plain DH + a KDF. The default providers don’t currently support DH with a null KDF (which is what you’re asking for) since this is neither safe nor broadly useful in practice. As of Windows 8 we also implement a standalone KDF primitive which as you note allows user-specified keys since this is a known safe and broadly useful piece of functionality.

It’s possible to implement and install a new CNG provider that supports DH with a null KDF – at some level, it’s all software and software can be extended – but this would not be in the default implementation. The reason is not ideological – it’s just that, as said above, this is neither safe nor useful. So in theory it’s possible that DH deriveBits would be possible when such a provider was installed on the user’s system, the common case would be that only deriveKey would work with most DH keys.

Let me ask a slightly different but perhaps related question – do you believe that an implementation that always created all its keys with extractable=false (so you could never export private keys from this implementation) would be compliant to the spec?

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


On Mar 7, 2014 9:21 PM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
>
> Thanks for bringing this up, Richard.
>
>
>
> I did point out the same issue in http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0019.html - CNG only allows a KDF to be performed on the Z value, and this is more secure (the bits of the secret are not unbiased so should not be used directly). Our implementation would likely just disallow the deriveBits key usage with ECDH and DH, and I believe that would be consistent with the spec today.
>

That's a spec bug, if so.

An implementation that implements an algorithm MUST implement all the operations - or at least, that should be the requirement. Otherwise you run into situations where you can roach-motel the API and still be conformant - eg: generate a key but never permit any operations with it.

The KDF issue should hardly seem a technical level blocker - you can just use a NoOp hash provider to memoizd Z and spit it back out.

This is fundamentally functionally identical to what CNG is providing developers today via the Alg extension method - a chance to implement any necessary custom KDFs for the appropriate protocols. We're just exposing this to JS - for the exact same reason CNG does: so that we don't have to support/implement every KDF under the sun to be useful to authors.

So is the objection ideological, rather than technical? If so, how does this square with the ability to register custom KDFs that can be fed the secret - something both CAPI and CNG support?

>
>
> However, you do bring up a good point – the table of algorithms still says ECDH and DH support deriveKey, but those subsections have vanished from the relevant algorithm specifications.
>
>
>
> Mark, is this an editorial cut-and-paste mishap, or was it intentional?
>
>
>
> From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
> Sent: Friday, March 7, 2014 11:32 AM
> To: Jim Schaad
> Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
> Subject: Re: Comments on RSA-PSS - March 7 Editors Draft
>
>
>
>
>
>
>
> On Fri, Mar 7, 2014 at 11:15 AM, Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:
>>
>> 1.  It should be noted that RFC 4055 from the PKIX group makes the
>> parameters field optional for id-RSASSA-PSS.  This means that depending on
>> the standard used, these fields may be absent when importing the key.
>>
>> 2.  What happened to the deriveKey descriptions.  I would like to point out
>> that Microsoft using CNG does not have the ability to get to the secret
>> value from aa DH key agreement operation.  They will be completely unable to
>> implement the current specification using their current code.
>
>
>
> I would prefer that we allow implementors to speak for themselves.
>
>
>
> While Vijay is correct in stating that Z is not directly exportable, and instead fed to a hash algorithm, one can simply create a new CNG hash provider that no-ops (eg: returns Z when told to H(Z)), to obtain Z.
>
>
>
> So it's certainly *technically* possible.