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

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.

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]
Sent: Friday, March 7, 2014 11:32 AM
To: Jim Schaad
Cc: 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.