[Nfd-dev] Intended scope of client.conf

[Burke, Jeff]

Right, thanks.

 I basically understand how all of this works, but think that we may want to explicitly describe it in the documentation rather than leave it implied by redmine entries and code... then we can make sure that the specification is followed in NDN-CCL.

So, the idea is that client.conf provides per-user configuration for NDN applications that gives the default keystore and mechanism for connecting to the local daemon.   For now, the default keystore specified in this configuration must be used if an application wants to interact with the identities/keys manipulated by the ndnsec tools.   Is that the right way to state it?

A few questions:

- NFD and NRD use their own system-wide configuration file, not client.conf.    The unix socket they use is defined in their nfd.conf file.  But where is the keystore for the keys used by NFD and NRD, and how is it configured?  I couldn't find this in the developers guide.

- It is assumed that there is only one installation of NFD/NRD per host.  So, shouldn't the socket configuration and protocol be per-host rather than per user?  I understand that for convenience they may be in client.conf, but want to confirm... perhaps their should be a client-default.conf in the same place as nfd.conf, and just override it from ~/.ndn/client.conf?

- There is an operator identity created by default at the time of installation of NFD/NRD.   This seems to be associated with the user who installed the software.   For NDN applications that run under other (non-root) users, is the idea that they can use their own client.conf settings, but the operator of the machine will need to authorize their key to sign things like prefix registration commands for the daemon?

- Because it uses ndn-cxx, ndnsec manipulates the PIB/TPM for the current user, based on the settings in that user's client.conf.  Is that correct?  This may need to be clarified in the documentation.   Also, ndnsec-list does not seem to take into account the TPM setting, it just lists all of the keys in the PIB for the user.  Perhaps it could indicate which TPM they are stored in, to aid debugging?


Thanks,
Jeff


From: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Mon, 18 Aug 2014 15:49:59 -0500
To: Steve DiBenedetto <dibenede at cs.colostate.edu<mailto:dibenede at cs.colostate.edu>>
Cc: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Intended scope of client.conf


On Aug 18, 2014, at 3:38 PM, Steve DiBenedetto <dibenede at cs.colostate.edu<mailto:dibenede at cs.colostate.edu>> wrote:


On Aug 18, 2014, at 2:25 PM, Burke, Jeff <jburke at remap.UCLA.EDU<mailto:jburke at remap.UCLA.EDU>> wrote:


Hi folks,

Is there any specification for the purpose and scope of client.conf.  E.g., how it can be located, what can be specified there, and what code should pay attention to it?

I'm not aware of a full specification for the current client.conf. Here's the original client.conf redmine issue that covers file format, location, and some parameters: http://redmine.named-data.net/issues/1364 .

This is basically the spec.  A new addition that was made long time ago was part of http://redmine.named-data.net/issues/1532  and is documented in http://redmine.named-data.net/projects/ndn-cxx/wiki/KeyChainConf

---
Alex




We need to consider how to handle this specification in the NDN-CCL libraries, and would prefer to work from a design specification rather than existing code in ndn-cxx.   For code like ndn-js, it may not always apply, so we need to understand defaults and assumptions, too.

Please see:
http://redmine.named-data.net/issues/1850

Thanks,
Jeff

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140818/44de8a96/attachment.html>