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

On Aug 21, 2012, at 11:27 AM, Ryan Sleevi wrote:

> On Tue, Aug 21, 2012 at 10:51 AM, Mark Watson <watsonm@netflix.com> wrote:
>> 
> 
> Mark,
> 
> While not trying to be dismissive, it remains unclear to me why you
> feel that the application-specific, context-specific unique identifier
> needs to be more special than any other pre-provisioned attribute.

Because the need for such an attribute is neither application- not context- specific, as I have explained. All applications with pre-provisioned symmetric keys (PSKs) will need such a thing because PSKs are useless without it (where useless = no different from keys generated randomly by the client).

Please note, I am arguing just for this to be supported in the specification. It's supported if you have KeyAttributes and the notion that some of those may be pre-provisioned along with the key itself. It's not supported if you remove KeyAttributes because there's nothing in the Local Storage specification about pre-provisioning (and if there was I think the link between the key and its attributes would still be too tenuous).

I'm fine with Local Storage for attributes that need to be stored by the JS application itself.

> 
> As I understand your response, it's primarily (solely?) focused on
> pre-provisioned keys, which are already an implementation-specific
> detail that is not going to be common across user agents, and is thus
> inherently non-portable to begin with.

Support for PSKs is essential to our use-case and included in the charter.

You are right that not all WebCrypto implementations will support them, which just means they are an optional capability. It will need to be possible for an application to discover whether a pre-provisioned key exists. Applications such as ours will behave differently, depending on whether a PSK exists or not.

> 
> That said, is there any reason why such an ID needs to be any
> different from any other pre-provisioned attribute?

What other pre-provisioned attributes ?

> Is this really a
> question about unique IDs (as has been framed by yourself and Mitch
> several times), or can your need simply be addressed by having
> whomever is doing the pre-provisioning of keys (an industry and
> application-specific act) also provision those attributes?

Where ? As I've said, pre-provisioning of Local Storage is not something mentioned in the Local Storage specification and may be viewed as rather odd.

> 
> I'd like to focus on this specific point, since I strongly feel the
> needs you have identified are already readily addressed by the spec,
> and what you're wanting to do is already possible, and without having
> to introduce any special handling for pre-provisioned keys, nor
> require any language changes to the spec.

Could you explain in more detail why you believe that ?

I am beginning to feel that we need a specific section on pre-provisioned keys, since there's clearly a wide variance in the assumptions people have about them.

> 
> To be completely unambiguous: pre-provisioned keys are inherently
> implementation specific, and thus I believe any attempt to define a
> common nomenclature for them is fatally flawed.

I disagree. The notion of a pre-provisioned symmetric key with an associated identity is straightforward and application-independent and we can easily specify is, just as is done for TLS PSK. Just because it is an optional feature doesn't make it's definition 'implementation-specific'.

> 
> Assume we resolve ISSUE-17 and agree that, indeed, it's necessary to
> have a specific attribute store for keys (for which the only use case
> I seems to be pre-provisioned keys...). As discussed previously, the
> KeyAttributes interface (
> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-KeyAttributes )
> fully supports read-only properties. That's why explicit
> getters/setters were defined, since WebIDL makes it clear that any
> accesses will be redirected through these getters/setters (
> http://www.w3.org/TR/WebIDL/ ) and that they need not support the
> operation.

Yes, if you have the KeyAttributes interface, everything is fine (modulo the descriptive text which I think it would be wise to add on this issue). There is no need to say what the "name" of the key id is, since whomever pre-provisions the id itself can tell me what the name is as well.

We could consider keeping KeyAttributes only for functional or read-only attributes and require applications to use Local Storage for application-specific stuff.

> 
> Possible ways that Netflix can do what they want without a spec change:
> * Presume a pre-provisioned Master Key (MK) which is secret from all
> applications
> * Goal is a pre-provisioned Origin Key (OK), which is origin-specific
> 
> Option 1: Implicit keys on demand:
>  - When the UA navigates to one of the authorized origins
>    - If an OK does not yet exist, generate one
>      - Pre-provision an attribute/value pair with "MKID" and the ID
> of the master key
>      - Pre-provision an attribute/value pair with "OKID" and whatever
> industry-specific origin key
>    - Expose it via window.crypto.keys
> Option 2: Explicit key derivation
>  - When the UA navigates to one of the authorized origins
>    - Expose the MK as a handle via window.crypto.keys
>    - Implement a custom key derivation mechanism ("Netflix-TV-keys")
>    - Have your application request that a key be derived from the MK
>    - The user agent performs the following steps:
>      - Take the origin of the currently executing script (which all
> UAs must track anyways), and feed that as input into your derivation
> scheme. Thus, it's *never* necessary the application provide it
>      - Derive the OK from the MK
>      - On the generated OK, set the OKID and MKID as appropriate
>      - Return the OK to the application
>     - The key is now available to the application, and may be
> available later via window.crypto.keys (if the caller requested the OK
> be persistent)

Both assume that there is a sensible place to pre-provision attributes. Local Storage is a sensible place for the application to store stuff, but I don't think it works for pre-provisioning key attributes.

I think both options could work, with some tweaks. If by 'ID of the master key' you mean a global id for that, then I would not expect that to be exposed. The idea of explicitly exposing a key derivation function that factors in the current origin is interesting. That could be under the covers (the application only ever knows about the OK), but there may be some advantage in giving the application control of the derivation. You'd need to derive an orgin-specific key identifier too.

In fact if we could specify the above approach that would make things significantly easier for device manufacturers.


> 
> Again, pre-provisioned keys are user-agent specific.

Support of pre-provisioned keys is user-agent-specific. That's different.

> There is no way
> to have pre-provisioned keys to universally work across user agents,
> since that universally assumes the same key storage and access APIs,
> which is simply impossible. So your user agent can do whatever it
> wants - because it's the only one who understands this concept.
> 

But there are some concepts which are generic, which we can standardize. We could standardize the origin-specific key derivation function and the concept of a common Master Key as you describe above. We would not make any statements about the properties this key has. Some implementations might just re-generate it randomly every time. Especially if you're in "incognito mode". Others would have it stored in hardware. Doesn't matter because the API is not guaranteeing any special properties for this key. Any special properties are learned out-of-band.

…Mark

Received on Tuesday, 21 August 2012 19:06:12 UTC