├── .gitattributes
├── README.md
└── draft-rundgren-jose-json-crypto-normalization.xml


/.gitattributes:
--------------------------------------------------------------------------------
1 | # Disable LF normalization for all files
2 | * -text


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | Although working, this scheme has been superseded by [JSON Canonicalization](https://github.com/cyberphone/json-canonicalization#json-canonicalization).
 2 | 
 3 | # json-crypto-normalization
 4 | Internet-Draft describing the JSON processing rules used in Cleartext JWS and JWE as well as in some other schemes
 5 | where "Crypto Safe" JSON is utilized.
 6 | 
 7 | ## View draft in traditional RFC format:
 8 | https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https%3A%2F%2Fraw.githubusercontent.com%2Fcyberphone%2Fjson-crypto-normalization%2Fmaster%2Fdraft-rundgren-jose-json-crypto-normalization.xml
 9 | 
10 | ## View draft in HTML markup:
11 | https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https%3A%2F%2Fraw.githubusercontent.com%2Fcyberphone%2Fjson-crypto-normalization%2Fmaster%2Fdraft-rundgren-jose-json-crypto-normalization.xml&modeAsFormat=html%2Fascii
12 | 


--------------------------------------------------------------------------------
/draft-rundgren-jose-json-crypto-normalization.xml:
--------------------------------------------------------------------------------
  1 | <?xml version="1.0" encoding="us-ascii"?>
  2 | <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  3 | <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
  4 | 
  5 | <?rfc strict="yes" ?>
  6 | <?rfc toc="yes"?>
  7 | <?rfc tocdepth="4"?>
  8 | <?rfc symrefs="yes"?>
  9 | <?rfc sortrefs="yes" ?>
 10 | <?rfc compact="yes" ?>
 11 | <?rfc subcompact="no" ?>
 12 | 
 13 | <rfc category="info" docName="draft-rundgren-jose-json-crypto-normalization-00" ipr="trust200902">
 14 |   <front>
 15 |     <title abbrev="draft-rundgren-jose-json-crypto-normalization">
 16 |       JSON Crypto Normalization (JCN)
 17 |     </title>
 18 | 
 19 |     <author fullname="Anders Rundgren" initials="A." surname="Rundgren">
 20 |       <organization>Independent</organization>
 21 |       <address>
 22 |         <postal>
 23 |           <street></street>
 24 |           <code></code>
 25 |           <city>Montpellier</city>
 26 |           <country>France</country>
 27 |         </postal>
 28 |         <email>anders.rundgren.net@gmail.com</email>
 29 |       </address>
 30 |     </author>
 31 | 
 32 |     <date year="2018" />
 33 | 
 34 |     <area>Security</area>
 35 | 
 36 |     <workgroup>JSON Object Signing and Encryption (JOSE)</workgroup>
 37 | 
 38 |     <keyword>
 39 |       JOSE, JSON, ECMAScript, Signatures, Cryptography, Canonicalization
 40 |     </keyword>
 41 | 
 42 |     <abstract>
 43 |       <t>
 44 |         Cryptographic operations like hashing and signing depend on that the
 45 |         target data does not change during serialization, transport, or parsing.
 46 |         By applying the JCN (JSON Crypto Normalization) scheme, data provided in the
 47 |         JSON <xref target="RFC8259"/> format can be exchanged &quot;as is&quot;,
 48 |         while still being suitable for cryptographic operations.
 49 |         JCN achieves this by exploiting the strict predictability
 50 |         offered by the JSON parsing and serialization methods defined in
 51 |         ECMAScript beginning with version 6 <xref target="ES6"/>.
 52 |       </t>
 53 |       <t>
 54 |         The intended audience of this document is JSON tool vendors who
 55 |         may need updating their products in order to support schemes like
 56 |         Cleartext JSON Web Signature <xref target="CT-JWS"/>,
 57 |         building on ECMAScript <xref target="ES6"/> JSON processing rules.
 58 |         The latter also have utility outside of cryptography.
 59 |       </t>
 60 |     </abstract>
 61 |   </front>
 62 | 
 63 |   <middle>
 64 |     <section anchor="Introduction" title="Introduction">
 65 |       <t>
 66 |         Cryptographic operations like hashing and signing depend on that the
 67 |         target data does not change during serialization, transport, or parsing.
 68 |         A straightforward way of accomplishing this is converting the data into
 69 |         a format which has a simple and fixed representation like Base64Url <xref target="RFC4648"/>
 70 |         which for example have been used in JWS <xref target="RFC7515"/>.
 71 |         Another solution is creating a canonicalized version of the target data
 72 |         with XML Signature <xref target="XMLDSIG"/> as a prime example.
 73 |       </t>
 74 |       <t>
 75 |         Although the mentioned approaches obviously work, the ability
 76 |         applying cryptographic operations on JSON data (without encoding it
 77 |         in Base64Url or having to rely on standalone canonicalizers) became
 78 |         fully realistic with the advent of ECMAScript (aka JavaScript) version 6
 79 |         from now on referred to as "ES6".
 80 |       </t>
 81 |       <t>
 82 |         Realistic in this context means &quot;available&quot; since ES6
 83 |         compatible JSON processing is already supported by most Web browsers,
 84 |         Node.js <xref target="NODEJS"/>,
 85 |         as well as by third party libraries like Open&nbsp;Keystore <xref target="OPENKEY"/>.
 86 |       </t>
 87 |       <t>
 88 |         The JCN specification describes how JSON processing rules compliant
 89 |         with ES6, can be used for supporting &quot;Crypto&nbsp;Safe&quot; JSON.
 90 |       </t>
 91 |     </section>
 92 | 
 93 |     <section anchor="Terminology" title="Terminology">
 94 |       <t>
 95 |         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
 96 |         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
 97 |         "MAY", and "OPTIONAL" in this document are to be interpreted as
 98 |         described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
 99 |         when, and only when, they appear in all capitals, as shown here.
100 |       </t>
101 |     </section>
102 | 
103 |     <section anchor="Operation" title="Detailed Operation">
104 |       <t>
105 |         This section elaborates on the different issues related to JCN and how they are addressed by ES6.
106 |       </t>
107 |       <section anchor="json.parsing" title="Core JSON Parsing">
108 |         <t>
109 |           When parsing JSON string data the following MUST be taken in account:
110 |         </t>
111 |         <t>
112 |           <list style="symbols">
113 |             <t>
114 |               The input data MUST conform to JSON as specified in <xref target="RFC8259"/>.
115 |               <vspace blankLines="1"/>
116 |               Note: ES6 requires that data encoded as UTF-8 <xref target="UNICODE"/>,
117 |               is converted to the internal ES6 string format (which is based on UTF-16),
118 |               in order to make it processable
119 |               by the ES6 <spanx style="verb">JSON.parse()</spanx> method.
120 |             </t>
121 |             <t>
122 |               The property names within a JSON object MUST be unique.
123 |               <vspace blankLines="1"/>
124 |               Note: this is currently not checked by ES6 compatible parsers.
125 |             </t>
126 |             <t>
127 |               Whitespace MUST be removed which in practical terms means removal
128 |               of all characters outside of quoted strings having a value of x09,
129 |               x0a, x0d or x20.  This is the de-facto standard for JSON parsers,
130 |               indirectly derived from the JSON <xref target="RFC8259"/> specification
131 |               itself.
132 |             </t>
133 |             <t>
134 |               All JSON escape sequences
135 |               (\/&nbsp;\"&nbsp;\\&nbsp;\b&nbsp;\f&nbsp;\n&nbsp;\r&nbsp;\t&nbsp;\uhhhh)
136 |               within quoted strings MUST be converted to their proper single
137 |               character internal representation.
138 |               ES6 defines this behavior in Section <xref target="ES6" format="none">11.8.4</xref>.
139 |             </t>
140 |           </list>
141 |         </t>
142 |       </section>
143 |       <section anchor="json.proporder" title="Preserving JSON Property Order">
144 |         <t>
145 |           It is common knowledge that the order of properties in JSON is insignificant.
146 |         </t>
147 |         <t>
148 |           However, this is not equivalent with disrespecting the order in which properties
149 |           are supplied in JSON objects during parsing or serialization.
150 |           It is obvious that if you parse (or create) a JSON object like
151 |         </t>
152 |         <t>
153 |           <figure align="center">
154 |             <artwork><![CDATA[  {
155 |     "Name": "John Doe",
156 |     "Address": "2000 Sunset Boulevard",
157 |     "City": "Los Angeles",
158 |     "Zip": "90001",
159 |     "State": "CA"
160 |   }]]></artwork>
161 |           </figure>
162 |         </t>
163 |         <t>
164 |           and it would serialize like
165 |         </t>
166 |         <t>
167 |           <figure align="center">
168 |             <artwork><![CDATA[  {
169 |     "Zip": "90001",
170 |     "Address": "2000 Sunset Boulevard",
171 |     "City": "Los Angeles",
172 |     "Name": "John Doe",
173 |     "State": "CA"
174 |   }]]></artwork>
175 |           </figure>
176 |         </t>
177 |         <t>
178 |           the result would not only possibly surprise the developer; it would break a signature
179 |           depending on an immutable representation of JSON data.
180 |         </t>
181 |         <t>
182 |           ES6 does with a minor exception described in <xref target="es6.interoperability"/>,
183 |           maintain an internal &quot;Creation&nbsp;Order&quot; of properties, per
184 |           Section <xref target="ES6" format="none">9.1.12</xref> of ES6.
185 |           This ordering applies to the following core operations that may
186 |           be used for dealing with &quot;Crypto&nbsp;Safe&quot; JSON data:
187 |         </t>
188 |         <t>
189 |           <list style="symbols">
190 |             <t>
191 |               Creation of an empty JSON object:
192 |               <list style="empty">
193 |                 <t>obj = {}</t>
194 |               </list>
195 |             </t>
196 |             <t>
197 |               Parsing of a JSON string into a JSON object:
198 |               <list style="empty">
199 |                 <t>obj = JSON.parse('...')</t>
200 |               </list>
201 |             </t>
202 |             <t>
203 |               Serialization of a JSON object into JSON string:
204 |               <list style="empty">
205 |                 <t>... = JSON.stringify(obj)</t>
206 |               </list>
207 |             </t>
208 |             <t>
209 |               Shallow cloning (only the top level properties are copied) of a JSON object:
210 |               <list style="empty">
211 |                 <t>... = Object.assign({}, obj)</t>
212 |               </list>
213 |             </t>
214 |             <t>
215 |               Deep cloning of a JSON object:
216 |               <list style="empty">
217 |                 <t>... = JSON.parse(JSON.stringify(obj))</t>
218 |               </list>
219 |             </t>
220 |             <t>
221 |               Deletion of a JSON property:
222 |               <list style="empty">
223 |                 <t>delete obj.property</t>
224 |               </list>
225 |             </t>
226 |             <t>
227 |               Addition of a JSON property:
228 |               <list style="empty">
229 |                 <t>obj.property = ...</t>
230 |               </list>
231 |             </t>
232 |           </list>
233 |         </t>
234 |         <t>
235 |           Although the above is specified in ES6 notation, a JSON tool kit
236 |           for another platform MUST provide the same functionality
237 |           in order to be compliant with this specification.
238 |         </t>
239 |       </section>
240 |       <section anchor="json.serialization" title="JSON Serialization">
241 |         <section anchor="json.serialization.data" title="Serialization of Data">
242 |           <t>
243 |             Assume that you parse a JSON object like the following
244 |             using the rules outlined in the previous sections:
245 |           </t>
246 |           <t>
247 |             <figure align="center">
248 |               <artwork><![CDATA[  {
249 |     "escaping": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/",
250 |     "numbers": [1E30,4.50,6,2e-3,0.000000000000000000000000001]
251 |   }]]></artwork>
252 |             </figure>
253 |           </t>
254 |           <t>
255 |             If you subsequently serialize the object created by the operation above,
256 |             using an ES6 compliant serializer,
257 |             the result would (with a line wrap between elements for display purposes only),
258 |             be rather divergent with respect to data representation:
259 |           </t>
260 |           <t>
261 |             <figure align="center">
262 |               <artwork><![CDATA[  {"escaping":"\u20ac$\u000f\nA'B\"\\\\\"/","numbers":
263 |   [1e+30,4.5,6,0.002,1e-27]}]]></artwork>
264 |             </figure>
265 |           </t>
266 |           <t>Note: \u20ac denotes the Euro character, which not being ASCII, is currently not displayable in RFCs.</t>
267 |           <t>
268 |             The reason for the huge difference between the parsed data and its
269 |             serialized counterpart, is due to a wider tolerance on input data than on output data.
270 |             <vspace blankLines="1"/>
271 |             For serializing JSON data according to ES6 the following rules apply:
272 |             <list style="symbols">
273 |               <t>
274 |                 The literals <spanx style="verb">null</spanx>, <spanx style="verb">true</spanx>,
275 |                 and <spanx style="verb">false</spanx> present no challenge since they already have a
276 |                 fixed definition in JSON <xref target="RFC8259"/>.
277 |               </t>
278 |               <t>
279 |                 For data of the type <spanx style="verb">String</spanx> (which includes
280 |                 property names as well), each character MUST be serialized as
281 |                 described in Section <xref target="ES6" format="none">24.3.2.2</xref> of ES6.
282 |                 <vspace blankLines="1"/>
283 |                 If the Unicode value falls within the traditional ASCII control
284 |                 character range (0x0000-0x001f), it MUST
285 |                 be serialized using lowercase hexadecimal Unicode notation (\uhhhh) unless it is in the
286 |                 set of predefined JSON control characters 0x0008, 0x0009, 0x000a, 0x000c or 0x000d
287 |                 which MUST be serialized as \b, \t, \n, \f and \r respectively.
288 |                 <vspace blankLines="1"/>
289 |                 If the Unicode value is outside of the ASCII control character range, it MUST
290 |                 be serialized &quot;as&nbsp;is&quot; unless it is equivalent to
291 |                 0x005c&nbsp;(\) or 0x0022&nbsp;(") which MUST be serialized as \\ and \" respectively.
292 |               </t>
293 |               <t>
294 |                 Data of the type <spanx style="verb">Number</spanx>, MUST be serialized according to
295 |                 Section <xref target="ES6" format="none">7.1.12.1</xref> of ES6; for
296 |                 maximum interoperability preferably including the "Note 2" enhancement as well.
297 |                 The latter is implemented by for example Google's V8 <xref target="V8"/>.
298 |                 <vspace blankLines="1"/>
299 |                 Due to the relative complexity of this part, it is not included in this specification.
300 |                 <vspace blankLines="1"/>
301 |                 Note that ES6 builds on the IEEE-754 <xref target="IEEE754"/> double precision
302 |                 standard for storing <spanx style="verb">Number</spanx> data.  If the target
303 |                 JSON system uses another format it may be difficult achieving full
304 |                 interoperability with respect to numeric data.
305 |                 <vspace blankLines="1"/>
306 |                 <xref target="ieee754.test"/> holds a set of test values.
307 |               </t>
308 |             </list>
309 |           </t>
310 |         </section>
311 |         <section anchor="json.utf8" title="UTF-8 Generation">
312 |           <t>
313 |             The final step is converting the textual output into an UTF-8 formatted array.
314 |             Applied to the sample in <xref target="json.serialization.data"/> this should yield the following bytes here shown in hexadecimal notation:
315 |           </t>
316 |           <t>
317 |             <figure align="center">
318 |               <artwork><![CDATA[  7b 22 65 73 63 61 70 69 6e 67 22 3a 22 e2 82 ac 24 5c 75 30
319 |   30 30 66 5c 6e 41 27 42 5c 22 5c 5c 5c 5c 5c 22 2f 22 2c 22
320 |   6e 75 6d 62 65 72 73 22 3a 5b 31 65 2b 33 30 2c 34 2e 35 2c
321 |   36 2c 30 2e 30 30 32 2c 31 65 2d 32 37 5d 7d]]></artwork>
322 |             </figure>
323 |           </t>
324 |           <t>
325 |             This data is intended to be usable as 
326 |             interoperable input to cryptographic functions.
327 |           </t>
328 |         </section>
329 |       </section>
330 |     </section>
331 |     <section anchor="es6.interoperability" title="ES6 Interoperability">
332 |       <t>
333 |         For execution speed optimization reasons, ES6 internally rearranges
334 |         the order of properties with names expressed as integers, making a
335 |         parsed JSON string like
336 |       </t>
337 |       <t>
338 |         <figure align="center">
339 |           <artwork><![CDATA[  {"2":"First","A":"Second","1":"Third"}]]></artwork>
340 |         </figure>
341 |       </t>
342 |       <t>
343 |         actually serialize as
344 |       </t>
345 |       <t>
346 |         <figure align="center">
347 |           <artwork><![CDATA[  {"1":"Third","2":"First","A":"Second"}]]></artwork>
348 |         </figure>
349 |       </t>
350 |       <t>
351 |         which is in conflict with the requirements stated in <xref target="json.proporder"/>.
352 |         Due to this fact, signature creators MUST
353 |         "emulate" this scheme since this behavior is not
354 |         intended to be an additional requirement to support by JSON tools in
355 |         general in order to use this specification.
356 |         <vspace blankLines="1"/>
357 |         The easiest way accomplishing this is to programmatically make sure that possible
358 |         numeric property names always are created first and added in ascending
359 |         order.
360 |       </t>
361 |     </section>
362 | 
363 |     <section anchor="IANA" title="IANA Considerations">
364 |       <t>
365 |         This document has no IANA actions.
366 |       </t>
367 |     </section>
368 | 
369 |     <section anchor="Security" title="Security Considerations">
370 |       <t>
371 |         JSON parsers MUST check that input data conforms to the JSON <xref target="RFC8259"/>
372 |         specification.
373 |       </t>
374 |     </section>
375 | 
376 |     <section anchor="Acknowledgements" title="Acknowledgements">
377 |       <t>
378 |         Building on ES6 number normalization was originally
379 |         proposed by James Manger. This ultimately led to
380 |         the adoption of the entire ES6 JSON processing model.
381 |       </t>
382 |     </section>
383 |   </middle>
384 | 
385 |   <back>
386 |     <references title="Normative References">
387 |       <?rfc include='reference.RFC.2119'?>
388 |       <?rfc include='reference.RFC.8259'?>
389 |       <?rfc include='reference.RFC.8174'?>
390 | 
391 |       <reference anchor="ES6" target="https://www.ecma-international.org/ecma-262/6.0/index.html">
392 |         <front>
393 |           <title>ECMAScript 2015 Language Specification</title>
394 |           <author>
395 |             <organization>Ecma International</organization>
396 |           </author>
397 |           <date/>
398 |         </front>
399 |       </reference>
400 |       <reference anchor="IEEE754" target="http://grouper.ieee.org/groups/754/">
401 |         <front>
402 |           <title>IEEE Standard for Floating-Point Arithmetic</title>
403 |           <author>
404 |             <organization>IEEE</organization>
405 |           </author>
406 |           <date month="August" year="2008"/>
407 |         </front>
408 |       </reference>
409 |       <reference anchor="UNICODE" target="https://www.unicode.org/versions/Unicode10.0.0/">
410 |         <front>
411 |           <title>The Unicode Standard, Version 10.0.0</title>
412 |           <author>
413 |             <organization>The Unicode Consortium</organization>
414 |           </author>
415 |           <date/>
416 |         </front>
417 |       </reference>
418 |     </references>
419 |     <references title="Informal References">
420 |       <?rfc include='reference.RFC.4648'?>
421 |       <?rfc include='reference.RFC.7515'?>
422 |       <reference anchor="V8" target="https://developers.google.com/v8/">
423 |         <front>
424 |           <title>Chrome V8 Open Source JavaScript Engine</title>
425 |           <author>
426 |             <organization>Google LLC</organization>
427 |           </author>
428 |           <date/>
429 |         </front>
430 |       </reference>
431 |       <reference anchor="CT-JWS" target="https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00">
432 |         <front>
433 |           <title>Work-In-Progress: Cleartext JSON Web Signature</title>
434 |           <author>
435 |             <organization>Erdtman, S., Rundgren, A. and M. Jones</organization>
436 |           </author>
437 |           <date month="March" year="2018"/>
438 |         </front>
439 |       </reference>
440 |       <reference anchor="NODEJS" target="https://nodejs.org">
441 |         <front>
442 |           <title>Node.js</title>
443 |           <author/>
444 |           <date/>
445 |         </front>
446 |       </reference>
447 |       <reference anchor="OPENKEY" target="https://github.com/cyberphone/openkeystore">
448 |         <front>
449 |           <title>Open Keystore</title>
450 |           <author/>
451 |           <date/>
452 |         </front>
453 |       </reference>
454 |       <reference anchor="XMLDSIG" target="https://www.w3.org/TR/xmldsig-core1/">
455 |         <front>
456 |           <title>XML Signature Syntax and Processing Version 1.1</title>
457 |           <author>
458 |             <organization>W3C</organization>
459 |           </author>
460 |           <date/>
461 |         </front>
462 |       </reference>
463 |     </references>
464 | 
465 |     <section anchor="ieee754.test" title="Sample Number Serializations">
466 |       <t>
467 |         The following table holds a set of ES6 <spanx style="verb">Number</spanx> serializations including
468 |         some edge cases.  The field  &quot;ES6&nbsp;Internal&quot; refers to the internal
469 |         ES6 representation of the <spanx style="verb">Number</spanx> data type which is based on the
470 |         IEEE-754 <xref target="IEEE754"/> standard using 64-bit (double precision) values,
471 |         here expressed in hexadecimal.
472 |       </t>
473 |       <t>
474 |         <figure align="center">
475 |           <artwork><![CDATA[|=================================================================|
476 | |   ES6 Internal   |   JSON Representation    |      Comment      |
477 | |=================================================================|
478 | | 0000000000000000 | 0                        | Zero              |
479 | |-----------------------------------------------------------------|
480 | | 8000000000000000 | 0                        | Minus zero        |
481 | |-----------------------------------------------------------------|
482 | | 0000000000000001 | 5e-324                   | Smallest positive |
483 | |-----------------------------------------------------------------|
484 | | 8000000000000001 | -5e-324                  | Smallest negative |
485 | |-----------------------------------------------------------------|
486 | | 7fefffffffffffff | 1.7976931348623157e+308  | Largest positive  |
487 | |-----------------------------------------------------------------|
488 | | ffefffffffffffff | -1.7976931348623157e+308 | Largest negative  |
489 | |-----------------------------------------------------------------|
490 | | 7fffffffffffffff |                          | Error (NaN)       |
491 | |-----------------------------------------------------------------|
492 | | 7ff0000000000000 |                          | Error (Infinity)  |
493 | |-----------------------------------------------------------------|
494 | | 44b52d02c7e14af5 | 9.999999999999997e+22    |                   |
495 | |-----------------------------------------------------------------|
496 | | 44b52d02c7e14af6 | 1e+23                    |                   |
497 | |-----------------------------------------------------------------|
498 | | 44b52d02c7e14af7 | 1.0000000000000001e+23   |                   |
499 | |-----------------------------------------------------------------|
500 | | 444b1ae4d6e2ef4e | 999999999999999700000    |                   |
501 | |-----------------------------------------------------------------|
502 | | 444b1ae4d6e2ef4f | 999999999999999900000    |                   |
503 | |-----------------------------------------------------------------|
504 | | 444b1ae4d6e2ef50 | 1e+21                    |                   |
505 | |-----------------------------------------------------------------|
506 | | 444b1ae4d6e2ef51 | 1.0000000000000001e+21   |                   |
507 | |-----------------------------------------------------------------|
508 | | 41b3de4355555553 | 333333333.3333332        |                   |
509 | |-----------------------------------------------------------------|
510 | | 41b3de4355555554 | 333333333.33333325       |                   |
511 | |-----------------------------------------------------------------|
512 | | 41b3de4355555555 | 333333333.3333333        |                   |
513 | |-----------------------------------------------------------------|
514 | | 41b3de4355555556 | 333333333.3333334        |                   |
515 | |-----------------------------------------------------------------|
516 | | 41b3de4355555557 | 333333333.33333343       |                   |
517 | |-----------------------------------------------------------------|]]></artwork>
518 |         </figure>
519 |       </t>
520 |      </section>
521 |   </back>
522 | </rfc>
523 | 


--------------------------------------------------------------------------------