Re: ISSUE-17: Key Attributes - Proposed resolution

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.

Mitch

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