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 11:08 AM, Ryan Sleevi wrote:

> On Mon, Aug 27, 2012 at 10:40 AM, Mark Watson <watsonm@netflix.com> wrote:
>> 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'd suggest at least three levels of in-scope here:
> 1) Ensuring that PSKs, if implemented, can function within the API,
> and with minimal-to-no use of normative language.
> 2) Dictating exact details of how PSKs are implemented or requiring a
> special class for/distinction from other types of keys (eg:
> site-generated, site-authorized).
> 3) Requiring that PSKs be implemented.
> 
> I agree with 1. I have more trouble with 2, and absolutely cannot agree with 3.

Noone is proposing 3.

> 
>> 
>> 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
> 
> In the case of pre-provisioned keys - that is, keys generated outside
> of the user agent - I do not think (a) is something we can or
> necessarily should try to standardize.
> 
> The nature of how PSKs are supported is going to be implementation
> dependent. Some may require you import the keys out-of-band. Some may
> expose existing, native cryptographic APIs. Some may directly
> interface with some secure element or device that is specific to the
> operating environment of the user agent. Each has different
> requirements and needs and details.
> 
> Because of that, I'm extremely wary about how realistic it is to try
> to describe some set of normative non-functional attributes for these
> keys. Even the concept of 'identifier' is problematic between these
> implementations. If using an OS key store, should the identifier be
> the OS key ID? The label (which isn't supposed to be an ID)? Some
> other attribute?

We don't have to specify details of how such keys are provisioned (your 2nd para above). We don't have to specify any details about what the identity is either. Anyone using such keys will need to discover - out-of-band - what the identities are for all the pre-provisioned keys and what they signify. The most we could conceivably do is something like "If a pre-provisioned symmetric key has an associated identifier, it should be exposed <like this>". No more.

(Btw, I could imagine an equivalent for public/private key pairs: "If a pre-provisioned public/private key pair has an associated certificate, it should be exposed <like this>".)

> 
> Even at the (existing) API layer, the concept of fixed,
> pre-provisioned IDs is something that varies with implementation. One
> smart card vendor may expose such keys by using the PKCS#11 attribute
> CKA_LABEL, while another might instead use the CKA_ID, and yet a third
> use the vendor-specific CKA_* attributes to define some custom scheme.
> 
> That's why I think (b)/(c)/(d) are the more realistic approaches that
> balance the needs of UAs and implementations.
> 
> I'm also concerned that the lack of use cases AND implementors for
> PSKs will, if we were to attempt to define (a), lead to a solution
> that was narrowly defined to the needs of a particular vendor/set of
> vendors. We should keep in mind that we can always define it as
> (b)/(c)/(d) and, if it turns out the it is needed and there are
> significant implementors with experience, define (a) at a later point.
> Given that the perfect is the enemy of the good, I'd rather we focus
> on what major implementations can commit to implementing and shipping
> before we go too far into trying to normatively specify optional
> behaviours.
> 
>> 
>> 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
> 
> I'm not sure I follow how this conclusion is reached, in-as-much as
> PSKs are in the realm of implementation details, but I think each user
> agent that does support PSKs can choose the appropriate level of
> information and transparency to expose to users. As the W3C is not in
> the habit of normatively requiring UI details, especially not when it
> relates to security dialogs or user details, even if we were to go
> with (a), I do not see the need in any way addressed differently. The
> two are, arguably, orthogonal, and so conflating them seems to be
> disingenuous.

By transparency, I did not mean anything to do with UIs, but that fact that there is public information about how things work and that they work in a similar way across different systems.

…Mark

>

Received on Monday, 27 August 2012 18:22:54 UTC