Fwd: Proposal for ISSUE-25 (Globally unique pre-shared keys)

Begin forwarded message:

From: Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>>
Subject: Re: Proposal for ISSUE-25 (Globally unique pre-shared keys)
Date: November 1, 2012 10:23:42 AM GMT+01:00
To: Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>>

Here's a first stab at some text characterizing the globally unique identifier. This would replace the proposal for 10.2.2. below (we can replace the text fort 10.2.1 with a "tbd" if you like).

"10.2.2 Pre-provisioned symmetric keys and identifiers

Pre-provisioned symmetric keys may be exposed as Key objects with specific id attribute values known to users of those keys. Pre-provisioned symmetric keys are frequently provisioned with associated identifiers. Where an identifier exists that uniquely identifies the key amongst all keys pre-provisoned under the same id value (in the widest sense, across devices, UAs etc.) and if this identifier can be canonically expressed as a sequence of no more than 256 bytes, then this identifier SHOULD be exposed, base64 encoded, as the "uid" property within the extra attribute of the key interface. If no identifier matching these conditions exists, the "uid" attribute SHOULD NOT be present."

We could, I suppose, add the following, though it seems a little arbitrary: "If multiple identifiers exist that match the above conditions, the smallest, interpreting the identifier as a big-endian unsigned integer, should be used." With this, any two people given the key and the same set of identifying information, whatever that may be, will arrive at the same identifier. Implementing it might not be straightforward.

…Mark

On Oct 29, 2012, at 2:23 PM, Mark Watson wrote:

All,

To address ISSUE-25 [1] I'd like to propose the following changes. I hope we can discuss this later in the week.

1) To Section 6, Privacy Considerations, replace the last sentence of the "Super-cookies" section ('This is especially true for keys that were pre-provisioned for particular origins and for which no user interaction was provided') with a more detailed separate section:

"Pre-shared keys

Pre-shared keys may be long-lived and may be securely associated with specific hardware elements. Without sufficient safeguards it may be possible for an origin to identify a user or device without the knowledge or consent of the user. Access to pre-shared keys SHOULD require explicit user authorization on a per origin basis. User Agents supporting pre-shared keys SHOULD ensure that each origin receives a unique origin-specific pre-shared key. This could be accomplished, for example, by transforming an origin-independent secret using a suitable origin-specific one-way function."

2) To Section 10 (Key interface) [or wherever is most appropriate], add new sub-section, as follows:

"10.2 Pre-shared keys

User Agents MAY expose origin-specific pre-shared keys as Key objects visible within the keys attribute of the Crypto interface. Examples of pre-shared keys include keys stored in secure hardware elements.

10.2.1 Pre-shared key pairs and certificates

Where a pre-shared public/private key pair has an associated X.509 certificate, this certificate SHOULD be made available in a property named "x509certificate" within the extra attribute of the Key object. The "x509certificate" property contains the base64 encoding of the … <specify encoding of X.509 certificate here>.

10.2.2 Pre-shared symmetric keys and identities

Where a pre-shared symmetric key has an associated globally unique identity, this identity SHOULD be made available in a property named "uid" within the extra attribute of the Key object. The "uid" property contains the base64 encoding of the bytes of the globally unique identity."

…Mark

[1] http://www.w3.org/2012/webcrypto/track/issues/25