Re: verify method

On Jun 28, 2013, at 3:19 PM, Mark Watson <watsonm@netflix.com> wrote:

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

This is basically what I was going to say.  To put it slightly differently: Promises/futures are said to represent a future value.  In this case, the value is the boolean result of the validation.

In any case, if we follow the former pattern above (call the success handler when validation proceeds correctly, regardless of result), then a developer can polyfill the second one by moving execution from the success path to the failure path:

  function moveToFailurePath(valid) {
    if (valid) { return valid; }
    else { throw new InvalidSignatureError(); }
  }
  verify(things).then(moveToFailurePath).then( handleValidationSuccess, handleValidationError );

It's a little more complicated to go the other way:

  function passThrough(val) { return val; }
  function moveToSuccessPath(err) {
    if (err instance of InvalidSignatureError()) { return true; }
    else { throw err; }
  }
  verify(things).then(passThrough, moveToSuccessPath).then( handleValidationResult );

One other interesting perspective here is to look at older libraries.  It appears that OpenSSL and NSS do not expose the reason for a failure; they simply return failure for any failure, crypto or otherwise [1][2].  (In that case, you wouldn't be able to do the second polyfill above.)  CNG and BouncyCastle, on the other hand, provide differentiated responses [3][4].

Obviously, you could read that history to say that we should just revoke the promise on any failure, including validation failure.  I still lean the other way; that we should follow more modern design patterns than old C-inspired ones.  

--Richard


[1] <http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11obj.c#l663>
[2] <http://www.openssl.org/docs/crypto/RSA_sign.html>
[3] <http://msdn.microsoft.com/en-us/library/windows/desktop/aa375515(v=vs.85).aspx>
[4] <http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/signers/RSADigestSigner.html>



> 
> 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 Monday, 1 July 2013 14:58:19 UTC