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

Re: verify method

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 26 Jun 2013 12:20:31 -0700
Message-ID: <CACvaWvbG3oFwiaWjqYoD0smaXEhqdzQZbi70f20AH2+KkDMrdw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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?

> 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

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

> Jim
Received on Wednesday, 26 June 2013 19:20:58 UTC

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