Project

General

Profile

CommandValidatorConf » History » Version 52

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