Project

General

Profile

Actions

Feature #2260

closed

KeyChain component indicator

Added by Yingdi Yu almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Security
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

We need an expression to indicate a particular KeyChain component (e.g., a instance of Pib or Tpm).
Such an indicator can facilitate KeyChain configuration.

The indicator is defined as a name with following naming convention:

[scheme]:[location]
  • scheme: either starts with tpm- or pib-, followed by the exact type of the implementation, e.g., tpm-osxkeychain, tpm-file, and pib-sqlite3.
  • loaction: interpreted by specific component implementation. Missing location means the default location.

Here are some examples:

tpm-file:                   // a file TPM at the default location (e.g., home dir)
tpm-osxkeychain:ndn         // an osx keychain with name "ndn"
pib-sqlite3:/example/dir    // a pib at /example/dir

Related issues 2 (0 open2 closed)

Related to ndn-cxx - Task #1906: Write documentation about client.confClosedAlex Afanasyev

Actions
Blocks ndn-cxx - Task #2242: Pair up SecPublicInfo and SecTpmClosedYingdi Yu11/30/2014

Actions
Actions #1

Updated by Yingdi Yu almost 10 years ago

  • Description updated (diff)
Actions #2

Updated by Junxiao Shi almost 10 years ago

  • Start date deleted (12/02/2014)

Consider giving it a prefix such as ndn:/localhost/keychain to make it clear that it's an indicator, not a routable Name.

Similar design is seen in Strategy Name, and identity Name of DigestSha256 signing.

Actions #3

Updated by Yingdi Yu almost 10 years ago

I would like to use the "ndn:" prefix if it explicitly specify that the name after it is just an indicator.

btw, I am not familiar with the "ndn:" prefix, any reference about how to use it?

Actions #4

Updated by Yingdi Yu almost 10 years ago

  • Blocks Task #2242: Pair up SecPublicInfo and SecTpm added
Actions #5

Updated by Yingdi Yu almost 10 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 80
Actions #6

Updated by Yingdi Yu almost 10 years ago

  • Description updated (diff)
Actions #7

Updated by Yingdi Yu almost 10 years ago

  • Description updated (diff)
Actions #8

Updated by Alex Afanasyev almost 10 years ago

  • Description updated (diff)
Actions #9

Updated by Alex Afanasyev almost 10 years ago

Do we really need to have such a class? It is just a KeyChain component will be identified by the name, but what is the value of having a special class for that?

Actions #10

Updated by Yingdi Yu almost 10 years ago

I take the class as a parser or checker of the name

Actions #11

Updated by Yingdi Yu almost 10 years ago

change my mind. I will simply provide two static checking methods of SecPublicInfo, so no need to keep a separate class.

bool
SecPublicInfo::isValidPibLocator(const Name& pibLocator);

bool
SecPublicInfo::isValidTpmLocator(const Name& tpmLocator);
Actions #12

Updated by Yingdi Yu almost 10 years ago

Or we can put it into KeyChain, given KeyChain is the only class that really need a correct TpmLocator/PibLocator.

Actions #13

Updated by Yingdi Yu almost 10 years ago

  • Description updated (diff)

Turns out that using name as indicators is a bad idea. The indicator should be easy to write in configuration. However, encoding directory in name may cause some confusions and may cause the name difficult to write. So I change it back to URI-style expression.

Actions #14

Updated by Yingdi Yu almost 10 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 80 to 100
Actions #15

Updated by Alex Afanasyev almost 10 years ago

  • Status changed from Code review to Closed
  • Target version set to v0.3
Actions #16

Updated by Alex Afanasyev over 9 years ago

  • Related to Task #1906: Write documentation about client.conf added
Actions

Also available in: Atom PDF