Re: [WebCrypto Key Discovery] Algorithm names in named keys


The user obviously shouldn't choose the algorithm, because no 'normal' user knows what to choose. So it is either the implementer of the web crypto API or de app developer who needs to make the decision of the algorithm to use. Ideally the implementer should do this (he knows most about cryptography), but only the app developer knows what he is going to do with the result of the sign/verify/encrypt/decrypt operation and consequently the supported algorithm(s) for the usage. But then the implementer should provide access to all supported algorithms for the key, so he can choose the most secure one which is supported for the use case. Or am I missing something?


Nick van den Bleeken

On 01 Mar 2013, at 19:28, "Ryan Sleevi" <> wrote:

> On Fri, Mar 1, 2013 at 7:44 AM, Mark Watson <> wrote:
>> Hi Nick,
>> In WebCrypto, keys are associated with a very specific algorithm, such as
>> RSAES-PKCS1-v1_5. When you pre-provision named keys for a specific origin,
>> you should pre-provision their attributes - including this specific
>> algorithm - as well.
>> Now, since the pre-provisioning mechanism is out-of-scope of the
>> specification, you can implement this however you like. If you want to
>> expose multiple named keys that - under the covers - are derived from the
>> same secret keying material then you are free to do that (although I cannot
>> comment on the wisdom of that from a security perspective).
>> I think it is an open issue whether getKeysByName should be able to return
>> multiple values. At one point the idea was that you could specify wildcard
>> names. Without wildcards we'd imagined that getKeysByName should return a
>> single value. This could be another reason to return multiple.
>> ...Mark
> +1
> Using the same keying material with multiple algorithms should be a
> security non-goal, because it only leads to cryptographic pain.
> The provisioning of a NamedKey (out of spec) should also include
> provisioning the associated algorithm.


Inventive Designers' Email Disclaimer:

Received on Friday, 1 March 2013 21:23:03 UTC