Project

General

Profile

Actions

Task #2444

closed

Simplify KeyChain

Added by Andrew Brown about 9 years ago. Updated over 6 years ago.

Status:
Abandoned
Priority:
Normal
Assignee:
-
Start date:
01/28/2015
Due date:
% Done:

0%

Estimated time:

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:

  1. moving from two-layer model (with IdentityManager) to a KeyChain with a TPM instance and a PIB instance
  2. 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.
  3. removing all generate... methods from KeyChain; expose the TPM with getTPM() and allow generation there.

Thoughts?

Actions #1

Updated by Andrew Brown about 9 years ago

  1. add some integration tests for identity creation
Actions #2

Updated by Yingdi Yu about 9 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.

Actions #3

Updated by Andrew Brown about 9 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.

Actions #4

Updated by Anonymous about 9 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

Actions #6

Updated by Anonymous about 9 years ago

  • Project changed from jndn to NDN-CCL
Actions #7

Updated by Anonymous over 6 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.

Actions

Also available in: Atom PDF