Task #2444
closed
Simplify KeyChain
0%
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?
Updated by Andrew Brown almost 10 years ago
- add some integration tests for identity creation
Updated by Yingdi Yu almost 10 years ago
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.
Updated by Andrew Brown almost 10 years ago
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.
Updated by Anonymous almost 10 years ago
Hi Yingdi,
You say "these two methods should be simplified as generateKey which accept a KeyParams argument", but it looks like ndn-cxx already has a private generateKeyPair which is used by generateRsaKeyPair. Do you just want to make it public?
https://github.com/named-data/ndn-cxx/blob/master/src/security/key-chain.hpp#L718
Updated by Andrew Brown over 9 years ago
Clearer discussion at http://redmine.named-data.net/issues/2451
Updated by Anonymous about 7 years ago
- 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.