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

On Mon, Oct 29, 2012 at 6:23 AM, Mark Watson <watsonm@netflix.com> 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."

My initial reaction regarding the transformation is that while it's
good, I'm not sure how reasonable it may be to recommend at a SHOULD
level. In the case of smart card keys (for example), such
transformation may not be acceptable or possible - since access to the
key material is generally not available. It's also only really
applicable to symmetric keys (which generally lack any particular
structure), rather than asymmetric keys (which must follow some form
of mathematical construct)

It *sounds* like you think of pre-shared keys as being symmetric only,
but I'm not sure I'd agree with that.

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

I'm working on a proposal to fully remove the window.keys interface,
which I believe is the right approach. So we'll need to re-consider
the pre-provisioned key case.

Note - I think of the general issue being pre-provisioned (eg:
including symmetric and asymmetric), and not pre-shared (which implies
symmetric only, as a general term of art)

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

I really think this as problematic - for the various reasons we've
discussed during certificate. Minimally, we'd need to consider this as
an array, but I think practical/implementation concerns mean this is
not generally possible. For example, a key may be stored in one device
but a certificate stored in another device.

I'm also very loathe to expose attributes that are stored/managed on
security devices. The current (albiet synchronous) API is primarily
designed for attributes read/set by authors, and perhaps is a poor fit
for exposing pre-provisioned key attributes of meaningful semantic
form.

Case in point: A key stored on a smart card may have multiple
certificates issued, with various lifetimes and purposes, even though
they use the same key, such as cross-certified by different
organizations.

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

As I mentioned on IRC during the proposed wording, and as mentioned
during previous conversations, my big concern here is that there's
absolutely no definition of what a "globally unique identity" is, nor
how an implementor can determine, for the various forms of key storage
supported (whether hardware or software), if a given identifier is a
"globally unique ID"

For example, in PKCS#11, there is no such global *or* unique ID
requirement. Typically, such attributes are embedded in vendor ID
attributes that are specific to the hardware vendor, the middleware
being used, the version of the card being used, the provisioning
profile, etc. So it's reasonably impossible for a generic
implementation to reliably determine what construction constitutes a
"globally unique identity"

Further, it doesn't help that some "globally unique identities" are
the combinations of several attributes that, together, provide the
unique identifier. The fact that a key has a globally unique
identifier formed through the combination of n-number of attributes
creates ambiguity for implementations in determining if and how this
should be exposed to applications.

As such, unless we're defining exact storage semantics (which we're
not, at least so far), or defining exactly how pre-shared keys are
implemented (which, I would hope, we're not), then I'm not sure we can
reasonably or reliably provide this sort of statement.

Minimally though, I think the above wording MUST specify how an
implementation can determine if a "globally unique identifier" is
present for a pre-shared key, and I personally believe that's an
intractable task.

Received on Monday, 29 October 2012 13:41:46 UTC