Re: crypto-ISSUE-18: Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics? [Web Cryptography API]

On Tue, Aug 14, 2012 at 9:29 AM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
> Agree on postponing this until after FPWD.
>
> To be clear, I believe the only problem we have is whether to support operations where the sink is a stream. The APIs as they exist now support source-as-stream semantics simply by virtue of the processData method. So the problem is limited to various symmetric cipher modes.

Now that we're getting FPWD out...

I think we will want to support cases where either source or sink is
stream - not just sink.

A possible stream source would be the result of an XMLHttpRequest
Level 2 call (where .responseType == blob).

A possible stream sink would be, again, XMLHttpRequest Level 2, having
it send() using a Blob

This has the potential to be much more efficient, from the perspective
of implementers, since it allows them to lazily evaluate the crypto -
and perhaps without requiring the execution of any client JS code once
the respective sources and sinks were glued.

For example, when sending with a 'streaming' type API (whether
Blob-as-pseudo-stream or an explicit Stream-type class), if all of the
crypto was U-A supplied (that is, not polyfilled), it could delay
encrypting/decrypting until, say, the XHR had actually connected to
the peer and negotiated SSL (if doing an HTTPS post).

With Microsoft's Streams API proposal (which is one such way of
addressing it), you could glue the Blob to a CryptoOperation as a
sink->source relationship, then glue the CryptoOperation to an XHR as
a source->sink. This could fully avoid having to execute any client
JS, and allow the "read data from blob" operations to not occur until
the XHR was ready for more data (eg: network IO was unblocked). The
alternative in today's API would have the client JS calling the Blob
read operations, only to then immediately .processData, which means
that the XHR would have to be internally buffering all of this when
blocked on network IO.

As mentioned previously, the downside with directly using Blob to do
this is that, intrinsicly, Blob's have sizes and types. For
cryptographic operations, the size may not be known a-priori (I'm
thinking of padding situations in general). Maybe it's not really a
concern in practice - I admit, I'm hand-wavey here on this aspect, but
that's why I favor a Blob + (some other type), usable as a Source or a
Sink.

>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Monday, August 6, 2012 11:48 AM
> To: Web Cryptography Working Group
> Cc: Arun Ranganathan
> Subject: Re: crypto-ISSUE-18: Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics? [Web Cryptography API]
>
> On Mon, Aug 6, 2012 at 11:20 AM, Web Cryptography Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
>> crypto-ISSUE-18: Should it be possible to perform CryptoOperations as
>> a 'streaming' operation with URI semantics? [Web Cryptography API]
>>
>> http://www.w3.org/2012/webcrypto/track/issues/18
>>
>> Raised by: Ryan Sleevi
>> On product: Web Cryptography API
>>
>> The File API [1] defines an extension to the URL API [2] that exposes methods URL.createObjectURL [3] and URL.revokeObjectURL [4].
>>
>> These define a 'special' URL syntax that allows user agents to directly interpret the data represented within a Blob, for use with existing schemes that take a URL (for example, img.src or script.src).
>>
>> The MediaStreams API [5] further extends URL.createObjectURL [6] to allow MediaStream objects to be passed to to createObjectURL. MediaStreams are not Blob types themselves, and may be of indeterminate length (unlike Blobs), but by exposing them as pseudo-URLs, they can be used with existing tags such as <audio> or <video>.
>>
>> Similarly, proposed APIs for streaming exist as part of the Stream Processing Spec [7] and through the Streams API [8]. Notably, the Streams API proposes a generic extension for createObjectURL that allows creating a blob URI from Stream objects.
>>
>> The question is whether or not the Web Cryptography API should also extend createObjectURL to allow the creation of a Blob URI from a CryptoOperation.
>>
>> Possible semantics:
>> - For an decryption operation, the returned stream references the plaintext data
>>   - TBD: What to do for authenticated encryption data
>> - For an encryption operation, the returned stream references the encrypted data
>>   - TBD: What to do for authenticated encryption data
>> - For a verify operation, the returned stream will contain the verified (signed) data.
>>
>> Possible downsides:
>> - Unlike MediaStream/Blob, for which the data source is inside the user agent itself, the CryptoOperation is dependent upon the user manually adding more data to be processed, via processData(). This is similar to the StreamBuilder API from [8]. Does createObjectURL make sense for this use case?
>> - It's not possible to specify a streaming /source/ of data
>>
>> Possible enhancements:
>> - Should FormData [10] or XMLHttpRequest.send [11] be updated to take CryptoOperation/streams?
>>
>> [1] http://www.w3.org/TR/FileAPI/
>> [2] http://www.w3.org/TR/url/
>> [3] http://www.w3.org/TR/FileAPI/#dfn-createObjectURL
>> [4] http://www.w3.org/TR/FileAPI/#dfn-revokeObjectURL
>> [5] http://www.w3.org/TR/mediacapture-streams/
>> [6] http://www.w3.org/TR/mediacapture-streams/#url
>> [7]
>> https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.htm
>> l [8] http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
>> [9]
>> http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#error-uris
>> _for_streams [10]
>> http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#interface-formda
>> ta [11]
>> http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#the-send-method
>>
>>
>>
>
> Note: I'd like to propose that we don't discuss this in depth until after FPWD, to make sure that the higher priority issues are dealt with first.
>
>
> This is in part a response to Wan-Teh Chang's comments on 20 Jun - http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0131.html
> - and re-iterated at the Face-to-Face. It also mirrors existing concerns that have been raised with the File API needing to keep the entire result in memory.
>
> I don't believe it appropriate to resolve in the FPWD, and some of the cited specs have not been touched for up to a year. However, it's clear from discussions in other WGs that the question of streaming data is an ongoing one, so I've raised this issue to track discussion and the WG's sentiment towards applicability.
>
> Because the concept of "cryptography as streams" may be novel for some, example APIs that implement these semantics include Apple's "Security Transforms" API [1], Crypto++'s Pipelining API [2], and OpenSSL's BIO API [3].
>
> For any given operation, there is at least 1 source (generates data),
> 1 sink (receives data), and 1 transformation. Some transformations may support multiple sinks or sources. An example of multiple sinks would be authenticated decryption outputting both ciphertext and authenticated data, or the inverse operation, which might have multiple sources.
>
> Further, transformations can be chained together efficiently, such as encrypt-and-sign sequences. They also lead themselves to (internal to the implementation) parallelization and asynchronicity.
>
> Since the existing web model treats "the network" as a stream source, the existing processing model is designed around streaming data. This includes ProgressEvents [4] or the XMLHttpRequest readyState [5].
> Thus, exposing cryptographic transforms as streams allows them to be easily plugged into existing network-friendly APIs.
>
> [1] https://developer.apple.com/library/mac/#documentation/Security/Conceptual/SecTransformPG/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010801-CH1-SW1
> [2] http://www.cryptopp.com/wiki/Pipelining
> [3] http://www.openssl.org/docs/crypto/bio.html
> [4] http://www.w3.org/TR/progress-events/
> [5] http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-readystate
>
>

Received on Wednesday, 12 September 2012 20:50:44 UTC