Project

General

Profile

Feature #2260

KeyChain component indicator

Added by Yingdi Yu almost 7 years ago. Updated over 6 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

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
#1

Updated by Yingdi Yu almost 7 years ago

  • Description updated (diff)
#2

Updated by Junxiao Shi almost 7 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.

#3

Updated by Yingdi Yu almost 7 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?

#4

Updated by Yingdi Yu almost 7 years ago

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

Updated by Yingdi Yu almost 7 years ago

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

Updated by Yingdi Yu almost 7 years ago

  • Description updated (diff)
#7

Updated by Yingdi Yu almost 7 years ago

  • Description updated (diff)
#8

Updated by Alex Afanasyev almost 7 years ago

  • Description updated (diff)
#9

Updated by Alex Afanasyev almost 7 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?

#10

Updated by Yingdi Yu almost 7 years ago

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

#11

Updated by Yingdi Yu almost 7 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);
#12

Updated by Yingdi Yu almost 7 years ago

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

#13

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

#14

Updated by Yingdi Yu almost 7 years ago

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

Updated by Alex Afanasyev over 6 years ago

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

Updated by Alex Afanasyev over 6 years ago

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

Also available in: Atom PDF