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

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.

>
> 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?

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.

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