NFD » ndn-cxx

The term key handler is inaccurate.

Merriam-Webster dictionary defines handler as: one that handles something.
handle as a verb is defined as: to act on or perform a required function with regard to.

This means key handler is an active subject that acts on a key.

However, statements "the handler is a Keychain Item Reference" and "the handler could simply carry the private key" indicate that the key handler is an passive object that represents or references a key.

I recommend the term key handle, where dictionary meaning for handle is: a part that is designed especially to be grasped by the hand.

The usage of handle is also consistent with its meaning in Win32 API: An object is a data structure that represents a system resource, such as a file, thread, or graphic image. An application cannot directly access object data or the system resource that an object represents. Instead, an application must obtain an object handle, which it can use to examine or modify the system resource.

Under this definition, a key (either OSX Keychain Item Reference or the private key in a file-based TPM back end) is an object, and a key handle is used to examine that object.

I am ok to change this class name to KeyHandle

Reply to note-7:

Description of this issue should be updated to reflect this decision.

We recently ran into a decision problem about the default way to create a key ID. Here is the problem:

An identity may have more than one keys, in order to distinguish different keys under the same identity, we add a KeyId component as a part of key name, after the portion of Identity, so the purpose is to make sure there is no two keys for the same identity have the same key name.

In our earlier implementation, the default way to create a key ID is to use the timestamp. However, timestamp does not provide a strong uniqueness. Here are several possible scenarios:

• In ndn-cxx test cases, we use a pseudo clock in some test cases, such a clock always start from a fixed time point, and does not move forward unless there is an explicit advance call. So that it is highly possible that test cases will try to create keys with the same key ID. This is usually fine if the clean up phase of test cases works well. However, once there is some error, or configuration of test case environment goes wrong, keys may not be cleaned up in the TPM, so that when we tried to create a key with the same name, the library will throw an Error saying that key already exists.

• In distributed signing scenario, for example, Alice wants to create her keys for the same app on both her laptop and smart phone. It cannot guaranteed that the two timestamps would be different.

Moreover, the default mechanism should be used when people do not care about the key ID, therefore using key hash as the default mechanism can always guarantee the uniqueness of the key name unless the hash algorithm is broken. On the other side, if we use timestamp as the default mechanism, it requires every system must have synchronized clock, and it is difficult to control the library to use the appropriate timestamp as the key id.

So the problem is: should we take key hash or timestamp as the default way to create key ID?

I'm strongly opposing the use of a key hash name component provide "uniqueness" (as a default). Name hierarchy provides the context and most of the uniqueness properties, with timestamp having relatively good uniqueness properties (minus a few corner cases you mentioned), plus having

• short and concise representation, it is easy to read and distinguish different keys
• increasingly monotonic, so it is easy to see which one created later

Alex and I had a discussion about this problem. We clarified our desires.

What I want is "a default KeyId generating method which is independent of any system", such as clock.

What Alex wants is "not using hash as the KeyId", because it may discourage people to use naming hierarchy to assure uniqueness of name.

We agreed to use 8-byte random number as the default KeyID generating method. Hopefully, this compromise can resolve this issue.