- From: <bugzilla@jessica.w3.org>
- Date: Tue, 20 May 2014 00:56:55 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25820 Mark Watson <watsonm@netflix.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |watsonm@netflix.com --- Comment #2 from Mark Watson <watsonm@netflix.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 20 May 2014 00:56:56 UTC