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.html
> [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-formdata
> [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 Monday, 6 August 2012 18:48:42 UTC