- From: Mitch Zollinger <mzollinger@netflix.com>
- Date: Tue, 4 Sep 2012 17:42:04 -0700
- To: Ryan Sleevi <sleevi@google.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On 9/4/12 3:33 PM, Ryan Sleevi wrote: > On Tue, Sep 4, 2012 at 12:07 PM, Mitch Zollinger <mzollinger@netflix.com> wrote: >> Regarding Section 11.2: >> >> id >> >> For all Keys visible within a given origin, each Key shall have a unique, opaque identifier assigned that may be used to uniquely identify that Key within the set of keys. >> >> Within the same origin, if two Keys are created from the same underlying keying material, they MUST share the same id. >> >> >> What is meant by "if two Keys are created from the same underlying keying material" here? >> >> Does this mean that if I have some key material that I use as an AES key in one case and as a 3DES key in another, they will have the same ID? > > Thanks for pointing out the ambiguity, caused by an assumption on my > part on the implementation details. > > The /intent/ was for implementations that use handles from underlying > cryptographic providers, that the ID remains the same. This was in > anticipation of things like key querying, which multiple queries > should return the same key ID for the same logical key. > > That said, it may be inappropriately overspecified here, in addition > to the ambiguity. I'll see if I can find a better way to word this (or > suggestions welcome, or perhaps it's unnecessary), but the intent was > that algorithm was part of the identity of the underlying key - ergo, > two different IDs. > >> Also, would the algorithm be such that if my keying material on one device matched the keying material on another device that this ID would be identical for the same origin? > No statement is made one way or the other. This is a user agent (eg: > purely client side) behaviour. As long as an implementation meets > those criteria, I would expect it to be fine. So they may share the > same ID between devices, or they may be unique between devices. > Ok. That's what we were hoping for. Mitch
Received on Wednesday, 5 September 2012 00:42:32 UTC