Re: Proposed text for import/export

On Thu, Dec 19, 2013 at 4:12 PM, Eric Roman <ericroman@google.com> wrote:

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

It might also be convenient to be able to leave "usages" unspecified for
importKey() / unwrapKey(). Currently when importing JWK keys you need to
duplicate knowledge of what operations the key supports when importing it.
You cannot import the JWK and then inspect what operations it allows.
Rather you must import it already knowing exactly what it encodes.

This could come up if you were fetching a JWK from a remote server. You
would need to additionally be told what usages it has in order to unpack
it. Not likely to be a big obstacle in practice (most users will know how
they want to use the key), but it is a limitation of the importKey()
semantics for JWK nonetheless.


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