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

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.

-----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 Tuesday, 14 August 2012 16:30:40 UTC