- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 4 Mar 2013 17:33:22 +0000
- To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
- CC: Ryan Sleevi <sleevi@google.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mar 1, 2013, at 1:22 PM, Nick Van den Bleeken wrote: > Hi, > > 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. No, it's the provisioner of the key. The specific algorithm is provisioned along with the key. At least this is how it looks on to the user of the API - what the implementor does under the covers is up to them: they could decide to have one master key from which many different keys for different algorithms are derived, for example. …Mark > 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? > > Regards, > > Nick van den Bleeken > > > On 01 Mar 2013, at 19:28, "Ryan Sleevi" <sleevi@google.com> wrote: > >> On Fri, Mar 1, 2013 at 7:44 AM, Mark Watson <watsonm@netflix.com> 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: > http://www.inventivedesigners.com/email-disclaimer >
Received on Monday, 4 March 2013 17:33:51 UTC