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

On Mar 7, 2014 9:21 PM, "Vijay Bharadwaj" <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]
> 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>
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.