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

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

Received on Thursday, 27 February 2014 21:00:15 UTC