RE: verify method

It might be more useful to return a false for signature validation as oppose
to the signature algorithm is not supported.  Part of this is the fact that
when something fails, there is no indication of what the failure is.  If the
false half of the then returns an error code this is no longer a problem.

Jim


> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Wednesday, June 26, 2013 1:44 PM
> To: Richard Barnes
> Cc: Jim Schaad; public-webcrypto@w3.org
> Subject: Re: verify method
> 
> Can you explain why you see it as marginally more useful?
> 
> ISTM that
> 
> validate(things).then(handleSuccess, handleError) is much more intuitive -
> that is, regardless of the error cause, errors are handled.
> 
> Otherwise, you run into situations like
> 
> validate(things).then(result => (result ? return handleSuccess() :
> return handleError()), handleError);
> 
> Especially if you want to have an error chain with error fastforwarding.
> 
> 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 )
> >
> > 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/Overv
> >> iew.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 Friday, 28 June 2013 03:11:44 UTC