W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2013

Re: verify method

From: Richard Barnes <rbarnes@bbn.com>
Date: Wed, 26 Jun 2013 16:26:54 -0400
Cc: Jim Schaad <ietf@augustcellars.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-Id: <48DCAD78-AFC7-4088-AD2E-5466A5E3C916@bbn.com>
To: Ryan Sleevi <sleevi@google.com>

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.


>> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:17 UTC