nrd.conf.sample

security
{
  ; Security section defines the trust model that NRD should use. It consists of rules and
  ; trust-anchors, which are briefly defined in this file. For more details please see the
  ; following wiki:
  ; http://redmine.named-data.net/projects/ndn-cpp-dev/wiki/CommandValidatorConf
  ;
  ; A trust-anchor is a pre-trusted certificate. It is usually stored in a file in the
  ; same directory as this config file. You can download the NDN testbed root certificate as the
  ; trust anchor, or you can dump an existing certificate from your system as a trust anchor:
  ;   $ ndnsec cert-dump /example/certificate/name > trust-anchor.cert
  ; or you can generate a self-signed certificate as a trust anchor:
  ;   $ ndnsec key-gen /example/identity/name > trust-anchor.cert
  ; See comments in trust-anchor section for configuration details.
  ;
  ; A rule defines conditions a valid packet MUST have. A packet must satisfy one of the rules defined
  ; here. A rule can be broken into two parts: matching & checking. A packet will be matched against
  ; rules from the first to the last until a matched rule is encountered. The matched rule will be
  ; used to check the packet. If a packet does not match any rule, it will be treated as invalid.
  ; The matching part of a rule consists of `for` and `filter` sections. They collectively define
  ; which packets can be checked with this rule. `for` defines packet type (data or interest),
  ; while `filter` defines conditions on other properties of a packet. Right now, you can only
  ; define conditions on packet name, and you can only specify ONLY ONE filter for packet name.
  ; The checking part of a rule consists of `checker`, which defines the conditions that a VALID
  ; packet MUST have. See comments in checker section for more details.

  rule
  {
    id "NRD Prefix Registration Command Rule" ; rule id
    for interest                              ; this rule is used to validate interests
    filter
    {
      type name                               ; condition on interest name (w/o signature)
      regex ^[<localhop><localhost>]<nrd>[<register><unregister>]<>{3}$
    }
    checker
    {
      type customized
      sig-type rsa-sha256                     ; interest must have a rsa-sha256 signature
      key-locator
      {
        type name                             ; key locator must be the certificate name of
                                              ; the signing key
        regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
      }
    }
  }
  rule
  {
    id "Testbed Hierarchy Rule"               ; rule id
    for data                                  ; this rule is used to validate data
    filter
    {
      type name                               ; condition on data name
      regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT><>$
    }
    checker
    {
      type hierarchical                       ; the certificate name of the signing key and
                                              ; the data name must follow the hierarchical model
      sig-type rsa-sha256                     ; data must have a rsa-sha256 signature
    }
  }
  trust-anchor
  {
    type file                     ; trust anchor is stored in a file
    file-name "trust-anchor.cert" ; the file name, by default this file should be placed in the
                                  ; same folder as this config file.
  }
}