Re: Consider whether the others Public Value input to (EC)DH deriveKey should be a Key object

In case it wasn't clear, +1 from me if we can make it work.
On Feb 28, 2014 8:03 AM, "Mark Watson" <watsonm@netflix.com> wrote:

> Two plus votes - any other opinions ?
>
> ...Mark
>
>
> On Thu, Feb 27, 2014 at 12:59 PM, Vijay Bharadwaj <
> Vijay.Bharadwaj@microsoft.com> wrote:
>
>> Agreed. I too think it's cleaner to always use Key objects.
>>
>> -----Original Message-----
>> From: Jim Schaad [mailto:ietf@augustcellars.com]
>> Sent: Thursday, February 27, 2014 12:54 PM
>> To: 'Mark Watson'; public-webcrypto@w3.org
>> Subject: RE: Consider whether the others Public Value input to (EC)DH
>> deriveKey should be a Key object
>>
>>
>>
>> From: Mark Watson [mailto:watsonm@netflix.com]
>> Sent: Wednesday, February 26, 2014 3:01 PM
>> To: public-webcrypto@w3.org
>> Subject: Consider whether the others Public Value input to (EC)DH
>> deriveKey should be a Key object
>>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24830
>>
>> Presently, if the other's public value for the two DH algorithms is
>> received in spki format, then it is necessary first to import this
>> structure to obtain a Key object and then to export that in raw format to
>> obtain an ArrayBuffer containing the Public Value. This may then be used
>> with deriveKey.
>>
>> If this is the more common use-case it would make sense to change the
>> type of the public property of (Ec)DhDeriveParams to have type Key.
>>
>> If we make that change, then the other use-case where the Public Value is
>> received in some other form and extracted to an ArrayBuffer by the
>> application would require that ArrayBuffer to be imported to obtain a Key.
>> Thus the steps would be the same in both cases: import the received
>> public value, provide this Key object to deriveKey.
>>
>> ...Mark
>>
>> I would feel much better if this was always using key objects rather than
>> using an array of bytes as the second public key.  This would be true
>> regardless of the number of keys used in the process (i.e. for 4 key DH key
>> agreement methods).
>>
>> Jim
>>
>>
>>
>>
>