Add CaConfig to support CA configuration
Change-Id: I3095b4c8fbe70c2f5b8e27722c0e85d1ec801aba
diff --git a/tests/unit-tests/ca.conf.test b/tests/unit-tests/ca.conf.test
new file mode 100644
index 0000000..8459594
--- /dev/null
+++ b/tests/unit-tests/ca.conf.test
@@ -0,0 +1,73 @@
+; The namespace that the NDN Certificate Authority will serve.
+name "/ndn/edu/ucla/cs/zhiyi"
+
+; This section configures parameter(s) of the issued certificates.
+certificate-info
+{
+ ; freshness-period defines the freshness period of newly issued certificates.
+ freshness-period 720
+}
+
+; This ca-anchor section configures the CA certificate.
+;
+; The type defines the type of certificate. Now NDNCERT supports two types:
+;
+; file; value should be the file name of the certificate file
+; base64; value should be the Base64 encoded plain text of NDN certificate bytes
+;
+ca-anchor
+{
+ type file
+ value "ca.ndncert.test"
+}
+
+; This challenge-list section defines a list of all available challenge types.
+;
+; It includes one or more challenge. For every challenge, the type should be
+; the unique type identifier of the registered Challenge Module.
+;
+challenge-list
+{
+ challenge
+ {
+ type pin
+ }
+}
+
+;
+validator-conf
+{
+ ; This section defines the trust model for NDNCERT CaModule validator. It consists of rules
+ ; and trust-anchors, which are briefly defined in this file. For more information refer to
+ ; manpage of ndn-validator.conf:
+ ;
+ ; man ndn-validator.conf
+ ;
+ ; A trust-anchor is a pre-trusted certificate. This can be any certificate that is the root
+ ; of certification chain (e.g., NDN testbed root certificate) or an existing default system
+ ; certificate `default.ndncert`. 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) and `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 "zhiyi interest rule"
+ for interest
+ filter
+ {
+ type name
+ regex ^<ndn><edu><ucla><cs><zhiyi>[<_NEW><_POLL>]<>*$
+ }
+ trust-anchor
+ {
+ type any
+ }
+ }
+}