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

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