Validator Configuration File Format¶

You can set up a Validator via a configuration file.
Next, we will show you how to write a configuration file.

The configuration file consists of rules that will be used in validation.
Here is an example of configuration file containing two rules.

rule
{
  for data
  name "Simple Rule"
  type customized
  target
  {
    type name
    name "/localhost/example"
    relation isPrefixOf
  }
  signer
  {
    type name
    name "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT"
    relation equal
  }
}
rule
{
  for data
  name "Testbed Validation Rule"
  type hierarchical
  trust-anchor
  {
    type file
    file-name "testbed-trust-anchor.cert"
  }
}

Each rule has a unique name (which should be unique in the configuration file), e.g., "Simple Rule", "Testbed Validation Rule".
The rule name is specified in the property name.
Each rule must be specified with a usage which is specified in the property for.
The usage indicates the type of packets to which the rule should be applied, therefore, only two usages can be specified so far: data and interest.
The property type indicates how to apply the rule to packets.
Some rule types (such as hierarchical) has been defined.
One can also specify its own rules by set the type property to be customized.
A particular type of rules might require some other properties.
Next, we will introduce the other properties for the each rule type.

Customized Rule¶

Two properties are required by customized rule: target and signer.
And some optional properties may be configured if necessary.

Target Property¶

The target property defines the conditions that the packet per se must satisfy,
thus restricting the scope of packets to which the rule can be applied.

A packet will be checked against the target property of rules in the configuration file,
one-by-one until the first rule whose target property can be satisfied by the packet.
Once the packet is caught by a rule, no other rules will be applied to the packet.
Therefore, the order of rules in configuration file MATTERS!
If the packet cannot satisfy none of the rules, it will be treated as unvalidated packet.

The target also has a property type which indicates the condition type.
Two possible types are supported so far: name and regex.

If type is name, then the target has two more properties: name and relation.
A packet can satisfy the condition if the name and the packet name can establish the relation.
The value of relation could be either isPrefixOf or equal.
For example, a target:

target
{
  type name
  name "/localhost/example"
  relation isPrefixOf
}

can catch a packet with name "/localhost/example/data" but cannot catch a packet with name "/localhost/another_example".

And a target

target
{
  type name
  name "/localhost/example"
  relation equal
}

can only catch a packet with the exact name "/localhost/example".

If type is regex, then target must have a property expr and an optional property expand.
expr is an NDN regular expression.
A packet can satisfy the target only if the regex can match the packet name.
If the regex contains back references, then the expand property can be specified to extract certain pattern out of the packet name.
For example, a target

target
{
  type regex
  expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$"
  expand "\\1\\2"
}

can catch all the identity certificates and extract the corresponding namespace of the certificate.

Signer Property¶

The signer property defines the conditions that the signer (or KeyLocator) must fulfill.

Hierarchical Rule¶

As implied by its name, hierarchical rule requires the name of the target packet to be under the namespace of the packet signer.
Assume that the usage of the rule is for data, then it is equivalent to a customized rule:

rule
{
  for data
  name "Expanded Hierarchical Rule"
  type customized
  target
  {
    type regex
    expr "^(<>*)$"
    expand "\\1"
  }
  signer
  {
    type regex
    expr "^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$"
    expand "\\1\\2"
  }
  relation isPrefixOf
}