RE: crypto-ISSUE-25 (Global Unique ID): How do we provision Global Unique ID for pre-provisionned symetric keys [Web Cryptography API]

Thanks for clarifying the terminology.

Does it matter to you how the identifier is exposed in the API? In other words, if it was possible to pre-provision a key (of whatever scope) with certain read-only user attributes (like Ryan's recent proposal allows) would that be sufficient?

-----Original Message-----
From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Tuesday, August 28, 2012 9:38 AM
To: Vijay Bharadwaj
Cc: Harry Halpin; Mike Jones; Ryan Sleevi; 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 Aug 28, 2012, at 6:49 AM, Vijay Bharadwaj wrote:

> Mark, does my earlier proposal (http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0247.html) suffice for your needs?
> 
> In other words, if origin-authorized keys (which PSKs would be in that framework) had the property that their attributes were visible to all origins but could not be altered by any origin, would that meet this requirement? If not, can you help me understand the gap?

First, we have a terminology collision. I previously proposed the terms "origin-authorized" and "origin-specific" with different meanings from your proposal.

In my terminology, an origin-specific key is one which will only ever be used with a specific origin. Or rather this is the applications policy.

An origin-authorized key is one which the application intends may be used with multiple origins.

I don't think PSKs are necessarily origin-authorized (my definition). I'm most interested in origin-specific (my definition) PSKs. Origin-authorized keys raise more complex privacy issues, IMO.

The issue in this thread is that in practice any user of pre-provisioned symmetric keys needs some kind of identity for those that is bound to the keys. It would be nice to have a standard way to expose that, just as we expect there to be a standard way to expose certificates associated with pre-provisioned key pairs.

...Mark

> 
> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: Monday, August 27, 2012 1:11 PM
> To: Harry Halpin
> Cc: Mike Jones; Ryan Sleevi; 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 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 Tuesday, 28 August 2012 19:10:13 UTC