W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

Re: ISSUE-17: Key Attributes - Proposed resolution

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Wed, 5 Sep 2012 16:45:18 -0700
Message-ID: <5047E40E.6030306@netflix.com>
To: Ryan Sleevi <sleevi@google.com>
CC: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Mark Watson <watsonm@netflix.com>, "Arun Ranganathan" <arun@mozilla.com>
Hi Ryan,

I believe that the concepts of "unique ID" and "name" for a symmetric 
key are important and distinct, at least in the case of pre-shared keys.

I tried to make an argument previously about there being a parallel with 
X.509 certificates which have a "unique ID" in the form of a serial 
number and/or SubjectKeyIdentifier and a "name" in the form of a 
SubjectName and/or SubjectAltName.

But, as Wan-Teh mentioned on the last call, maybe we should meet f2f to 
discuss the issue rather than creating an ongoing distraction. We'll try 
to get something set up shortly.


On 9/4/12 6:59 PM, Ryan Sleevi wrote:
> On Tue, Sep 4, 2012 at 10:30 AM, Mitch Zollinger <mzollinger@netflix.com> wrote:
>> On 9/4/12 2:04 AM, Vijay Bharadwaj wrote:
>> We would like to see a standard way to identify a symmetric key, just as we
>> have a standard way to identify a public & private key pair.
>> Would something like PKCS#11's CKA_CHECK_VALUE suffice?
>> Google says:
>> CKA_CHECK_VALUE: The value of this attribute is derived from the key object
>> by taking the first three bytes of the ECB encryption of a single block of
>> null (0x00) bytes, using the default cipher associated with the key type of
>> the secret key object.
>> There are two problems I see with this approach:
>> 1. 3 bytes is not enough to uniquely identify a unique device key, when
>> there are 100s of millions (billions, perhaps?) of connected devices
>> currently and that number can only grow.
>> 2. Even if the number of bytes were increased, the uniqueness is only as
>> good as the random entropy used to create the key. Assuming all of the
>> device manufacturers use good HW generated random numbers and don't abuse a
>> PRNG initialized with time of day, the likelihood of collision becomes the
>> answer to the birthday problem. I don't think that's good enough ;)
>> Mitch
> Google the search engine, not Google the participants ;-)
> Why not just CKA_ID? Which is to say the same as / no different than
> the Key.id attribute (note: Specifically in the context of
> *pre-provisioned* keys. *Discovered* keys are likely different)
> Nothing in the spec, normative or informative, prevents an
> implementation from exposing some fixed, meaningful ID as the key ID,
> provided it meets the criteria of unique (to the key) and opaque (to
> the application - which is to say - its just bytes)
> As far as PKCS#11 is concerned, the CKA_ID is a common attribute for
> all Key objects, which is a byte array that is the "key identifier for
> key"
> Quoth the Spec:
> "The  CKA_ID attribute is intended as a means of distinguishing
> multiple publickey/private-key pairs held by the same subject (whether
> stored in the same token or not).  (Since the keys are distinguished
> by subject name as well as identifier, it is possible that keys for
> different subjects may have the same CKA_ID value without introducing
> any ambiguity.)
> It is intended in the interests of interoperability that the subject
> name and key identifier for a certificate will be the same as those
> for the corresponding public and private keys (though it is not
> required that all be stored in the same token). However, Cryptoki does
> not enforce this association, or even the uniqueness of the key
> identifier for a given subject; in particular, an application may
> leave the key identifier empty."
> However, as you can see, even PKCS#11 does not require that symmetric
> keys have any form of unique identifier, and if arguably one of the
> most widely implemented crypto APIs can do get away with it, I feel
> fairly confident that we could too.
Received on Wednesday, 5 September 2012 23:45:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:13 UTC