Project

General

Profile

CommandValidatorConf » History » Version 51

Yingdi Yu, 06/13/2014 11:06 AM

1 3 Yingdi Yu
# Validator Configuration File Format
2 1 Yingdi Yu
3 3 Yingdi Yu
You can set up a `Validator` via a configuration file. 
4
Next, we will show you how to write a configuration file.
5 1 Yingdi Yu
6 32 Yingdi Yu
The configuration file consists of **rules** and **trust-anchors** that will be used in validation.
7
**Rules** tell the validator how to validate a packet, while **trust-anchors** tell the validator which certificates are valid immediately.
8 4 Yingdi Yu
Here is an example of configuration file containing two rules.
9 3 Yingdi Yu
10
    rule
11 1 Yingdi Yu
    {
12 9 Yingdi Yu
      id "Simple Rule"
13 3 Yingdi Yu
      for data
14 9 Yingdi Yu
      filter
15 3 Yingdi Yu
      {
16 6 Yingdi Yu
        type name
17 22 Yingdi Yu
        name /localhost/example
18 48 Yingdi Yu
        relation is-prefix-of
19 3 Yingdi Yu
      }
20 26 Yingdi Yu
      checker
21 1 Yingdi Yu
      {
22 27 Yingdi Yu
        type customized
23 14 Yingdi Yu
        sig-type rsa-sha256
24
        key-locator
25
        {
26
          type name
27 22 Yingdi Yu
          name /ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT
28 14 Yingdi Yu
          relation equal
29
        }
30 6 Yingdi Yu
      }
31 1 Yingdi Yu
    }
32
    rule
33
    {
34 9 Yingdi Yu
      id "Testbed Validation Rule"
35 1 Yingdi Yu
      for data
36
      checker
37 27 Yingdi Yu
      {
38 1 Yingdi Yu
        type hierarchical
39
        sig-type rsa-sha256
40
      }
41 27 Yingdi Yu
    }
42 32 Yingdi Yu
    trust-anchor
43
    {
44
      type file
45
      file-name "testbed-trust-anchor.cert"
46
    }
47 1 Yingdi Yu
48 29 Yingdi Yu
* <font color='red'>**ATTENTION: The order of rules MATTERS!**</font>
49 10 Yingdi Yu
50 1 Yingdi Yu
A rule can be broken into two parts: 
51
52 9 Yingdi Yu
* The first part is to qualify packets to which the rule can be applied;
53 27 Yingdi Yu
* The second part is to check whether further validation process is necessary.
54 1 Yingdi Yu
55 27 Yingdi Yu
When receiving a packet, the validator will apply rules in the configuration file one-by-one against the packet,
56
until finding a rule that the packet qualifies for.
57
And the second part of the matched rule will be used to check the validity of the packet.
58 1 Yingdi Yu
If the packet cannot qualify for any rules, it is treated as an invalid packet.
59
Once a packet has been matched by a rule, the rest rules will not be applied against the packet.
60 27 Yingdi Yu
Therefore, you should always put the most specific rule to the top, otherwise it will become useless.
61 1 Yingdi Yu
62
In the example configuration,
63
the first rule indicates that all the data packets under the name prefix "/localhost/example" must be signed by a key whose certificate name is "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT".
64
If a packet does not have a name under prefix "/localhost/example", validator will skip the first rule and apply the second rule.
65 32 Yingdi Yu
The second rule indicates that any data packets must be validated along a hierarchy. 
66
And a certificate stored in a file "testbed-trust-anchor.cert" is valid.
67 27 Yingdi Yu
68 11 Yingdi Yu
## Rules in general
69 1 Yingdi Yu
70 29 Yingdi Yu
A rule has four types of properties: **id**, **for**, **filter**, and **checker**.
71 1 Yingdi Yu
72 27 Yingdi Yu
The property **id** uniquely identifies the rule in the configuration file.
73 11 Yingdi Yu
As long as being unique, any name can be given to a rule, e.g., "Simple Rule", "Testbed Validation Rule".
74 29 Yingdi Yu
A rule must have one and only one **id** property.
75 1 Yingdi Yu
76 27 Yingdi Yu
A rule is either used to validate an interest packet or a data packet. 
77 1 Yingdi Yu
This information is specified in the property **for**.
78
Only two value can be specified: **data** and **interest**.
79 29 Yingdi Yu
A rule must have one and only one **for** property.
80 1 Yingdi Yu
81 51 Yingdi Yu
* <font color='red'>**ATTENTION: For [signed interest](http://redmine.named-data.net/projects/nfd/wiki/Signed_Interests), rules should cover the prefix before the ``timestamp``**</font>.
82
83 1 Yingdi Yu
The property **filter** further constrains the packets that can be checked by the rule.
84 29 Yingdi Yu
Filter property is not required in a rule, in this case, the rule will capture all the packets passed to it.
85
A rule may contain more than one filters, in this case, a packet can be checked by a rule only if the packet satisfies all the filters.
86 27 Yingdi Yu
87 29 Yingdi Yu
* <font color='red'>**ATTENTION: A packet that satisfies all the filters may not be valid**</font>.
88 1 Yingdi Yu
89 29 Yingdi Yu
The property **checker** defines the conditions that a matched packet must fulfill to be treated as a valid packet.
90 44 Yingdi Yu
A rule must have at least one **checker** property, a packet is treated as invalid if it cannot pass none of the checkers.
91 29 Yingdi Yu
92 27 Yingdi Yu
**filter** and **checker** have their own properties.
93 29 Yingdi Yu
Next, we will introduce them separately.
94 12 Yingdi Yu
95 27 Yingdi Yu
## Filter Property
96 12 Yingdi Yu
97 29 Yingdi Yu
Filter has its own **type** property.
98 13 Yingdi Yu
Although a rule may contain more than one filters, there is at most one filter of each type.
99 29 Yingdi Yu
So far, only one type of filter is defined: **name**.
100 27 Yingdi Yu
In other word, only one filter can be specified in a rule for now.
101 1 Yingdi Yu
102 28 Yingdi Yu
### Name Filter
103
104 27 Yingdi Yu
There are two ways to express the conditions on name. 
105 21 Yingdi Yu
The first way is to specify a relationship between the packet name and a particular name.
106 7 Yingdi Yu
In this case, two more properties are required: **name** and **relation**.
107 27 Yingdi Yu
A packet can fulfill the condition if the **name** has a **relation* to the packet name.
108 48 Yingdi Yu
Three types of **relation** has been defined: **equal**, **is-prefix-of**, **is-strict-prefix-of**. 
109 1 Yingdi Yu
For example, a filter 
110 22 Yingdi Yu
111 21 Yingdi Yu
    filter
112 1 Yingdi Yu
    {
113
      type name
114
      name /localhost/example
115
      relation equal
116
    }
117 21 Yingdi Yu
118 27 Yingdi Yu
shall only capture a packet with the exact name "/localhost/example".
119 21 Yingdi Yu
And a filter
120 22 Yingdi Yu
121 21 Yingdi Yu
    filter
122
    {
123 1 Yingdi Yu
      type name
124 21 Yingdi Yu
      name /localhost/example
125 48 Yingdi Yu
      relation is-prefix-of
126 21 Yingdi Yu
    }
127 1 Yingdi Yu
128 27 Yingdi Yu
shall capture a packet with name "/localhost/example" or "/localhost/example/data", but cannot catch a packet with name "/localhost/another_example".
129 1 Yingdi Yu
And a filter
130 22 Yingdi Yu
131 21 Yingdi Yu
    filter
132 8 Yingdi Yu
    {
133 7 Yingdi Yu
      type name
134 21 Yingdi Yu
      name /localhost/example
135 48 Yingdi Yu
      relation is-strict-prefix-of
136 21 Yingdi Yu
    }
137 7 Yingdi Yu
138 27 Yingdi Yu
shall capture a packet with name "/localhost/example/data", but cannot catch a packet with name "/localhost/example".
139 1 Yingdi Yu
140
The second way is to specify an [[Regex|NDN Regular Expression]] that can match the packet.
141
In this case, only one property **regex** is required.
142
For example, a filter 
143
144
    filter
145
    {
146
      type name
147
      regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
148
    }
149
150
shall capture all the identity certificates. 
151
152
## Checker Property
153
154 29 Yingdi Yu
Passing all the filters in a rule only indicates that a packet can be checked using the rule, 
155
and it does not necessarily implies that the packet is valid.
156 1 Yingdi Yu
The validity of a packet is determined by the property **checker**, which defines the conditions that a valid packet must fulfill.
157
158 29 Yingdi Yu
Same as **filter**, **checker** has a property **type**.
159 37 Yingdi Yu
We have defined three types of checkers: **customized**, and **hierarchical**, and **fixed-signer**.
160 29 Yingdi Yu
As suggested by its name, **customized** checker allows you to customize the conditions according to specific requirements.
161 37 Yingdi Yu
**hierarchical** checker and **fixed-signer** checker are pre-defined shortcuts, which specify specific trust models separately.
162 1 Yingdi Yu
163 29 Yingdi Yu
### Customized Checker
164
165 32 Yingdi Yu
So far, we only allow three customized properties in a customized checker: **sig-type**, **key-locator**.
166 29 Yingdi Yu
All of them are related to the `SignatureInfo` of a packet. 
167
168 1 Yingdi Yu
    checker
169 29 Yingdi Yu
    {
170
      type customized
171
      sig-type ...
172
      key-locator
173
      {
174
        ...
175
      }
176
    }
177
178
The property **sig-type** specifies the acceptable signature type.
179
Right now two signature types have been defined: **rsa-sha256** (which is a strong signature type) and **sha256** (which is a weak signature type).
180 32 Yingdi Yu
If sig-type is sha256, then **key-locator** will be ignored.
181 29 Yingdi Yu
Validator will simply calculate the digest of a packet and compare it with the one in `SignatureValue`.
182 32 Yingdi Yu
If sig-type is rsa-sha256, you have to further customize the checker with **key-locator**.
183 29 Yingdi Yu
184
The property **key-locator** which specifies the conditions on `KeyLocator`.
185
If the **key-locator** property is specified, it requires the existence of the `KeyLocator` field in `SignatureInfo`.
186
Although there are more than one types of `KeyLocator` defined in the [Packet Format](http://named-data.net/doc/ndn-tlv/signature.html), 
187
**key-locator** property only supports one type: **name**:
188
189
    key-locator
190
    {
191
      type name
192
      ...
193
    }
194
195
Such a key-locator property specifies the conditions on the certificate name of the signing key.
196
Since the conditions are about name, they can be specified in the same way as the name filter.
197 1 Yingdi Yu
For example, a checker could be:
198
199
    checker
200 21 Yingdi Yu
    {
201 29 Yingdi Yu
      type customized
202 21 Yingdi Yu
      sig-type rsa-sha256
203
      key-locator
204
      {
205
        type name
206 1 Yingdi Yu
        name /ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT
207
        relation equal
208
      }
209 15 Yingdi Yu
    }
210
211
This checker property requires that the packet must have a rsa-sha256 signature generated by a key whose certificate name is "/ndn/edu/ucla/KEY/yingdi/ksk-1234/ID-CERT".
212 1 Yingdi Yu
213 29 Yingdi Yu
Besides the two ways to express conditions on the `KeyLocator` name (name and regex), 
214
you can further constrain the `KeyLocator` name using the information extracted from the packet name.
215 15 Yingdi Yu
This third type of condition is expressed via a property **hyper-relation**.
216 21 Yingdi Yu
The **hyper-relation** property consists of three parts:
217 1 Yingdi Yu
218 21 Yingdi Yu
* an NDN regular expression that can extract information from packet name
219 29 Yingdi Yu
* an NDN regular expression that can extract information from `KeyLocator` name
220
* relation from the part extracted from `KeyLocator` name to the one extracted from the packet name
221 22 Yingdi Yu
222
For example, a checker:
223 21 Yingdi Yu
224
    checker
225 1 Yingdi Yu
    {
226 29 Yingdi Yu
      type customized
227 15 Yingdi Yu
      sig-type rsa-sha256
228 6 Yingdi Yu
      key-locator
229 1 Yingdi Yu
      {
230
        type name
231
        hyper-relation
232
        {
233
          k-regex ^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$
234 41 Yingdi Yu
          k-expand \\1\\2
235 48 Yingdi Yu
          h-relation is-prefix-of
236 29 Yingdi Yu
          p-regex ^(<>*)$
237 41 Yingdi Yu
          p-expand \\1
238 29 Yingdi Yu
239 1 Yingdi Yu
        }
240
      }
241
    }
242
243 29 Yingdi Yu
requires the packet name must be under the corresponding namespace of the `KeyLocator` name.
244 1 Yingdi Yu
245 32 Yingdi Yu
In some cases, you can even customize checker with another property 
246 29 Yingdi Yu
For example:
247 1 Yingdi Yu
248
    checker
249
    {
250 29 Yingdi Yu
      type customized
251 1 Yingdi Yu
      sig-type rsa-sha256
252
      key-locator
253
      {
254 29 Yingdi Yu
        type name
255 1 Yingdi Yu
        hyper-relation
256
        {
257
          k-regex ^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$
258 41 Yingdi Yu
          k-expand \\1\\2
259 48 Yingdi Yu
          h-relation is-prefix-of
260 1 Yingdi Yu
          p-regex ^(<>*)$
261 41 Yingdi Yu
          p-expand \\1
262 1 Yingdi Yu
        }
263 29 Yingdi Yu
      }
264
    }
265 16 Yingdi Yu
266 29 Yingdi Yu
### Hierarchical Checker
267
268
As implied by its name, hierarchical checker requires that the packet name must be under the namespace of the packet signer.
269 32 Yingdi Yu
A hierarchical checker:
270 29 Yingdi Yu
271 37 Yingdi Yu
    checker
272 29 Yingdi Yu
    {
273
      type hierarchical
274
      sig-type rsa-sha256
275
    }
276 1 Yingdi Yu
277 32 Yingdi Yu
is equivalent to a customized checker:
278 1 Yingdi Yu
279 29 Yingdi Yu
    checker
280 1 Yingdi Yu
    {
281 26 Yingdi Yu
      type customized
282 29 Yingdi Yu
      sig-type rsa-sha256
283
      key-locator
284 1 Yingdi Yu
      {
285 21 Yingdi Yu
        type name
286 29 Yingdi Yu
        hyper-relation
287 22 Yingdi Yu
        {
288 29 Yingdi Yu
          k-regex ^([^<KEY>]*)<KEY>(<>*)<ksk-.*><ID-CERT>$
289 42 Yingdi Yu
          k-expand \\1\\2
290 48 Yingdi Yu
          h-relation is-prefix-of
291 29 Yingdi Yu
          p-regex ^(<>*)$
292 42 Yingdi Yu
          p-expand \\1
293 29 Yingdi Yu
        }
294 33 Yingdi Yu
      }
295 29 Yingdi Yu
    }
296
297 37 Yingdi Yu
### Fixed-Signer Checker
298 29 Yingdi Yu
299
In some cases, you only accept packets signed with pre-trusted certificates, i.e. "one-step validation".
300 37 Yingdi Yu
Such a trust model can be expressed with **fixed-signer** checker.
301 39 Yingdi Yu
And you only need to specify the trusted certificate via property **signer**. 
302
The definition of **signer** is the same as **trust-anchor**.
303 29 Yingdi Yu
For example:
304
305 36 Yingdi Yu
    checker
306 29 Yingdi Yu
    {
307 1 Yingdi Yu
      type fixed-signer
308
      sig-type rsa-sha256
309 39 Yingdi Yu
      signer
310
      {
311
        type file
312
        file-name "trusted-signer.cert"
313
      }
314
      signer
315
      {
316 40 Yingdi Yu
        type base64
317
        base64-string "Bv0DGwdG...amHFvHIMDw=="
318 39 Yingdi Yu
      }
319 29 Yingdi Yu
    }
320
321 32 Yingdi Yu
## Trust Anchors
322
323 45 Yingdi Yu
Although **trust-anchor** is always not required in the configuration file (for example, if fixed-signer checker is used), 
324
it is very common to have a few trust-anchors in the configuration file, otherwise most packets cannot be validated.
325 1 Yingdi Yu
A configuration file may contain more than one trust anchors, but the order of trust anchors does not matter.
326 45 Yingdi Yu
The structure of trust-anchor is same as the **signer** in fixed-signer checker, for example:
327
328
    trust-anchor
329
    {
330
      type file
331
      file-name "trusted-signer.cert"
332
    }
333
    trust-anchor
334
    {
335
      type base64
336
      base64-string "Bv0DGwdG...amHFvHIMDw=="
337
    }
338 32 Yingdi Yu
339 50 Yingdi Yu
You may also specify a trust anchor directory as following:
340
341
    trust-anchor
342
    {
343
      type dir
344
      dir /usr/local/ndn/keys
345
    }
346
347
Validator will load every file as a trust anchor from the directory.
348
If the content in the directory will change during the runtime, 
349
you can specify **refresh** property to ask Validator to periodically reload trust anchors. 
350
For example:
351
352
    trust-anchor
353
    {
354
      type dir
355
      dir /usr/local/ndn/keys
356
      refresh 1h
357
    }
358
359
indicates that validator should reload trust anchors from this directory every hour.
360
There three options of time units: `h` for hour, `m` for minutes, and `s` for seconds.
361
If the refresh period is set to `0`, then the default refresh period (`1h`) will be used.
362
If the refresh property is not specified, then trust anchors will be loaded for only one time.
363
364 49 Yingdi Yu
There is another special trust anchor **any**.
365
As long as such a trust-anchor is defined in config file, packet validation will be turned off.
366
367
<font color=red>**ATTENTION!! Such a type of trust anchor is dangerous. 
368
You should used it only when you want to disable packet validation temporarily (e.g, debugging code, building a demo).**</font>
369
370
    trust-anchor
371
    {
372
      type any
373
    }
374
375 21 Yingdi Yu
## Example Configuration For NLSR
376 25 Yingdi Yu
377 24 Yingdi Yu
The trust model of NLSR is semi-hierarchical.
378 17 Yingdi Yu
An example certificate signing hierarchy is:
379 1 Yingdi Yu
    
380 17 Yingdi Yu
                                            root 
381
                                             |  	    
382
                              +--------------+---------------+
383
                            site1                          site2
384
                              |                              |		   
385 1 Yingdi Yu
                    +---------+---------+                    +
386
                 operator1           operator2            operator3
387
                    |                   |                    | 
388
              +-----+-----+        +----+-----+        +-----+-----+--------+
389
           router1     router2  router3    router4  router5     router6  router7
390
              |           |        |          |        |           |        |
391 22 Yingdi Yu
              +           +        +          +        +           +        +  	      
392 17 Yingdi Yu
            NLSR        NSLR     NSLR       NSLR     NSLR        NSLR     NSLR
393 1 Yingdi Yu
394
However, entities name may not follow the signing hierarchy, for example:
395 17 Yingdi Yu
396
Entity   | Identity Name                                     | Example                         | Certificate Name Example
397
-------- | ------------------------------------------------- | ------------------------------- | ------------------------------------------------
398
root     | /\<network\>                                      | /ndn                            | /ndn/KEY/ksk-1/ID-CERT/%01
399 22 Yingdi Yu
site     | /\<network\>/\<site\>                             | /ndn/edu/ucla                   | /ndn/edu/ucla/KEY/ksk-2/ID-CERT/%01
400 17 Yingdi Yu
operator | /\<network\>/\<site\>/%C1.O.N./\<operator-id\>    | /ndn/edu/ucla/%C1.O.N./op1      | /ndn/edu/ucla/%C1.O.N./op1/KEY/ksk-3/ID-CERT/%01
401 26 Yingdi Yu
router   | /\<network\>/\<site\>/%C1.O.R./\<router-id\>      | /ndn/edu/ucla/%C1.O.R./rt1      | /ndn/edu/ucla/%C1.O.R./rt1/KEY/ksk-4/ID-CERT/%01
402 17 Yingdi Yu
NLSR     | /\<network\>/\<site\>/%C1.O.R./\<router-id\>/NLSR | /ndn/edu/ucla/%C1.O.R./rt1/NLSR | /ndn/edu/ucla/%C1.O.R./rt1/NLSR/KEY/ksk-5/ID-CERT/%01
403 1 Yingdi Yu
404 17 Yingdi Yu
405 1 Yingdi Yu
Assume that a typical NLSR data name is "/ndn/edu/ucla/%C1.O.R./rt1/NLSR/LSA/LSType.1/%01".
406
Then, the exception of naming hierarchy is "operator-router".
407
So we can write a configuration file with three rules.
408
The first one is a customized rule that capture the normal NLSR data.
409
The second one is a customized rule that handles the exception case of the hierarchy (operator->router).
410
And the last one is a hierarchical rule that handles the normal cases of the hierarchy.
411
412
We put the NLSR data rule to the first place, because NLSR data packets are the most frequently checked.
413 17 Yingdi Yu
The hierarchical exception rule is put to the second, because it is more specific than the last one.
414 22 Yingdi Yu
415
And here is the configuration file:
416
417
    rule
418
    {
419
      id "NSLR LSA Rule"
420
      for data
421
      filter
422 17 Yingdi Yu
      {
423
        type name
424
        regex ^[^<NLSR><LSA>]*<NLSR><LSA>
425
      }
426
      checker
427
      {
428 29 Yingdi Yu
        type customized
429 17 Yingdi Yu
        sig-type rsa-sha256
430
        key-locator
431
        {
432
          type name
433 23 Yingdi Yu
          hyper-relation
434 17 Yingdi Yu
          {
435 1 Yingdi Yu
            k-regex ^([^<KEY>]*)<KEY><ksk-.*><ID-CERT>$
436 43 Yingdi Yu
            k-expand \\1
437 1 Yingdi Yu
            h-relation equal
438 29 Yingdi Yu
            p-regex ^([^<NLSR><LSA>]*)<NLSR><LSA><LSType\.\d><>$
439 43 Yingdi Yu
            p-expand \\1
440 17 Yingdi Yu
          }
441 22 Yingdi Yu
        }
442
      }
443
    }
444
    rule
445
    {
446
      id "NSLR Hierarchy Exception Rule"
447
      for data
448
      filter
449 17 Yingdi Yu
      {
450
        type name
451
        regex ^[^<KEY><%C1.O.R.>]*<%C1.O.R.><><KEY><ksk-.*><ID-CERT><>$
452
      }
453
      checker
454
      {
455 29 Yingdi Yu
        type customized
456 17 Yingdi Yu
        sig-type rsa-sha256
457
        key-locator
458
        {
459 19 Yingdi Yu
          type name
460 1 Yingdi Yu
          hyper-relation
461 18 Yingdi Yu
          {
462 1 Yingdi Yu
            k-regex ^([^<KEY><%C1.O.N.>]*)<%C1.O.N.><><KEY><ksk-.*><ID-CERT>$
463 43 Yingdi Yu
            k-expand \\1
464 35 Yingdi Yu
            h-relation equal
465 29 Yingdi Yu
            p-regex ^([^<KEY><%C1.O.R.>]*)<%C1.O.R.><><KEY><ksk-.*><ID-CERT><>$
466 43 Yingdi Yu
            p-expand \\1
467 1 Yingdi Yu
          }
468
        }
469
      }
470
    }
471
    rule
472
    {
473
      id "NSLR Hierarchical Rule"
474
      for data
475 30 Yingdi Yu
      filter
476 1 Yingdi Yu
      {
477
        type name
478 46 Yingdi Yu
        regex ^[^<KEY>]*<KEY><ksk-.*><ID-CERT><>$
479
      }
480
      checker
481
      {
482
        type hierarchical
483
        sig-type rsa-sha256
484
      }
485
    }
486
    trust-anchor
487
    {
488
      type file
489
      file-name "testbed-trust-anchor.cert"
490
    }
491
492
## Example Configuration For NRD
493
494
Assume NRD allows any valid testbed certificate to register prefix, the configuration file could be written as:
495
496
    rule
497
    {
498
      id "NRD Prefix Registration Command Rule"
499
      for interest
500
      filter
501
      {
502
        type name
503
        regex ^<localhost><nrd>[<register><unregister><advertise><withdraw>]
504
      }
505
      checker
506
      {
507
        type customized
508
        sig-type rsa-sha256
509
        key-locator
510
        {
511
          type name
512 47 Yingdi Yu
          regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
513 46 Yingdi Yu
        }
514
      }
515
    }
516
    rule
517
    {
518
      id "Testbed Hierarchy Rule"
519
      for data
520
      filter
521
      {
522
        type name
523
        regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT><>$
524 1 Yingdi Yu
      }
525 29 Yingdi Yu
      checker
526 1 Yingdi Yu
      {
527 29 Yingdi Yu
        type hierarchical
528 1 Yingdi Yu
        sig-type rsa-sha256
529
      }
530 33 Yingdi Yu
    }
531
    trust-anchor
532
    {
533
      type file
534
      file-name "testbed-trust-anchor.cert"
535 1 Yingdi Yu
    }