- 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