Re: ISSUE-17: Key Attributes - Proposed resolution

On 9/5/12 5:17 PM, Ryan Sleevi wrote:
> 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.

You could argue that this is indicative of needing some standard for 
this purpose (?)

If I have two SSL server certificates for a single hostname issued from 
a single CA, where I had to revoke the old certificate for some reason, 
a client receiving this host's cert needs a SubjectName or 
SubjectAltName (a key "name" if you will) to match against DNS. If the 
client also wants to check the cert against a CRL (or OCSP?) it uses the 
serial number (a key "identifier" if you will) to identify the unique 
cert and match against CRL.

<I had more written here, but I deleted it. I'd rather meet f2f on the 
issue.>

> 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

<I had more written here, but I deleted it. I'd rather meet f2f on the 
issue.>

>   - 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:59:32 UTC