Re: ACTION-84: Finishing support for key derivation/key agreement (take 2)

On Tue, Jul 23, 2013 at 1:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Monday, July 22, 2013 3:58 PM
>> To: Jim Schaad
>> Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Richard Barnes; Israel
> Hilerio
>> Subject: Re: ACTION-84: Finishing support for key derivation/key agreement
>> (take 2)
>>
>> On Mon, Jul 22, 2013 at 3:41 PM, Jim Schaad <ietf@augustcellars.com>
>> wrote:
>> >
>> >
>>
>> Correct - but it was based on a misunderstanding of Vijay's proposal.
>>
>> I understood the original proposal was that Z would be fed directly into
> the
>> KDF, and the key returned was the derived key. However, after reading this
>> again, I see that the Key returned wraps Z as a 'raw'
>> key.
>>
>> So the only issue here is that the algorithm (derivationAlgorithm) may be
>> something being polyfilled - in which case, a native implementation cannot
>> execute the algorithm normalization parameters or handle it for a
> polyfilled
>> case.
>>
>> Normally, a JS application would use any of the ES5/ES6 methods available
> to
>> intercept and/or wrap window.crypto.subtle's prototype with its own
>> extensions. However, in this case, it can't intercept the derivedKey
> algorithm.
>>
>> However, this issue exists in the current ED as well - the
> derivedAlgorithm
>> parameter (which isn't even specified fully - oops!) has the same issues.
>>
>> Off the top of my head (eg: not having fully considered the implementation
>> complexities/realities), I can see a couple solutions, but they all feel a
> bit
>> gross:
>> - Expose a meta 'raw' algorithm to allow a Key object to be created that
> can
>> then be exported
>> - Expose a meta 'raw' KDF, for which deriveBits() just exposes the key
> bits
>> - Expose some 'secret agree bits' function
>>
>> Of this, I'm inclined to go for a 'raw' KDF, but if anyone else has better
>> suggestions, I'm all for it.
>
> I can think of one other way to handle this which would address some other
> problems:
>
> Make the crypto interface read-only
> Add a new function to allow for adding a new crypto algorithm which contains
> a name and a set of functions for implementing the different routines.
>
> The environment can then make the calls back into JavaScript for those
> algorithms which are implemented there and stay in the browser for its own
> implementations.
>
> Algorithms could then define additional things to put into the definition
> structure.  As an example RSA signature algoirthms could say that if you
> place and oid field in the definition, a newly defined hash algorithm could
> be used in RSA v1.5 signatures  (If implemented and permitted by the
> environment.)   This would allow for newly defined hash algorithms to be
> used in a number of different places without any new problems.
>
> Jim

This was considered early on and is highly inconsistent with the web
platform and with general ES5/6 design.

Received on Tuesday, 23 July 2013 20:52:11 UTC