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

> -----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

> 
> >
> > The value of Z appears to be to be passed to the importKey algorithm,
> > but it is not clear what is returned in the resolve since that is
> > saying value not result.
> >
> 
> I don't understand what you mean here. Vijay's text seemed clear on this
> point:
> 
> 11.  Let result be the result of executing the importKey algorithm [...]
12. [...]
> 13. Execute resolver's resolve(value) algorithm, with result as the value
> argument.

Received on Tuesday, 23 July 2013 20:50:28 UTC