This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25820 - Should empty key usages be allowed when creating keys?
Summary: Should empty key usages be allowed when creating keys?
Status: RESOLVED FIXED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-20 00:21 UTC by Eric Roman
Modified: 2014-09-26 23:35 UTC (History)
2 users (show)

See Also:


Attachments

Description Eric Roman 2014-05-20 00:21:44 UTC
A key with no usages can be created by either passing [] during importKey/unwrapKey/generateKey. Or by passing a non-empty key usages array to generateKey() for an asymmetric algorithm (since the usages are intersected with those allowed by the publickey/privatekey).

Does it make sense to have keys without usages, or should these be treated as errors and raise an exception?

A key without usages could still potentially be used with exportKey()/wrapKey(), but not much else.

Feel free to close this with working as intended, just want to verify the current behavior.
Comment 1 Ryan Sleevi 2014-05-20 00:32:49 UTC
I think the spec needs to be updated with how to handle this. This is also needed as part of the general effort of ensuring extensibility of the spec without monkey patching.

Proposal: Any key whose type is "private" or "secret", with no usages, results in a failure.

Examples:
unwrapKey() is called with a "foo" usage. The implementation does not support "foo" -> rejection
generateKey() is called with the "foo" usage for a public/private key pair. The "foo" usage is only valid for public keys (implying the private key has no valid usage) -> rejection
generateKey() is called with the "foo" usage for a symmetric key. The implementation does not support "foo" -> rejection


The only interesting point is whether or not it should be valid to have a public key of an asymmetric key pair that has no usages.

For example, what is expected of
generateKey({name: "RSA-OAEP", hash: { name: "SHA-1" } }, true, ["unwrap"]);

Success: - The private key can be used for unwrapping. You can export the public key to the peers that will perform wrapping (perhaps as a SPKI, which doesn't have any usages assigned)
Failure: - The public key has no usages.
Comment 2 Mark Watson 2014-05-20 00:56:55 UTC
(In reply to Ryan Sleevi from comment #1)
> I think the spec needs to be updated with how to handle this. This is also
> needed as part of the general effort of ensuring extensibility of the spec
> without monkey patching.
> 
> Proposal: Any key whose type is "private" or "secret", with no usages,
> results in a failure.
> 
> Examples:
> unwrapKey() is called with a "foo" usage. The implementation does not
> support "foo" -> rejection
> generateKey() is called with the "foo" usage for a public/private key pair.
> The "foo" usage is only valid for public keys (implying the private key has
> no valid usage) -> rejection
> generateKey() is called with the "foo" usage for a symmetric key. The
> implementation does not support "foo" -> rejection
> 
> 
> The only interesting point is whether or not it should be valid to have a
> public key of an asymmetric key pair that has no usages.
> 
> For example, what is expected of
> generateKey({name: "RSA-OAEP", hash: { name: "SHA-1" } }, true, ["unwrap"]);
> 
> Success: - The private key can be used for unwrapping. You can export the
> public key to the peers that will perform wrapping (perhaps as a SPKI, which
> doesn't have any usages assigned)
> Failure: - The public key has no usages.

I think this should succeed. What you describe is a completely valid use-case.

Constraining usages for extractable keys only makes sense as a 'defensive' strategy to catch programming defects: if the key can be extracted it can be re-imported with different usages. But if a key is not extractable and has no usages then there really is nothing which can be done with it.

Should all extractable keys be allowed to have no usages ? I guess you could just about apply the same defensive argument to a private key that was going to be used with some experimental algorithm provided in JS and explicitly isn't supposed to be used with WebCrypto methods. But this feels like a stretch.
Comment 3 Ryan Sleevi 2014-05-20 01:11:56 UTC
(In reply to Mark Watson from comment #2)
> I think this should succeed. What you describe is a completely valid
> use-case.

Agreed, but I guess it wasn't clear that I was arguing it's the *only* valid use case, and that other examples are intrinsically bad/wrong

generateKey({name: "RSA-OAEP", hash: { name: "SHA-1" } }, true, ["wrap"]);

Creates a wrapping key that *nothing* can unwrap with (short of exporting the key)

My view: This should be a FAILURE

generateKey({name: "AES-CBC"}, true, []);

Creates an unusable key.

My view: This should be a FAILURE.

> 
> Constraining usages for extractable keys only makes sense as a 'defensive'
> strategy to catch programming defects: if the key can be extracted it can be
> re-imported with different usages. But if a key is not extractable and has
> no usages then there really is nothing which can be done with it.
> 
> Should all extractable keys be allowed to have no usages ? I guess you could
> just about apply the same defensive argument to a private key that was going
> to be used with some experimental algorithm provided in JS and explicitly
> isn't supposed to be used with WebCrypto methods. But this feels like a
> stretch.

Let me try to restate my view:

If an operation results in the production of a Key object whose type is either "secret" or "private", and which has no "usages" (after intersecting with the usages valid for the algorithm and those supplied by the caller and JWK) should be a FAILURE.

Regardless of the 'extractable' flag.

This is almost certainly going to occur not due to programmer error, but due to "feature detection", and that should fail as quickly as possible; that is, prior to generating any key material.
Comment 4 Mark Watson 2014-05-20 01:23:02 UTC
Yes, I understood. Just saying we should compare your use-case (fast failure for unsupported usages) with the only use-case I can think of for a key with no usages, which is where the app wants to use the UA's key generation capability alone and will extract the key and use it with an algorithm in pure JS.

As I said, that seems a stretch, whereas your use case does not, so I think your one wins here.
Comment 5 Mark Watson 2014-09-26 18:00:24 UTC
Unless there are further comments I will implement Ryan's proposal from comment 3.
Comment 6 Mark Watson 2014-09-26 18:23:48 UTC
https://dvcs.w3.org/hg/webcrypto-api/rev/c69386c630c6

[Leaving bug open in case there are comments]