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

Hi Ryan,

It's a long thread, so I'm just going to provide my comments up front. I think they address all the points you make below.

Support for pre-provisioned symmetric keys has been in scope of this work since the very beginning. It was discussed (without dissent) back at the "Identity in the browser" workshop last year and it's fundamental to the use-case we provided during chartering. I don't think there can be any doubt about the status of this feature with respect to our scope.

I've explained why, practically, any application that actually requires pre-provisioned symmetric keys also requires some kind of pre-provisioned identity associated with those keys. I can provide examples if you like. Basically, the client needs to indicate some kind of identity to the server. If this identity is not at least based on some pre-provisioned information associated with the key, then the application could work just as well with a client generated key. 

Given that, I can see four possibilities for how an associated identity might be exposed to applications:
(a) in a standard manner defined in the WebCrypto specification
(b) in a manner defined by each implementor who decides to support PSKs
(c) in a manner defined by each application provider who needs PSKs (assuming they can pursuade implementors to do something different for each application)
(d) both (b) and (c)

(b) obviously makes things difficult for applications, which must support multiple platforms each taking a different approach
(c) makes things difficult for implementations, who must support application-specific requirements

So I believe there is value in (a). Having said that, at Netflix we can work with (b) or (c). Mainly because we have the resources to deal with that complexity.

Privacy is central here. That's one reason why I think the same-origin policy should be strictly applied to such keys and exceptions very carefully considered.

Users' control of their privacy is enhanced by transparency. When people know what is happening and how, then systems can be publicly analyzed and users can be informed and make informed decisions about privacy. Transparency is enhanced by standardization. Options (b), (c) and (d) leave users with less information and reduce transparency because implementors must find proprietary solutions for a gap in the standard.

…Mark

On Aug 22, 2012, at 6:39 PM, 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.
> 
> 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 17:40:51 UTC