Zhiyi Zhang | daf2fd7 | 2017-01-19 11:31:35 -0800 | [diff] [blame] | 1 | ; The namespace that the NDN Certificate Authority will serve. |
| 2 | name "/ndn/edu/ucla/cs/zhiyi" |
| 3 | |
| 4 | ; This section configures parameter(s) of the issued certificates. |
| 5 | certificate-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 | ; |
| 18 | ca-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 | ; |
| 29 | challenge-list |
| 30 | { |
| 31 | challenge |
| 32 | { |
| 33 | type pin |
| 34 | } |
| 35 | } |
| 36 | |
| 37 | ; |
| 38 | validator-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 | } |