- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 27 Aug 2012 20:10:39 +0000
- To: Harry Halpin <hhalpin@w3.org>
- CC: Mike Jones <Michael.Jones@microsoft.com>, Ryan Sleevi <sleevi@google.com>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "Web Cryptography Working Group" <public-webcrypto@w3.org>
On Aug 27, 2012, at 12:54 PM, Harry Halpin wrote: > On 08/27/2012 09:45 PM, Mark Watson wrote: >> To Harry's comment below, what I understand was out of scope with respect to identity was consideration of actual, "non-opaque" identity schemes, since this was recognized as something of a can or worms. What is required for identification of pre-shared symmetric keys, however, can be completely opaque. >> >> There is no need for the API to place any requirements on or have any knowledge of the structure of this identifier or to process it in any way other than to expose it to the application. > > OK, then that would be in scope *I think* if what you want is some kind of standardized (i.e. non-custom,) attribute for GUIDs for keys where we *guarantee* that identifier is not used by another key in the same container, correct? So we'd want the API to enforce that guarantee across all keys being stored? No, not quite. The requirement for our application is that there is an identifier for the pre-shared key which is globally unique i.e. no other such key in any other device has the same identifier. I don't propose that we normatively specify that requirement. What I'd like is that IF there is a pre-shared key and IF it has some kind of unique identifier THEN that identifier should be exposed in a standard way. At the very least, we should describe, non-normatively, the possibility for UAs to expose such identifiers in a UA-specific way and give some examples of how this might be done within the API (for example, UA-specific key attributes). …Mark > > > > >> >> This is an important distinction which I thought was clear at the time. Again, this has been a central part of our use-case from the start. >> >> …Mark >> >> >> On Aug 27, 2012, at 12:22 PM, Mike Jones wrote: >> >>> GUIDs (http://tools.ietf.org/html/rfc4122) seem like an obvious choice. Most platforms provide GUID generation capabilities. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Harry Halpin [mailto:hhalpin@w3.org] >>> Sent: Monday, August 27, 2012 12:07 PM >>> To: Ryan Sleevi >>> Cc: Mark Watson; GALINDO Virginie; Web Cryptography Working Group >>> Subject: Re: crypto-ISSUE-25 (Global Unique ID): How do we provision Global Unique ID for pre-provisionned symetric keys [Web Cryptography API] >>> >>> On 08/23/2012 03:39 AM, Ryan Sleevi wrote: >>>> On Tue, Aug 21, 2012 at 5:15 PM, Mark Watson <watsonm@netflix.com> wrote: >>>>> On Aug 21, 2012, at 4:09 PM, Ryan Sleevi wrote: >>>>> >>>>>> If Netflix (or more likely, their device manufacturers) wanted to >>>>>> expose device unique keys, then I would propose that they could >>>>>> together propose text on how devices supporting such keys >>>>>> 1) Be exposed to user agents >>>>>> 2) Be exposed to web applications if supported by user agents. >>>>>> Including, but not limited to: >>>>>> 2a) Their presence in window.crypto.keys (or some other object >>>>>> that implemented the KeyStorage interface) >>>>>> 2b) The presence of read-only KeyAttributes >>>>>> 2c) Optionally, the 'well-known names' of these attributes, along >>>>>> with their possible values >>>>>> >>>>>> Such an effort would be complementary to the Web Crypto API, but not >>>>>> an essential part of it for implementers. That seems to highlight >>>>>> your remarks as an "optional" piece. >>>>>> >>>>>> I would rather the spec, to the degree possible, focus entirely on >>>>>> the mandatory parts that MUST be implemented by conforming user agents. >>>>>> That is, this is how the interfaces MUST behave and this is what >>>>>> MUST be exposed, and to the best degree possible, avoid any MAY language. >>>>> I appreciate the desire to maximize the normative mandatory capabilities and minimize the normative optional capabilities. But there are inevitably going to be normative optional capabilities (as you say, "UAs MAY implement X like this..." means either you don't implement it or you implement exactly what is specified.). >>>>> >>>>> There may be advantage in editorially separating the normative mandatory from the normative optional. Maybe separate documents, maybe a separate section in our one document. Normative mandatory parts will likely be implemented first. This is something we should discuss with the group. But it's unrealistic that the normative optional set is empty. >>>>> >>>>> I'm perfectly happy to propose text as you describe above for the normative optional part, but it should be part of our activity here, not outside the W3C. >>>> I would have to defer to the chairs on this, but I would think >>>> specifying such an attribute may or may not be within the scope of our >>>> work, and thus would likely need consensus about being a use case that >>>> this group would want to adopt and support. >>> Just to clarify, in the charter we originally specified that a standardized notion of "identity" (i.e. of users, client devices, etc.) would be part of the scope, but then decided that that would be out of >>> scope: "features including special handling directly for non-opaque key identification schemes, access-control mechanisms beyond the enforcement of the same-origin policy". So thus, I think "identity" information will for the time being have to be done in a custom key attribute. >>> >>> That being said, we recognize this is sub-optimal for Web developers who don't have the implementation experience of folks like Netflix. Thus, it makes sense for the W3C at some point to form another Working Group on this topic, once the work around Web Cryptography is more mature. I will suggest that we discuss this in the plenary session at the W3C TPAC. >>> >>> cheers, >>> harry >>> >>> [1]http://www.w3.org/2011/11/webcryptography-charter.html >>> >>> >>> >>> >>>> If I understand your response correctly, we've identified and agreed >>>> that pre-provisioned key attributes would offer sufficient flexibility >>>> for your immediate needs. You now wish to have this WG, as part of its >>>> work product, specify the exact format of these attributes, for the >>>> subset of user agents that support pre-provisioned keys of this >>>> particular nature (stored in secure elements, device storage, etc), >>>> either as part of the primary specification or as an additional work >>>> product of this group. Is this correct? >>>> >>>> Such work naturally has profound privacy implications, since >>>> supporting such a scheme implies the ability to track individual >>>> secure elements or devices for which the user may not be aware of nor >>>> have explicitly granted access to. This privacy requirements would >>>> need to be carefully considered and documented. >>>> >>>> Considering that the working group has not yet even begun to broach >>>> the topics found in our Secondary API functionality, I could not >>>> support such work, especially not under the timelines set forth by our >>>> charter. At best, I would support the documentation of this need in >>>> the supplementary Web Cryptography Use-Cases and Requirements >>>> document, and as a possible topic for future WG activity following the >>>> advancement to CR/PR of the primary API. >>>> >>> >>> >>> > >
Received on Monday, 27 August 2012 20:11:07 UTC