Re: Testing progress

Comments below.

On Mon, May 2, 2016 at 3:05 PM, Eric Roman <ericroman@google.com> wrote:
>
>
>> >> - Can't automate testing of PBKDF2 because it requires user input
>> >> outside control of the browser.
>
>
> RE: generateKey() for PBKDF2:
>
> Aside from the problem with automation, there is a bigger issue -- does any
> User Agent actually implement generateKey() for PBKF2?
>
> Chrome certainly doesn't.
> And as far as I can tell neither does Firefox
> (I can only speak authoritatively for Chromium's implementation).
>
> I raised my concerns with PBKDF2's specification in this bug:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27689
>
> I don't believe as specified generateKey() is implementable -- or at the
> very least would lead to a *good* implementation.
>
> I am happy to re-visit Chrome's implementation if we generate more
> discussion around this issue.
>
> Barring that if no UA implements it and the WG isn't able to respond to
> feedback on it, I say we remove it from the spec.

+1 I agree. I know from my informal checks in the past, I was unable
to find any browser implementing it, and I don't think it's needed.

> What property names are missing?

OperationError doesn't have a "legacy" named property defined, so you
have to test the exception's name for that string. Which is what the
test is doing now. But I think I found a place where the name value
was different. That might not be due to not supporting OperationError,
but just due to throwing the wrong exception.

> Other things to be testing for generateKey() for RSA:
>
>   * Supported key size
>   * Supported public exponent.
>
> We will see differences here -- Chrome has a minimum and maximum allowed key
> size for RSA, and also restricts the public exponent to being 3 or 65537
> (more details at https://www.chromium.org/blink/webcrypto).

Unlike for AES or EC, the specification doesn't say what values are
legal for RSA keys, so what would be used to test proper rejection of
those values?

> Side comment: not sure if we would want this under the conformance test
> suite, or leave it to implementation testing.. but when testing our own
> implementation we had an early bug where generated keys were unextractable
> (exportKey() would fail on them even when marked extractable). To catch
> these sorts of problems you would ideally run all the operation tests on
> each successfully generated key, and verify that all key usages are
> respected, and that operations work as expected on the key.

At least for this test, I tried to avoid testing any other operations.
If the result is of type CryptoKey, I accept that it's a good
CryptoKey. If it says it's extractable or can be used for signing, I
take it at its word. I agree it could be useful to have tests
verifying such claims.

Charlie

Received on Monday, 2 May 2016 19:23:28 UTC