Allow key_ops to be an empty list for JWK export

RESOLVED FIXED in Firefox 47

Status

()

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: mt, Assigned: mt)

Tracking

unspecified
mozilla47
Points:
---

Firefox Tracking Flags

(firefox47 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
Chrome does this.  Firefox removes the parameter if the list is empty.


The following succeeds in Firefox, even though the generated public key doesn't have any usages (I actually think that the public key should automatically be usable for verifying things, but it's a poor API, what can I say...)
 
crypto.subtle.generateKey({name: 'ECDSA', namedCurve: 'P-256' }, false, ['sign'])
  .then(pair => crypto.subtle.exportKey('jwk', pair.publicKey))
  .then(jwk => crypto.subtle.importKey('jwk', jwk, {name: 'ECDSA', namedCurve: 'P-256'}, false, ['verify']))
  .then(k => console.log(k), e => console.log(e))

Arguably, this is fine, but this isn't:

crypto.subtle.generateKey({name: 'ECDSA', namedCurve: 'P-256' }, false, ['sign'])
  .then(pair => crypto.subtle.exportKey('jwk', pair.publicKey))
  .then(jwk => crypto.subtle.importKey('jwk', jwk, {name: 'ECDH', namedCurve: 'P-256'}, false, ['deriveBits']))
  .then(k => console.log(k), e => console.log(e))

Notice the change in usage and type.

The fix is easy.
(Assignee)

Comment 1

3 years ago
Created attachment 8710888 [details]
MozReview Request: Bug 1241757 - Permit export of JWK with empty key_ops field, r?rbarnes

Review commit: https://reviewboard.mozilla.org/r/31901/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/31901/
Attachment #8710888 - Flags: review?(rlb)
(Assignee)

Comment 2

3 years ago
OK, I just discovered that EC JWKs don't include "alg".  That's a fine distinction that the tests manage not to validate.  I'll add another test for that.
(Assignee)

Updated

3 years ago
Assignee: nobody → martin.thomson
I'll hold off on the review until you add the other test.

But in the mean time: What are you after here?  I can see how it would be useful to prevent "cross-contamination" from ECDSA to ECDH as you suggest above, but that doesn't have anything to do with empty key usages.

What's your use case for keys that have no usages?  I would have thought that would be an illegal condition (or at least undesirable).  The spec explicitly forbids it for symmetric keys and private keys on GenerateKey.
(Assignee)

Comment 4

3 years ago
The test is included, the order of me pressing buttios was off, sorry.

The cross contamination thing is what I'm concerned about as an actual "security" issue.

The rest is just down to basic interoperability.  I think that in this corner case, Chrome is ever-so-slightly better.

Keys shouldn't have no usages, but you'd have to get the spec changed if you wanted to fix that because generateKey(..., ['sign']) creates a public key with no usages.  If you would rather change the spec, I'm happy with that.  I think that I'd still like to see this change until that happened though.
Comment on attachment 8710888 [details]
MozReview Request: Bug 1241757 - Permit export of JWK with empty key_ops field, r?rbarnes

https://reviewboard.mozilla.org/r/31901/#review31105

It might be good to fix the spec, but I can live with it for now.
Attachment #8710888 - Flags: review?(rlb) → review+

Comment 7

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/b9799dc98199
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox47: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in before you can comment on or make changes to this bug.