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

Clearly, I’m having a bad day.

I should have said Jim, not Richard.

And I just read Mark’s reply on the other fork of this thread, which explains that this was done to simplify the document. In the light of that explanation, the current organization makes a lot more sense.

One editorial suggestion – Microsoft protocol documents include a statement like this:

The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.

It may be worth including something like this at the beginning of section 14.3 to make it clear to implementers reading the specification that nothing in this section is intended to reduce their flexibility to make implementation choices.

From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
Sent: Friday, March 7, 2014 9:21 PM
To: Ryan Sleevi; Jim Schaad; Mark Watson (watsonm@netflix.com)
Cc: public-webcrypto@w3.org
Subject: 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<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.