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 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<mailto: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