Task #2444
closed
Added by Andrew Brown almost 10 years ago.
Updated about 7 years ago.
Description
As per http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2015-January/000237.html and associated chain, I would like to discuss simplifying the KeyChain class structure a bit. I think we could move closer to the ndn-cxx model by:
- moving from two-layer model (with IdentityManager) to a KeyChain with a TPM instance and a PIB instance
- creating an Identity -> Key -> Certificate class chain (e.g. keyChain.getIdentity(...).getKeys(...) or .getDefaultKey(...)); this would allow us to remove some extra methods like getCertificate(), getDefaultCertificateNameForIdentity(), etc.
- removing all generate... methods from KeyChain; expose the TPM with getTPM() and allow generation there.
Thoughts?
- add some integration tests for identity creation
We have started changing ndn-cxx to provide the "Identity->Key->Certificate" abstraction. Michael Sweatt (an undergrad at UCLA) is working on that. I will create a redmine task for ndn-cxx.
Some generate methods should be removed, but maybe not all. In ndn-cxx, we have generateRsaKeyPair and generateEcdsaKeyPair, these two methods should be simplified as generateKey which accept a KeyParams argument. Some generate methods should be done at the KeyChain level and should not be removed, e.g., the methods to generate certificates.
I am a little bit conservative to expose TPM and create keys through getTPM() directly, because the keys in TPM should be consistent with PIB. If user can explicitly use TPM to create keys, then user must maintain the corresponding data in PIB. From users' perspective, it might be better to ask KeyChain to handle all these operations implicitly.
Yingdi, makes sense; to your last point: should the user ever only be doing stuff like createIdentity()? Or to add an additional key, generateKey(KeyParams) and then something like getIdentity().addKey()? I agree that it seems like the user shouldn't be generating keys straight from the TPM but a getTPM() allows them to do that if they know what they're doing.
- Project changed from jndn to NDN-CCL
- Status changed from New to Abandoned
Abandoning this since it is part of security v1 which is deprecated. The proposed changes were made by looking at early versions of the security v2 API (such as removing IdentityManager). This is now the primary API in the Common Client Libraries.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Anonymous