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

On Tue, Aug 21, 2012 at 10:51 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Aug 21, 2012, at 10:18 AM, Ryan Sleevi wrote:
>
> On Tue, Aug 21, 2012 at 2:50 AM, Web Cryptography Working Group Issue
> Tracker <sysbot+tracker@w3.org> wrote:
>
> crypto-ISSUE-25 (Global Unique ID): How do we provision Global Unique ID for
> pre-provisionned symetric keys [Web Cryptography API]
>
>
> http://www.w3.org/2012/webcrypto/track/issues/25
>
>
> Raised by: Virginie GALINDO
>
> On product: Web Cryptography API
>
>
> During our call on the 20th of august, it was agreed that the way global
> unique identifier should be associated with a pre-provisionned symetric key
> needs further discussions. Several possibilities were expressed : adding
> another id to the key, integrating into specific attributes...The grop needs
> to make a decision on the best way to address this requirement.
>
>
>
>
>
> As I mentioned during our face to face and past calls, I believe such
> an ID is not a functional attribute (that is: intrinsic to the key,
> such as algorithm or size), but an application-specific attribute.
>
>
> Such an attribute is a necessary adjunct to a pre-provisioned symmetric key
> for any application. Otherwise the application has no way to identify, at
> the server side, which key was used to encrypt/sign data at the client.
>
> As such it is not 'application-specific' in the sense that some applications
> will need it and other will not.
>
> I would argue that it is a functional attribute of the key - because the key
> is useless without it (or rather has no properties that differ from a key
> generated randomly at the client).
>
> But we should avoid definitional ratholes - it suffices to say that this is
> very different from an arbitrary application-specific data that an
> application chooses to assign to a key.
>
>
> The ability to identify a symmetric key is something that is dependent
> on application-specific context, and is not something that is generic
> for all applications, for all users. While I realize that an
> application, in order to successfully (de/en)crypt a message needs to
> know what the key the peer will be using, such agreement is an
> application and context-specific decision, and not a system that is
> shared globally, even among major protocols.
>
>
> The mechanism for sharing the identifier/key pairs between whomever
> pre-provisioned them and whomever will be using them is certainly 'context
> specific' - as in a private agreement between those two parties. However the
> need for the identifier - and for it to be exposed to the application - is
> common to all applications/contexts where pre-provisioned symmetric keys are
> used.
>
> For example, such an
> identifier is not needed for the well functioning of S/MIME, TLS,
> IPSec, or OTR, as proof of why I do not believe this is a fundamental
> problem or functional attribute.
>
>
> These generally rely on public/private key pairs and certificates for
> authentication. In that context there is a need to communicate certificates,
> which communicate the identities bound to the public keys.
>
> Where Pre-Shared Keys are used, for example TLS PSK [1], then there is a
> corresponding need for a PSK identity. So I would specifically cite TLS PSK
> as an example of why this *is* a functional attribute of pre-shared
> symmetric keys.
>
>
> For example, if I'm authoring an application with which users log
> into, and for which there is only a single key associated with those
> users, then the unique identity of a key is derived from (username).
> If I allowed the user multiple keys, I might identify those per-user
> keys with a monotonically increasing counter, thus the unique identity
> might be derived from (username, monotonic-key-id). Alternatively, I
> might have the user self-report the Key's id attribute, at which
> point, the unique identity might be (username, id).
>
>
> One point of pre-shared keys is that I can learn from the entity that
> pre-provisioned them (out of band) properties of the place they were
> provisioned to. For example what type of device and what kind of security
> properties it has. I can use those properties to inform application
> decisions when someone uses one of those keys. But for that I need to know
> which key they are using - specifically that it is, indeed, one of the ones
> that was placed into one of these devices.
>
> This is completely independent of user identity and user authentication.
> This is very much the whole point of our use-case for pre-shared symmetric
> keys.
>
>
> Different applications will have different needs with respect to this.
> For example, in a system where there is no user authentication, nor
> any other form of "persistent" identifier (eg: machine identity), I
> might choose to use an alternate scheme.
>
>
> In this case I am not sure you need pre-shared keys. A key randomly
> generated at the client should suffice.
>
>
> In such a scheme, I either have the user generate or import a key, and
> then I, as the application author, bestow on it a
> unique-for-my-application identity. This identity could be stored
> wherever key attributes are stored - whether it be WebStorage,
> IndexedDB, or the strawman KeyAttributes.
>
>
> Yes. In this case I agree that the application identity bestowed upon the
> user generated/selected key is an application-specific attribute which the
> application can just put in local storage.
>
>
> Further, if I wanted to pre-provision keys, and I wanted to include an
> application-specific unique identifier that uniquely identified that
> key among all sets of keys in the whole of the world, I could equally
> pre-provision such an attribute, in whatever attribute storage. This
> again goes back to the use case of pre-provisioned attributes.
>
>
> It it no me, as application provider, who pre-provisions the keys. For
> example, in the case of TVs, it is the TV manufacturer. Since the need for
> an identifier is universal it makes sense for there to be an
> application-specific way to expose it, to avoid the pre-provisoners having
> to do something different for every application and to permit
> implementations which generate these keys and identities on demand (as I've
> described in another mail).
>
> I also feel nervous about introducing a new concept of "pre-provisioned
> Local Storage", which does not exist in the Local Storage specification.
>
>
> However, I do not believe it useful nor necessary to codify such a
> usage in the specification. Much like the major low-level APIs such as
> CNG, CDSA, CryptoAPI, PKCS#11, OpenSSL, JCA, and BSafe, which also do
> not expose any such "globally unique for all consumers of this API"
> identifier, I do not feel it's necessary to do so for this API. The
> primitives are flexible enough to allow the use case, certainly, and
> the less that is necessary to reach consensus on and for implementers
> to have to worry about implementing, the better.
>
>
> It's useful and necessary for the reasons described above. Exposing it in
> the WebCrypto API is no different from TLS PSK including the PSK identity in
> the ClientKeyExchange structure.
>
> Note that the identity does not need to be "globally unique for all
> consumers of the API". IMO, pre-shared keys should be origin-specific.
> Different origins using pre-shared keys should have different keys with
> different identities.
>
> …Mark
>
>
>
> [1] http://tools.ietf.org/html/rfc4279
>

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.

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.

That said, is there any reason why such an ID needs to be any
different from any other pre-provisioned attribute? 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?

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.

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.

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.

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)

Again, pre-provisioned keys are user-agent specific. 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.

Received on Tuesday, 21 August 2012 18:27:44 UTC