W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2016

Re: Clarification Requested

From: Eric Roman <ericroman@google.com>
Date: Tue, 26 Apr 2016 18:51:00 -0700
Message-ID: <CAFswn4=dzvow7O1UcYA7qgFT19KLcGUapqiuQjNkdYyz_s6WjQ@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Looks like this changed after
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24963 -- before then the jwk
input to importKey were explicit bytes rather than a dictionary, so that
wording made sense as step (1) explicitly involved parsing:

    Let jwk be the result of running the "parse a JWK" algorithm over

Following that change, I agree, the current wording ceased to be meaningful.

The preceding step (1) which "converts" to JsonWebKey *can* technically
fail if read in isolation. However there is a catch-all in section
that would prevent this:

    If the keyData parameter passed to the importKey method is not a
JsonWebKey dictionary, throw a TypeError.

So I would expect to get a TypeError in all such cases, and never hit the
DataError described in step (2).

While reviewing this, the language for JWK + unwrapKey() also suffers from
similar ambiguity.

In the unwrapKey() path the spec describes inflating UTF8-encoded bytes to
a dictionary (via JSON.parse()), and then implicitly converting that to a
JsonWebKey. There is no description of what to do if it is not a valid
JsonWebKey -- my assumption here is that "conversion" can fail when there
are type mismatches. Also in the unwrapKey "parse a jwk" thing, there are
implicitly the errors that JSON.parse() can throw (ie. SyntaxError), which
is perhaps not all that clear.

Personally I think it was clearer both in the spec and for consumers when
the 'jwk' format produced and consumed bytes rather than objects. From an
implementation standpoint I am still not sure what is really meant when
reading the JWK dictionary during importKey, since reading values from a
javascript object is not idempotent, and is sensitive to order, number of
times accessed, timings, etc in contrived edge cases.

On Mon, Apr 25, 2016 at 9:30 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> Looking at the import procedure for ECDH with format of "jwk", the first
> two lines are:
> 1. Let jwk be the JsonWebKey dictionary represented by keyData.
> 2. If an error occurred while parsing, then throw a DataError.
> It is not clear to me that the text here is clear.  Specifically, I don't
> see step #1 as being a parsing step so saying that an error occurring
> during parsing in step #2 seems odd.  From a testing point of view, I am
> not sure just what the error that is occurring in step #2 is supposed to
> be.  Are we saying that if there is an element which is not part of the
> JsonWebKey dictionary?  Is this left over from a point of time where we
> passed in a string rather than an object and the string was being parsed?
> Any clarifications would be helpful.
> Jim
Received on Wednesday, 27 April 2016 01:51:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 April 2016 01:51:31 UTC