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

Hi Mark,

I'm not completely sure with who you mean by the 'provisioner of the key'. Allow me to step back and explain our use case.

We have a web application which allows people to digitally sign documents using a smart card or USB security token.

Our customers don't want to use software keys because they could copied and consequently stolen without the end user's knowledge. In countries like Belgium, Germany, Italy,… you even don't need to provide a special smart card or USB security token to sign documents, because citizens already have an electronic identity card which they can use to sign documents.

So hopefully the browser vendors will support the WebCrypto Key Discovery API. In this case the browser user is the 'provisioner of the key' I guess and he doesn't know what algorithm and/or key he should use to sign the document.

When signing a document, the supported algorithms may vary depending on the document format. You can't use ECDSA in PDF for example [1].

Kind regards,

Nick Van den Bleeken

1: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf  : section 12.8.3.3 Table 257
On 04 Mar 2013, at 18:33, Mark Watson <watsonm@netflix.com> wrote:

>
> 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
>>
>
>
>


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

Received on Tuesday, 5 March 2013 11:53:10 UTC