Re: [W3C Web Crypto WG] PROPOSAL to close ISSUE-22 (Should CryptoOperations be clonable)

Le 04/04/2013 16:12, Mark Watson a écrit :
> Unless I am missing something, if multi-part operations are permitted
Not clear about this, what is a multi-part operation exactly (example?)
> , then in the complete step the variable copy contains only the data 
> since the last process. I don't see where you reset the state of the 
> operation to the same point.
>
I am assuming that the operation can restart from the last known pending 
data + result (wrong?)
> Anyway, this seems like a premature optimization. It complicates the 
> API and procedures for a minor use-case which could be achieved 
> (marginally less optimally) by keeping multiple CryptoOperation 
> objects, one for each prefix of the input data for which a digest is 
> required.
I am not sure it's so minor or will be minor in the future, without it I 
can not do [1] and probably SSL/TLS implementation with the API, the 
solution of having multiple CryptoOperations is impossible in terms of 
performances

[1] https://www.github.com/Ayms/node-Tor
>
> ...Mark
>
> Sent from my iPhone
>
> On Apr 4, 2013, at 5:18 AM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>> If ISSUE-22 is closed, then it becomes impossible to do correctly 
>> progressive hash/encryption with the WebCrypto API.
>>
>> This might be destroyed right away but please see below a proposal, 
>> it is not really a clone but a continuation of the operation resuming 
>> from the previous state (which as a non crypto expert maybe I am 
>> simplifying too much), see the example at the end, at least that's an 
>> attempt...
>>
>> This is based on the assumption than independently of which progress 
>> could be fired following some process invocations at the same time 
>> you call finish, you are only interested by the final result.
>>
>>
>> |interfaceCryptoOperation  : EventTarget {
>>    voidprocess  <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-process>(ArrayBufferView buffer);
>>    voidfinish  <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-finish>(boolean? resume);
>>    voidabort  <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-abort>();
>>
>>    readonly attributeKey  <http://www.w3.org/TR/WebCryptoAPI/#dfn-Key>?key  <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-key>;
>>    readonly attributeAlgorithm  <http://www.w3.org/TR/WebCryptoAPI/#dfn-Algorithm>  algorithm  <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>;
>>    readonly attribute anyresult  <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-result>;
>> ||   readonly attribute any?resume  <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-result>;|
>> |   readonly attribute any? final;|
>>   
>>
>>
>>         12.4.2. The|finish(boolean? resume)|method
>>
>> When|finish(boolean? resume)| 
>> <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-method-finish>method 
>> is called, the user agent must run the steps below.
>>
>> 1.
>>
>>     If the internal state is in the|"error"|state, throw
>>     an|InvalidStateError|exception and abort these steps.
>>
>> 2.
>>
>>     Set the internal state to|"complete"|. If resume is true let copy
>>     be a copy of the list of pending data and set the resume
>>     attribute to result
>>
>> 3.
>>
>>     If the underlying cryptographic implementation for the
>>     specifiedalgorithm
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>does
>>     not support multi-part cryptographic operations,
>>     asynchronouslyprocess data
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-process-data>,
>>     allowing the task that invoked this algorithm to continue.
>>
>> 4.
>>
>>     Once all items in thelist of pending data
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-list-of-pending-data>have
>>     beenprocessed
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-process-data>,if
>>     resume is true, restore the list of pending data with copy and
>>     set final to result, queue a task
>>     <http://www.w3.org/TR/WebCryptoAPI/#queue-a-task>tofire a simple
>>     event
>>     <http://www.w3.org/TR/WebCryptoAPI/#fire-a-simple-event>called|oncomplete|
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-oncomplete>at
>>     the|CryptoOperation|
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation>.
>>
>>
>>         12.4.1.|process(ArrayBufferView data)|
>>
>> When the|process(ArrayBufferView data)|method is called, the user 
>> agent must run the following steps:
>>
>> 1.
>>
>>     If the internal state is in the|"error"|state, throw
>>     an|InvalidStateError|exception and abort these steps.
>>
>> 2.
>>
>>     Letdatabe the data to be processed.
>>
>> 3.
>>
>>     Adddatato thelist of pending data
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-list-of-pending-data>.
>>
>>  4. If the resume attribute is not undefined, update result with resume
>> 5.
>>
>>     If the underlying cryptographic implementation for the
>>     specifiedalgorithm
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-algorithm>supports
>>     multi-part cryptographic operations, asynchrouslyprocess data
>>     <http://www.w3.org/TR/WebCryptoAPI/#dfn-CryptoOperation-process-data>,
>>     allowing the task that invoked this algorithm to continue.
>>
>> Example :
>>
>> The algorithm processes 3 bytes :
>>
>> process(ABCD) {result=abc, pending=D}
>> finish(true) {result=abcd,final=abcd,resume=abc,pending=D}
>> process(EFGH)
>>     step 4 {result=abc,final=abcd,resume=abc,pending=D}
>>     step 5 {result=abcdefg,final=abcd,resume=abc,pending=H}
>> finish(true) {result=abcdefgh,final=abcdefgh,resume=abcdefg,pending=H}
>>
>> The reason to use final attribute is that process does modify result 
>> and then progress could fire before complete and then the result in 
>> complete would not be the good one.
>>
>>
>> Le 04/04/2013 11:46, GALINDO Virginie a écrit :
>>>
>>> Dear all,
>>>
>>> I suggest that we close the ISSUE-22 
>>> http://www.w3.org/2012/webcrypto/track/issues/22 , with the 
>>> rationale that the WG did not make any progress /contribution on 
>>> cloning. As such I interpret it as no interest or need to have that 
>>> feature covered by our Web Crypto API.
>>>
>>> This proposal will be submitted to the vote during our next call on 
>>> the 15^th of April.
>>>
>>> Regards,
>>>
>>> Virginie
>>>
>>
>> -- 
>> jCore
>> Email :avitte@jcore.fr
>> iAnonym :http://www.ianonym.com
>> node-Tor :https://www.github.com/Ayms/node-Tor
>> GitHub :https://www.github.com/Ayms
>> Web :www.jcore.fr
>> Webble :www.webble.it
>> Extract Widget Mobile :www.extractwidget.com
>> BlimpMe! :www.blimpme.com

-- 
jCore
Email :  avitte@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

Received on Thursday, 4 April 2013 16:21:36 UTC