blob: 8459594bda081b2d7b61c34f7a863684c0277ded [file] [log] [blame]
Zhiyi Zhangdaf2fd72017-01-19 11:31:35 -08001; The namespace that the NDN Certificate Authority will serve.
2name "/ndn/edu/ucla/cs/zhiyi"
3
4; This section configures parameter(s) of the issued certificates.
5certificate-info
6{
7 ; freshness-period defines the freshness period of newly issued certificates.
8 freshness-period 720
9}
10
11; This ca-anchor section configures the CA certificate.
12;
13; The type defines the type of certificate. Now NDNCERT supports two types:
14;
15; file; value should be the file name of the certificate file
16; base64; value should be the Base64 encoded plain text of NDN certificate bytes
17;
18ca-anchor
19{
20 type file
21 value "ca.ndncert.test"
22}
23
24; This challenge-list section defines a list of all available challenge types.
25;
26; It includes one or more challenge. For every challenge, the type should be
27; the unique type identifier of the registered Challenge Module.
28;
29challenge-list
30{
31 challenge
32 {
33 type pin
34 }
35}
36
37;
38validator-conf
39{
40 ; This section defines the trust model for NDNCERT CaModule validator. It consists of rules
41 ; and trust-anchors, which are briefly defined in this file. For more information refer to
42 ; manpage of ndn-validator.conf:
43 ;
44 ; man ndn-validator.conf
45 ;
46 ; A trust-anchor is a pre-trusted certificate. This can be any certificate that is the root
47 ; of certification chain (e.g., NDN testbed root certificate) or an existing default system
48 ; certificate `default.ndncert`. A rule defines conditions a valid packet MUST have. A
49 ; packet must satisfy one of the rules defined here. A rule can be broken into two parts:
50 ; matching & checking. A packet will be matched against rules from the first to the last
51 ; until a matched rule is encountered. The matched rule will be used to check the packet. If
52 ; a packet does not match any rule, it will be treated as invalid. The matching part of a
53 ; rule consists of `for` and `filter` sections. They collectively define which packets can be
54 ; checked with this rule. `for` defines packet type (data or interest) and `filter` defines
55 ; conditions on other properties of a packet. Right now, you can only define conditions on
56 ; packet name, and you can only specify ONLY ONE filter for packet name. The checking part
57 ; of a rule consists of `checker`, which defines the conditions that a VALID packet MUST
58 ; have. See comments in checker section for more details.
59 rule
60 {
61 id "zhiyi interest rule"
62 for interest
63 filter
64 {
65 type name
66 regex ^<ndn><edu><ucla><cs><zhiyi>[<_NEW><_POLL>]<>*$
67 }
68 trust-anchor
69 {
70 type any
71 }
72 }
73}