This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
(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.
(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.
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.
Unless there are further comments I will implement Ryan's proposal from comment 3.
https://dvcs.w3.org/hg/webcrypto-api/rev/c69386c630c6 [Leaving bug open in case there are comments]