Re: Proposed text for import/export

Thanks Mark

I think step 6 needs more text to explain exactly what "inconsistent"
means. In the context of JWK import:
  * The usages specified to importKey() must be a subset of the usages
encoded by keyData
  * If the keyData says it is not extractable, extractable provided to
importKey() must be false
  * If "algorithm" was provided, it must be "consistent" with that implied
by keyData (and what this means).

As far as defining what algorithms are consistent, as well as what to
reflect back in Key.algorithm, I think we can extend the registration table
that lists Operation x Parameters x Result to include a new row for
importKey().

Many algorithms will expect None for the algorithm parameters to importKey,
however for example those which specify an inner hash will need more
parameters. Sample rows:

AES-CBC, importKey, None
AES-GCM, importKey, None
HMAC, importKey, HmacParams
RSASSA-PKCS1-v1_5, importKey, RsaSsaParams

(I don't think we would want implementations to be able to import a key for
simply "HMAC" without specifying what the inner hash was)

The above mapping would serve as a reference of what to expect in the input
algorithm, as well as what needs to be reflected back to Key.algorithm, as
well as a reminder of how to consider if two Key.algorithms are consistent.

Lastly, regarding what to do about Key.usages, I am of the opinion that we
should reflect only those usages which make sense to the algorithm, and are
understood by the implementation (no real evidence on why, just a
cleanliness issue).

Giving an error for unsupported usages would mean there is no way now to
easily say "give me all usages". Currently you can do this by defining a
single constant that lists all usages and using this for all key type.
Although this is mainly a consequence of
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19705. If the default value
of usages meant "all possible relevant usages" that would be fine too.

Cheers


On Thu, Dec 19, 2013 at 2:57 PM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> For those who didn't add themselves the bug I filed and resolved
> this-afternoon (that would be all of you), I have proposed some text for
> import / export in the Editor's Draft. This includes the text proposed by
> Ryan under ACTION-115.
>
> I believe there may remain various details associated with key formats
> other than "raw" that will need to be specified. Also, there is still
> discussion ongoing in JOSE about the "use" attribute. Although noone has
> suggested that we should not be allowed to register the values now in our
> specification, they may recommend we make changes to our registration.
>
> We must also answer questions about what happens if you try to import a
> key with a usage which is not supported by the key algorithm. Is that an
> error, or is that usage simply omitted from the usages which make it into
> the key.usages attribute ?
>
> ...Mark
>