W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

Re: JS code examples for ACTION 43

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 5 Sep 2012 17:33:48 -0700
Message-ID: <CACvaWvaQ2rTJsqaEZb+fDtJRzVjJpHW_Sh_80q9NVf=Swv8mgw@mail.gmail.com>
To: Wan-Teh Chang <wtc@google.com>
Cc: David Dahl <ddahl@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
On Wed, Sep 5, 2012 at 5:22 PM, Wan-Teh Chang <wtc@google.com> wrote:
> David, Arun,
>
> Thank you for writing the sample code.
>
> Some of the mistakes in your sample code are caused by incomplete
> specification of the current API draft. Some mistakes indicate areas
> for improvement. I noted some mistakes below. (I didn't correct all
> mistakes I found.)
>
> 1. In the algorithm object for RSA key pair generation:
>
> // Algorithm Object
> var algorithm = {
>   name: "RSAES-PKCS1-v1_5",
>   // AlgorithmParams
>   params: {
>     modulusLength: 2048,
>     publicExponent: 65537
>   }
> };
>
> The value of publicExponent needs to be a Uint8Array. So 65537 needs
> to be represented as an array of three Uint8 elements: 0x01, 0x00,
> 0x01.
>
> 2. In the onKeyGenComplete function, we have:
>
>   console.log("Key ID: " + event.target.key.id);
>
> This requires adding a |key| attribute to the KeyOperation interface
> in Section 13 "KeyOperation interface". But it seems that the |key|
> should be the |result| of the KeyOperation object for key generation.
> So perhaps this line should read:
>   console.log("Key ID: " + event.target.result.id);
>
> 3. Call sequences like the following don't work because the methods
> are all asynchronous:
>
>       pubKeyCryptoOp.init();
>       pubKeyCryptoOp.processData(secretMessageToAlice);
>       pubKeyCryptoOp.complete();

Right, this is probably a spec bug, at least with regards to how I was
thinking about it.

You are correct that the spec, in discussing the internal state of the
object, requires that the state transition be complete before calling
the next method (Step 1 of init/processData/complete). That is, in
order for processData() to not fail, the "state" must be "processing"
[1], which is only set AFTER init() has asynchronously completed.

Maybe I'm wrong in thinking it, but it seems like David's example
would be the 'preferable' way to do it - for 'simple' operations, you
can simply chain the calls without waiting for the results, and just
check for onComplete/onError. It's only the complicated sequences that
need to call processData() within the callbacks.

That said, it seems like it would require tracking an individual
object task queue, and having the asynchronous completion post the
next task automatically after the firing of event handlers. I don't
know of any APIs that presently behave that way though...

[1] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-CryptoOperation-state-processing

>
> 4. Please see the attached patch file for additional fixes. If you
> have questions about any change in the patch file, please let me know.
>
> Wan-Teh
Received on Thursday, 6 September 2012 00:34:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 00:34:16 GMT