Re: verify method

On Jun 26, 2013, at 3:20 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Sun, Jun 23, 2013 at 11:23 AM, Jim Schaad <ietf@augustcellars.com> wrote:
>> Ryan,
>> 
>> It is not clear to me if a verify operation where the finish operation fails
>> because the signature values do not match, if the promise fails or succeeds
>> and returns a fail result.
> 
> Reasonable question.
> 
> There are two options here. This would also apply to authenticated
> encryption modes
> 
> 1) Resolve the promise with a failure result (eg: an empty
> ArrayBuffer, a boolean false)
> 2) Reject the promise, with some sort of indicative error code
> 
> It seems more useful to authors to reject the promise, as that allows
> for an easier .then() flow. This would then argue for some sort of
> distinguishing error code, to distinguish between a promise being
> rejected for other reasons (unsupported alg? invalid params?) versus
> being rejected because a signature/mac/tag didn't validate.
> 
> Thoughts from the WG?

It seems marginally more useful to me to resolve if the validation proceeds correctly, returning a boolean with the result of the validation.  There are effectively two returned values here:
1. Reject / resolve
2. Value returned on resolution

ISTM that it would make sense to make those values equivalent to:
1. Whether validation proceeded correctly (reject if not)
2. Whether validation was successful

That separates cryptographic errors from mechanical errors.  It seems marginally nicer to program with:
  validate(things).then( handleValidationResult )
As opposed to:
  validate(things).then( handleValidationSuccess, handleValidationFailure )

But I don't feel very strongly one way or the other.

--Richard




> 
>> 
>> Also, it might be good to document what the value returned is for each
>> operation to tell me what the expected prototype is for the fulfill and
>> reject callbacks are.
> 
> Agreed - this is what the algorithm sections already try to do in
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/0956666e55e0/spec/Overview.html#algorithms
> 
> Do you see a place where this is missing or under-specified?
> 
> In some ways, the result is contingent upon the operation. eg: the
> discussion of AES-GCM, where both a tag and ciphertext are returned by
> encrypt.
> 
>> 
>> Jim
>> 
>> 
>

Received on Wednesday, 26 June 2013 20:27:29 UTC