idnits 2.17.1 draft-petithuguenin-p2psip-access-control-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 31, 2011) is 4532 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 457 -- Looks like a reference, but probably isn't: '17' on line 457 -- Looks like a reference, but probably isn't: '1' on line 507 -- Looks like a reference, but probably isn't: '2' on line 506 -- Looks like a reference, but probably isn't: '0' on line 507 ** Downref: Normative reference to an Informational RFC: RFC 1952 == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-19 -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMA-262' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-15) exists of draft-ietf-p2psip-service-discovery-03 == Outdated reference: A later version (-04) exists of draft-petithuguenin-vipr-reload-usage-02 == Outdated reference: A later version (-03) exists of draft-knauf-p2psip-share-02 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Petit-Huguenin 3 Internet-Draft (Unaffiliated) 4 Intended status: Standards Track October 31, 2011 5 Expires: May 3, 2012 7 Configuration of Access Control Policy in REsource LOcation And 8 Discovery (RELOAD) Base Protocol 9 draft-petithuguenin-p2psip-access-control-04 11 Abstract 13 This document describes an extension to the REsource LOcation And 14 Discovery (RELOAD) base protocol to distribute the code of new Access 15 Control Policies without having to upgrade the RELOAD implementations 16 in an overlay. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, except to format it 23 for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 3, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 65 A.1. Standard Access Control Policies . . . . . . . . . . . . . 8 66 A.1.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . . 8 67 A.1.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . . 9 68 A.1.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . . 9 69 A.1.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . . 9 70 A.2. Service Discovery Access Control Policy NODE-ID-MATCH . . 10 71 A.3. VIPR Access Control Policy . . . . . . . . . . . . . . . . 11 72 A.4. ShaRe Access Control Policy USER-CHAIN-ACL . . . . . . . . 12 73 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 12 74 B.1. Modifications between -04 and -03 . . . . . . . . . . . . 12 75 B.2. Modifications between -03 and -02 . . . . . . . . . . . . 12 76 B.3. Modifications between -02 and -01 . . . . . . . . . . . . 13 77 B.4. Modifications between -01 and -00 . . . . . . . . . . . . 13 78 B.5. Running Code Considerations . . . . . . . . . . . . . . . 13 79 B.6. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The RELOAD base protocol specifies an Access Control Policy as 85 "defin[ing] whether a request from a given node to operate on a given 86 value should succeed or fail." The paragraph continues saying that 87 "[i]t is anticipated that only a small number of generic access 88 control policies are required", but there is indications that this 89 assumption will not hold. On all the RELOAD Usages defined in other 90 documents than the RELOAD base protocol, roughly 50% defines a new 91 Access Control Policy. 93 The problem with a new Access Control Policy is that, because it is 94 executed when a Store request is processed, it needs to be 95 implemented by all the peers and so requires an upgrade of the 96 software. This is something that is probably not possible in large 97 overlays or on overlays using different implementations. For this 98 reason, this document proposes an extension to the RELOAD 99 configuration document that permits to transport the code of a new 100 Access Control Policy to each peer. 102 This extension defines a new element that can 103 be optionally added to a element in the configuration 104 document. The element contains ECMAScript 105 [ECMA-262] code that will be called for each StoredData object that 106 use this access control policy. The code receives four parameters, 107 corresponding to the Resource-ID, Signature, Kind and StoredDataValue 108 of the value to store. The code returns true or false to signal to 109 the implementation if the request should succeed or fail. 111 For example the USER-MATCH Access Control Policy defined in the base 112 protocol could be redefined by inserting the following code in an 113 element: 115 return resource.equalsHash(signer.user_name.bytes()); 117 The parameters are also passed to the code, so the NODE- 118 MULTIPLE Access Control Policy could be implemented like this: 120 for (var i = 0; i < kind.max_node_multiple; i++) { 121 if (resource.equalsHash(signer.node_id, i.width(4))) { 122 return true; 123 } 124 } 125 return false; 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are 134 appropriate when valid exceptions to a general requirement are known 135 to exist or appear to exist, and it is infeasible or impractical to 136 enumerate all of them. However, they should not be interpreted as 137 permitting implementors to fail to implement the general requirement 138 when such failure would result in interoperability failure. 140 3. Processing 142 A peer receiving a configuration document containing one or more 143 elements, either by retrieving it from the 144 configuration server or in a ConfigUpdateReq message, MUST reject 145 this configuration if is not is not signed or if the signature 146 verification fails. 148 The Compact Relax NG Grammar for this element is: 150 namespace acp = "http://implementers.org/access-control" 152 parameter &= element acp:access-control-code { 153 attribute name { xsd:string }, 154 xsd:base64Binary 155 }? 157 The "name" attribute defines the access control policy and can then 158 be used in a element as if it was defined by IANA. 160 If the element is present in the namespace 161 allocated to this specification, and the Access Control Policy is not 162 natively implemented, then the code inside the element MUST be called 163 for each DataValue found in a received StoreReq for a Kind that is 164 defined with this access control policy. The content of the element MUST be decoded using the base64 [RFC4648] 166 encoding, uncompressed using gzip [RFC1952] then converted to 167 characters using UTF-8. elements that are not 168 encoded using UTF-8, compressed with gzip or finally converted to the 169 base64 format MUST be ignored. For each call to the code, the 170 following ECMAScript objects, properties and functions MUST be 171 available: 173 configuration.instance_name: The name of the overlay, as a String 174 object. 175 configuration.topology_plugin: The overlay algorithm, as a String 176 object. 177 configuration.node_id_length: The length of a NodeId in bytes, as a 178 Number object. 179 configuration.kinds: An array of kinds (with the same definition 180 than the kind object), indexed by id and eventually by name. 181 configuration.evaluate(String, String, String): A function that 182 evaluates the first parameter as an XPath expression against the 183 configuration element, and returns the result as a String object. 184 The second parameter must contain a namespace prefix and the third 185 parameter must contain a namespace. 186 kind.id: The id of the Kind associated with the entry, as a Number 187 object. 188 kind.name: If the Kind associated with the entry is registered by 189 IANA, contains the name as a String object. If not, this property 190 is undefined. 191 kind.data_model: The name of the Data Model associated with the 192 entry, as a String object. 193 kind.access_control: The name of the Access Control Policy 194 associated with the entry, as a String object. 195 kind.max_count: The value of the max-count element in the 196 configuration file, as a Number object. 197 kind.max_size: The value of the max-size element in the 198 configuration file as a Number object. 199 kind.max_node_multiple: If the Access Control is MULTIPLE-NODE, 200 contains the value of the max-node-multiple element in the 201 configuration file, as a Number object. If not, this property is 202 undefined. 203 kind.evaluate(String, String, String): A function that evaluates the 204 first parameter as an XPath expression against the kind element, 205 and returns the result as a String object. The second parameter 206 must contain a namespace prefix and the third parameter must 207 contain a namespace. 208 resource: An opaque object representing the Resource-ID, as an array 209 of bytes. 210 resource.entries: An array of arrays of entry objects, with the 211 first array level indexed by Kind-Id and kind names, and the 212 second level indexed by index, key or nothing, depending on the 213 data model of the kind. This permits to retrieve all the values 214 of all Kinds stored at the same Resource-ID than the entry 215 currently processed. 216 resource.equalsHash(Object...): A function that returns true if 217 hashing the concatenation of the arguments according to the 218 mapping function of the overlay algorithm is equal to the 219 Resource-ID. Each argument is an array of bytes. 221 entry.index: If the Data Model is ARRAY, contains the index of the 222 entry, as a Number object. If not, this property is undefined. 223 entry.key: If the Data Model is DICTIONARY, contains the key of the 224 entry, as an array of bytes. If not, this property is undefined. 225 entry.storage_time: The date and time used to store the entry, as a 226 Date object. 227 entry.lifetime: The validity for the entry in seconds, as a Number 228 object. 229 entry.exists: Indicates if the entry value exists, as Boolean 230 object. 231 entry.value: This property contains an opaque object that represents 232 the whole data, as an array of bytes. 233 entry.signer.user_name: The rfc822Name stored in the certificate 234 that was used to sign the request, as a String object. 235 entry.signer.node_id: The Node-ID stored in the certificate that was 236 used to sign the request, as an array of bytes. 238 The properties SHOULD NOT be modifiable or deletable and if they are, 239 modifying or deleting them MUST NOT modify or delete the equivalent 240 internal values (in other words, the code cannot be used to modify 241 the elements that will be stored). 243 The value returned by the code is evaluated to true or false, 244 according to the ECMAScript rules. If the return value of one of the 245 call to the code is evaluated to false, then the StoreReq fails, the 246 state MUST be rolled back and an Error_Forbidden MUST be returned. 248 4. Security Considerations 250 Because the configuration document containing the ECMAScript code is 251 under the responsability of the same entity that will sign it, using 252 a scripting language does not introduce any additional risk if the 253 RELOAD implementers follow the rules in this document (no side effect 254 when modifying the parameters, only base classes of ECMAScript 255 implemented, etc...). It is even possible to deal with less than 256 perfect implementations as long as they do not accept a configuration 257 file that is not signed correctly. One way for the signer to enforce 258 this would be to deliberately send in a ConfigUpdate an incorrectly 259 signed version of the configuration file and blacklist all the nodes 260 that accepted it in a newly issued configuration file. 262 By permitting multiple overlay implementations to interoperate inside 263 one overlay, RELOAD helps build overlays that are not only resistant 264 to hardware or communication failures, but also to programmer errors. 265 Distributing the access control policy code inside the configuration 266 document reintroduces this single point of failure. To mitigate this 267 problem, new access control policies should be implemented natively 268 as soon as possible, but if all implementations uses the script as a 269 blueprint for the native code, an hidden bug can be duplicated. This 270 is why developers should implement new access control policies from 271 the normative text instead of using the code. That is anyway 272 probably not legal under most copyright laws but to help developers 273 do the right thing the code in the configuration is obfuscated by 274 compressing and encoding it as a base64 character string. 276 5. IANA Considerations 278 If this document is accepted as a standard track document this 279 section will request an URN in the "XML Namespaces" class of the 280 "IETF XML Registry" from IANA. Until this is done, implementions 281 should use the following URN: 283 http://implementers.org/access-control 285 6. Acknowledgements 287 This document was written with the xml2rfc tool described in 288 [RFC2629]. 290 7. References 292 7.1. Normative References 294 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 295 Randers-Pehrson, "GZIP file format specification version 296 4.3", RFC 1952, May 1996. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 302 Encodings", RFC 4648, October 2006. 304 [I-D.ietf-p2psip-base] 305 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 306 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 307 Base Protocol", draft-ietf-p2psip-base-19 (work in 308 progress), October 2011. 310 [ECMA-262] 311 Ecma, "ECMAScript Language Specification 3rd Edition", 312 December 2009. 314 7.2. Informative References 316 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 317 June 1999. 319 [I-D.ietf-p2psip-service-discovery] 320 Maenpaa, J. and G. Camarillo, "Service Discovery Usage for 321 REsource LOcation And Discovery (RELOAD)", 322 draft-ietf-p2psip-service-discovery-03 (work in progress), 323 July 2011. 325 [I-D.petithuguenin-vipr-reload-usage] 326 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "A 327 Usage of Resource Location and Discovery (RELOAD) for 328 Public Switched Telephone Network (PSTN) Verification", 329 draft-petithuguenin-vipr-reload-usage-02 (work in 330 progress), July 2011. 332 [I-D.knauf-p2psip-share] 333 Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A 334 Usage for Shared Resources in RELOAD (ShaRe)", 335 draft-knauf-p2psip-share-02 (work in progress), 336 October 2011. 338 Appendix A. Examples 340 A.1. Standard Access Control Policies 342 This section shows the ECMAScript code that could be used to 343 implement the standard Access Control Policies defined in 344 [I-D.ietf-p2psip-base]. 346 A.1.1. USER-MATCH 348 String.prototype['bytes'] = function() { 349 var bytes = []; 350 for (var i = 0; i < this.length; i++) { 351 bytes[i] = this.charCodeAt(i); 352 } 353 return bytes; 354 }; 356 return resource.equalsHash(entry.signer.user_name.bytes()); 358 A.1.2. NODE-MATCH 360 return resource.equalsHash(entry.signer.node_id); 362 A.1.3. USER-NODE-MATCH 364 String.prototype['bytes'] = function() { 365 var bytes = []; 366 for (var i = 0; i < this.length; i++) { 367 bytes[i] = this.charCodeAt(i); 368 } 369 return bytes; 370 }; 372 var equals = function(a, b) { 373 if (a.length !== b.length) return false; 374 for (var i = 0; i < a.length; i++) { 375 if (a[i] !== b[i]) return false; 376 } 377 return true; 378 }; 380 return resource.equalsHash(entry.signer.user_name.bytes()) 381 && equals(entry.key, entry.signer.node_id); 383 A.1.4. NODE-MULTIPLE 385 Number.prototype['width'] = function(w) { 386 var bytes = []; 387 for (var i = 0; i < w; i++) { 388 bytes[i] = (this >>> ((w - i - 1) * 8)) & 255; 389 } 390 return bytes; 391 }; 393 for (var i = 0; i < kind.max_node_multiple; i++) { 394 if (resource.equalsHash(entry.signer.node_id, i.width(4))) { 395 return true; 396 } 397 } 398 return false; 400 [[Note that base-15 still does not state exactly the length of i when 401 concatenated in the hash input]] 403 A.2. Service Discovery Access Control Policy NODE-ID-MATCH 405 [I-D.ietf-p2psip-service-discovery] defines a specific Access Control 406 Policy (NODE-ID-MATCH) that need to access the content of the entry 407 to be written. If implemented as specified by this document, the 408 ECMAScript code would look something like this: 410 /* Insert here the code from 411 http://jsfromhell.com/classes/bignumber 412 */ 414 var toBigNumber = function(node_id) { 415 var bignum = new BigNumber(0); 416 for (var i = 0; i < node_id.length; i++) { 417 bignum = bignum.multiply(256).add(node_id[i]); 418 } 419 return bignum; 420 }; 422 var checkIntervals = function(node_id, level, node, factor) { 423 var size = new BigNumber(2).pow(128); 424 var node = toBigNumber(node_id); 425 for (var f = 0; f < factor; f++) { 426 var temp = size.multiply(new BigNumber(f) 427 .pow(new BigNumber(level).negate())); 428 var min = temp.multiply(node.add(new BigNumber(f) 429 .divide(factor))); 430 var max = temp.multiply(node.add(new BigNumber(f + 1) 431 .divide(factor))); 432 if (node.compare(min) === -1 || node.compare(max) == 1 433 || node.compare(max) == 0) return false; 434 } 435 return true; 436 }; 438 var equals = function(a, b) { 439 if (a.length !== b.length) return false; 440 for (var i = 0; i < a.length; i++) { 441 if (a[i] !== b[i]) return false; 442 } 443 return true; 444 }; 446 var level = function(value) { 447 var length = value[16] * 256 + value[17]; 448 return value[18 + length] * 256 + value[18 + length + 1]; 449 }; 450 var node = function(value) { 451 var length = value[16] * 256 + value[17]; 452 return value[18 + length + 2] * 256 453 + value[18 + length + 3]; 454 }; 456 var namespace = function(value) { 457 var length = value[16] * 256 + value[17]; 458 return String.fromCharCode.apply(null, 459 value.slice(18, length + 18)); 460 }; 462 var branching_factor = 463 kind.evaluate('/branching-factor', 464 'redir', 'urn:ietf:params:xml:ns:p2p:redir'); 465 return equals(entry.key, entry.signer.node_id) 466 && (!entry.exists || checkIntervals(entry.key, 467 level(entry.value), node(entry.value), 468 branching_factor)) 469 && (!entry.exists 470 || resource.equalsHash(namespace(entry.value), 471 level(entry.value), node(entry.value))); 473 Note that the code for the BigNumber object was removed from this 474 example, as the licensing terms are unclear. The code is available 475 at . 477 A.3. VIPR Access Control Policy 479 [I-D.petithuguenin-vipr-reload-usage] defines a specific Access 480 Control Policy. If implemented as specified by this document, the 481 ECMAScript code would look something like this: 483 var equals = function(a, b) { 484 if (a.length !== b.length) return false; 485 for (var i = 0; i < a.length; i++) { 486 if (a[i] !== b[i]) return false; 487 } 488 return true; 489 }; 490 var length = configuration.node_id_length; 491 return equals(entry.key.slice(0, length), 492 entry.value.slice(4, length + 4)) 493 && equals(entry.key.slice(0, length), entry.signer.node_id); 495 A.4. ShaRe Access Control Policy USER-CHAIN-ACL 497 [I-D.knauf-p2psip-share] defines a new Access Control Policies, USER- 498 CHAIN-ACL. If implemented as specified by this document, the 499 ECMAScript code would look something like this: 501 var pattern = kind.evaluate('/share:pattern', 502 'share', 'urn:ietf:params:xml:ns:p2p:config-share'); 503 var username = entry.signer.user_name.match(/^([^@]+)@(.+)$/); 504 var new_pattern = new RegExp( 505 pattern.replace('$USER', username[1]) 506 .replace('$DOMAIN', username[2])); 507 var length = entry.value[0] * 256 + entry.value[1]; 508 var resource_name = String.fromCharCode.apply(null, 509 entry.value.slice(2, length + 2)); 510 return new_pattern.test(resource_name);\n")); 512 [[Note: the code is incomplete]] 514 Appendix B. Release notes 516 This section must be removed before publication as an RFC. 518 B.1. Modifications between -04 and -03 520 o Added a kinds array on the configuration object. 521 o Added an entries array on the resource object for retrieve all the 522 entries of all kinds stored at the same Resource-Id. 523 o the signer property is now an attribute of entry. 524 o Added initial code for ShaRe policy. 526 B.2. Modifications between -03 and -02 528 o Moved the access-control-code element fom the kind element to the 529 configuration element so the code can be shared between kinds. A 530 new "name" attribute is used to name the access control policy. 531 o Added configuration object to pass information about the whole 532 overlay. 533 o Added evaluate functions to retrieve extensions parameters. 534 o Renamed the signature attribute to signer. 535 o Filled Security section. 536 o Added temporary namespace to IANA section. 537 o The content of the access-control-code is now UTF-8 encoded, 538 compressed with gzip and converted back to characters with base64. 539 o Fixed the implementation of the service discovery access control 540 policy. 542 o Added code for VIPR policy. 544 B.3. Modifications between -02 and -01 546 o Made clear that an unsigned kind with this extension must be 547 rejected. 548 o Removed the kind.params array, and converted the max-count, max- 549 size and max-node-multiple as Number objects. Fixed the examples. 550 o Removed the parsing of extensions in the kind element. The former 551 system did not work with namespaces or attributes, and the right 552 solution (xpath) is probably too complex. The value of the 553 parameters can still be manually mirrored in the script, so there 554 is perhaps no need for the added complexity. Also fixed the 555 examples. 556 o Reference draft-p2psip-share instance of draft-p2psip-disco. 557 o Added a "Running Code Considerations" section that contain the 558 reference to the reference implementation and script tester. 559 o Nits 561 B.4. Modifications between -01 and -00 563 o Changed reference from JavaScript to ECMAScript. 564 o Changed signature from equals() to equalsHash(). 565 o Fixed the examples following implementation. 566 o Replaced automatic decoding of value by ECMAScript code. 567 o Added the type of each property. 568 o Specified that the code cannot be used to modify the value stored. 570 B.5. Running Code Considerations 572 o Reference Implementation and Access Control Policy script tester 573 (). 574 Marc Petit-Huguenin. Implements version -03. 576 B.6. TODO List 578 o Finish the code for ShaRe. 580 Author's Address 582 Marc Petit-Huguenin 583 (Unaffiliated) 585 Email: petithug@acm.org