Re: Unwrap Questions - How do I do this?

On Tue, Jan 28, 2014 at 1:20 PM, Jim Schaad <ietf@augustcellars.com> wrote:

>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Tuesday, January 28, 2014 1:04 PM
>
> *To:* Jim Schaad
> *Cc:* public-webcrypto@w3.org
> *Subject:* Re: Unwrap Questions - How do I do this?
>
>
>
>
>
>
>
> On Tue, Jan 28, 2014 at 12:54 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>
>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Tuesday, January 28, 2014 12:13 PM
> *To:* Jim Schaad
> *Cc:* public-webcrypto@w3.org
> *Subject:* Re: Unwrap Questions - How do I do this?
>
>
>
>
>
>
>
> On Tue, Jan 28, 2014 at 11:58 AM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>
> I am having a problem with the current description of the unwrapKey
> method.  I am going to try and lay out my understanding in the hope the
> somebody will tell me what I got wrong.
>
>
>
> Starting Point:
>
>
>
> wrapKey is in the browser
>
>                 wrapKey.type = secret
>
>                 wrapKey.extractable = false
>
>                 wrapKey.algorithm = “AES-GCM”
>
>                 wrapKey.usages[] = [unwrapKey]
>
>
>
> keyData = ENCRYPTED(
>
> ‘{“kty”:”oct”, “k”:”ABCDEFGHIJKLMNOP”,”alg”:”Magic”}’
>
> )
>
>
>
>
>
> First I am going to just use the normal call and attempt to unwrap the key
>
>
>
> unwrapKey(“jwk”, keyData, wrapKey, {name:“AES-GCM”},  null, true,
> [encrypt, decrypt])
>
>
>
> This will fail because the browser does not implement the algorithm Magic
> and through an error in step #12 of the unwrap algorithm (the import is
> going to fail because of “Magic”).
>
>
>
> My code then says – that is fine – I have  a script version of Magic that
> I have downloaded as well so I can run the algorithm in script rather than
> in the browser.
>
>
>
> Step #2 – Call my internal script unwrapKey function.
>
>
>
> I can successfully complete steps #1-9 without any problems in the script.
>
>
>
> I am now going to attempt to deal with step #10.  This says that I need to
> decrypt the bytes of keyData using the value of wrapKey.  In order to do
> this I could call the decrypt function, but that will fail because it does
> not have the decrypt key usage.  I could export and have AES-GCM in the
> script, but that fails because the key is not exportable.  I could call an
> undocumented function which does the decryption operation, but that is not
> documented.
>
>
>
> I am not sure what my script code is supposed to be doing at this point.
>
>
>
> Jim
>
>
>
>
>
>
>
> Jim,
>
>
>
> There is no undocumented function which does the decryption operation.
> Your polyfill (which is what it is) will not work in this case. It's as
> simple as that.
>
>
>
> Supporting polyfill-extended algorithms (eg: where JS registers its own
> implementation of some algorithm) is not something this WG has done. So
> there's no hidden feature you're missing - it's not supported *at this
> time*.
>
>
>
> We've discussed how it might be able to, and this was something the TAG
> suggested we consider for *future* work, but that's all it is, future work.
>
>
>
> If you want to unwrap "magic" keys, your AES-GCM key must be available to
> your implementation as decrypt, and you can implement the security boundary
> within your application. Since you're polyfilling the "magic" algorithm,
> which by definition means the key bytes of the "magic" key are available to
> you, this is no change in security properties - you've already decided
> where your security boundary is.
>
>
>
> Ryan,
>
>
>
> Either I misunderstood your previous position or it has changed.  This
> does not match what I thought you were saying previously.  This would have
> been during the discussions of boundaries of import and export of keys in
> previous messages where I was trying to argue for tight boundaries and I
> thought that you were not.  (I.e. the Netflix case of doing a chain import
> of a key that was not visible in any way to the script).
>
>
>
> Jim
>
>
>
>
>
> I'm not sure where you see the disconnect, Jim.
>
>
>
> The API does not support polyfilling in your own JS algorithms and
> treating them "as if" they were WebCrypto algorithms.
>
>
>
> You can polyfill by wrapping window.crypto.subtle and interposing your own
> object that intercepts or calls into the SubtleCrypto prototype, but that
> IS NOT complete, because it does not affect:
>
> - Algorithm Normalization
>
> - Operations that are composed (eg; We've previously discussed this in the
> context of RSA signing arbitrary hashes)
>
> - Wrap/Unwrap operations?
>
>
>
> Can you explain what you're confused by? I thought you understood the last
> time we discussed this, with respect to hashing algorithms.
>
>
>
> I understood this with respect to hashing algorithms, however I did not
> think that you understood this wrt wrap/unwrap and that was the disconnect
> that I was having.
>
>
>

Right.

To hopefully be clear, interposing JS-polyfilled implementations of
algorithms and having them be first-class next to native is *not* possible
with this API, and that's by design.

We've discussed this at a variety of F2F, including the first Mountain View
one, with the goal of exploring how an API might look. We've talked about a
notional idea of "CryptoWorkers", in a manner similar to Web Audio's
ScriptProcessorNode (
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#ScriptProcessorNode-
with a recognition of the attendant issues facing ScriptProcessorNode
-
eg: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

Given that the entire purpose of this API is in many ways a recognition of
the unsuitability of JS for general purpose crypto, if you feel there is
some missing algorithm requiring polyfill support, now would be a good to
speak up. Otherwise, I think we must simply take it as a recognition that
the API does not provide a *generic* polyfill extensibility point at this
time, while still providing *significant* value to developers AND permits
polyfill capability - provided that authors are careful to make use of
origin security boundaries.