Re: ISSUE-17: Key Attributes - Proposed resolution

On Wed, Sep 5, 2012 at 4:45 PM, Mitch Zollinger <mzollinger@netflix.com> wrote:
> 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.

For what it's worth, neither of these are unique in any meaningful way
for any meaningful use on the Internet or native code. Despite what
PKIX or X.509 may say, ensuring uniqueness for Serial+Issuer or
SKID+Issuer is not followed in practice, either by commercial CAs or
"roll your own cert" applications, and client applications that assume
either pair are unique tend to fail in new and wonderful ways.

I'm not aware of any cryptographic API that has tried to find a true
and Unique Identifier for certificates. All such identifier schemes
are application specific - CryptoAPI identifiers are not
interchangable with PKCS#11 identifiers, and even within different
modules, PKCS#11 identifiers are not interchangable. At best, the text
contains a recommendation to have certificates follow whatever the
same scheme as used for the public/private key ID, but even that is
"not required, and not commonly implemented"

>
> 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 Thursday, 6 September 2012 00:18:13 UTC