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

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

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).

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

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.

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.

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