NFD

Glancing through the code, it seems that this is a major change on NFD's side. Correct me if I'm wrong, but I think this requires completely changing the authorizations section of the configuration file and re-writing how NFD validates things.

NFD's CommandValidator currently handles the authorizations section parsing and interacts with the (deprecated) CommandInterestValidator through a simple addInterestRule API that allows it to associate privileges with identities. However, ValidatorConfig provides no such API and only supports loading what appears to be be a full configuration file at a time.

We might also lose the ability to detect invalid config file privileges. Currently managers use CommandValidator::addSupportedPrivilege to inform the CommandValidator::onConfig of what strings are valid privileges.

My thinking is:

1. re-write authorizations section as something ValidatorConfig expects (not sure of what this means at the moment)
2. Removing parsing code from CommandValidator::onConfig in favor of invoking `Validator::load
3. Various re-workings/cleanup (this probably touches a lot)

Is this an accurate assessment?

I will be against using ValidatorConfig for validation of fib, faces, and strategy-choice (unless somebody can prove that it is needed).

However, there is another method that doesn't require CommandValidator. Yingdi can correct me, but I believe ValidatorRegex may have exactly the same functionality. If not, then we simply would keep CommandValidator, but we'll need to rename it to something like "ValidatorSimple" or something.

My idea is:

Relive ndn::security::CommandInterestValidator from https://gerrit.named-data.net/2035, but as a subclass of Validator.

Similar to nfd::tools::nfd_status::NfdIdCollector, it would be a Validator that chains up to an inner validator.
It delegates trust model validation to the inner validator, but checks the uniqueness and sequence of timestamps.

Unlike abandoned Change 2035, ndn::security::CommandInterestValidator is not restricted to use with ValidatorConfig, and ValidatorConfig will not be weakened.

Then, nfd::CommandValidator class is replaced with an CommandAuthenticator class.
This class will not have Validator API. Instead, it has a method to return a ndn::mgmt::Authorization function for each ControlCommand which does the following:

1. Based on management module and command verb, find out what signing certificates are allowed.
2. Check whether the Interest is signed by one of these certificates. If not, reject.
3. Pass the Interest to the ndn::security::CommandInterestValidator (shared among all ndn::mgmt::Authorization functions). If timestamp is bad, reject.
4. Finally, verify the signature with Validator::verifySignature static method.

The benefit of this design is that it takes advantage of the management module and command verb information that is already known from the ndn::mgmt::Dispatcher, because every Dispatcher::addControlCommand can have a distinct ndn::mgmt::Authorization callback, so that those information can kept with std::bind.

The inner validator when constructing ndn::security::CommandInterestValidator is simply a ValidatorNull.

Can you mention what is the typo, so I can fix it?

what is the typo?

Authorzation => Authorization
ParametersValidate => ValidateParameters
StatusDataset should not have Authorization, or it cannot reject