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

RE: JS code examples for ACTION 43

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Fri, 7 Sep 2012 07:00:59 +0000
To: Ryan Sleevi <sleevi@google.com>, Wan-Teh Chang <wtc@google.com>
CC: David Dahl <ddahl@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
Message-ID: <382AD43736BB12439240773F68E90773AFCEAF@DF-M14-21.exchange.corp.microsoft.com>
> 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...

Not exactly the same, but the WinRT promises model tries to simplify these types of sequences for similar reasons: http://msdn.microsoft.com/library/windows/apps/hh710229.aspx


-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Wednesday, September 5, 2012 5:34 PM
To: Wan-Teh Chang
Cc: David Dahl; public-webcrypto@w3.org Working Group
Subject: Re: JS code examples for ACTION 43

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 Friday, 7 September 2012 07:01:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 07:01:53 GMT