Re: verify method

On Wed, Jun 26, 2013 at 1:26 PM, Richard Barnes <rbarnes@bbn.com> wrote:

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

+1

If a signature fails to validate then this is not an "error" any more than
isEven( 3 ) is an error.

Generically, the handling of actual error cases is very different from the
handling of an invalid signature.

...Mark


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