Re: Streaming - [Re: CryptoOperation and its life cycle]

On Dec 17, 2012 1:30 AM, "Aymeric Vitte" <vitteaymeric@gmail.com> wrote:
>
> Let's recap :
>
> - algorithm that does not support intermediate results : Issue-22, OK
> - algorithm that supports intermediate results : progress
>
> But for the second case it's still not possible to correlate the progress
output with a given request.
>
> Is this not an issue and was it never requested/discussed before ? ( I
gave an example of real use case)

Not an issue, was discussed.

Again, there is no requirement that a UA support multi part operations at
the implementation level. A conforming UA MAY decide to perform zero
cryptographic operations until finish() is called. A conforming MAY choose
to coalesce buffers from .process() into optimal sized buffers for the
underlying implementation, and then emit a single progress event with the
output. A conforming UA MAY choose to schedule tasks to process each buffer
from .process() independently, firing notifications *if* data was output.
The spec is written **intentionally** to allow all of these patterns to be
permissible because they reflect patterns used by a variety of low-level
implementations expected to be used by UAs - libraries like OpenSSL, NSS,
CDSA, SecTransforms, CryptoAPI, and CNG. There is no one universal form in
them - short of making EVERYTHING a single-part one shot op.

You have not provided a use case where it is necessary to map 1:1 the
inputs and outputs, *except* when being considered with respect to
ISSUE-22. Which is exactly what is thorny about ISSUE-22.

Can you share a use case that is not inextricably linked to cloning
cryptographic state?

>
>
> Le 16/12/2012 20:40, Ryan Sleevi a écrit :
>
>> Just so it's clear,
>>
>> Everything you so far have expressed a desire for is summed up in
ISSUE-22.
>
>
> --
> jCore
> Email :  avitte@jcore.fr
> 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 Monday, 17 December 2012 09:57:02 UTC