idnits 2.17.1 draft-strombergson-shf-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 539. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 22, 2005) is 6973 days in the past. Is this intentional? 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: '0-9A-Fa-f' on line 271 -- Looks like a reference, but probably isn't: 'WWWXML' on line 413 == Unused Reference: '4' is defined on line 485, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '2') ** Obsolete normative reference: RFC 3023 (ref. '4') (Obsoleted by RFC 7303) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Standards Track J. Strombergson 2 Internet-Draft InformAsic AB 3 Expires: September 23, 2005 L. Walleij 4 Lunds Tekniska Hogskola 5 P. Faltstrom 6 Cisco Systems Inc 7 March 22, 2005 9 The S Hexdump Format 10 draft-strombergson-shf-06.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 23, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document specifies the S Hexdump Format (SHF), a new XML-based 46 open format for describing binary data in hexadecimal notation. SHF 47 provides the ability to describe both small and large, simple and 48 complex hexadecimal data dumps in an open, modern, transport and 49 vendor neutral format. 51 1. Introduction 53 In the computing, network and embedded systems communities several 54 different types of data formats for hexadecimal data are being used. 55 One of the more common formats is known as "S-records" (and several 56 derivatives) which reportedly originated at the Motorola company. 57 The S Hexdump Format is named in its honour. 59 Typical uses of these dump formats include executable object code for 60 embedded systems (i.e. "firmware"), on-chip flash memories and 61 filesystems, FPGA configuration bitstreams, graphics and other 62 application resources, routing tables, etc. Unfortunately, none of 63 the formats used are truly open, vendor neutral and/or well defined. 65 Even more problematic is the fact that none of these formats are able 66 to represent data sizes that are getting more and more common. Data 67 dumps comprised of multiple sub-blocks with different Word sizes, 68 data sizes spanning anywhere from a few Bytes of data to data sizes 69 much larger than 2^32 bits are not handled. Also, the checksums 70 included in these formats are too simplistic and for larger data 71 sizes provides insufficient ability to accurately detect errors. 72 Alternatively, the overhead needed for proper error detection is very 73 large. 75 The S Hexdump format therefore is an effort to provide a modern, 76 XML-based format that is not too complex for simple tools and 77 computing environments to implement, generate, parse and use. Yet 78 the format is able to handle large data sizes and complex data 79 structures and can provide high quality error detection by leveraging 80 standardized cryptographic hash functions. 82 One of the simplifications introduced in the format is to disallow 83 other number systems such as octal or decimal notation, and to allow 84 for Word sizes of even bytes (8-bit groups) only. This is 85 intentional and was done to simplify implementations aimed for 86 practical present-day applications. Formats aimed for esoteric 87 number systems or odd Word sizes may be implemented elsewhere. 89 At present, the usage of the SHF format may be mainly for Internet 90 transport and file storage on development machinery. A parser for 91 the XML format is presently not easily deployed in hardware devices, 92 but the parsing and checksumming of the SHF data may be done by a 93 workstation computer, which in turn converts the SHF tokens to an 94 ordinary bitstream before the last step (e.g., of a firmware upgrade) 95 commence. 97 SHF is a dump format only and shall not be confused with similar 98 applications, such as binary configuration formats or patches, which 99 are intended to e.g. alter contents of a core memory. Such 100 applications require the possibility to modify individual bits or 101 groups of bits in the memory of a machine, and is not the intended 102 usage of the mechanism described in the present document. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [1]. 110 The key word Byte is to be interpreted as a group of 8 bits. The key 111 word Octet is another name for Byte. 113 The key word Word is to be interpreted as a group containing an 114 integral number of Bytes. 116 The key word Block is to be interpreted as an ordered sequence of 117 Words, beginning at a certain address, running from lower to higher 118 addresses. A Block typically represents a sequence of Words at a 119 certain address range in the memory of a computer. 121 The key word Dump is to be interpreted as a sequence of Blocks, which 122 may or may not be in a particular order. A Dump typically represents 123 some non-continous, interesting parts of the memory of a computer, 124 such that the Dump as a whole has a certain meaning, for example (but 125 not limited to) a complete firmware for an embedded system. 127 The expression 2^n is to be interpreted as the value two (2) raised 128 to the n:th power. For example 2^8 equals the value 256. 130 3. Features and functionality 132 The SHF-format has the following features: 133 o Support for arbitrarily wide data Words 134 o Support for very large data Blocks 135 o Support for an arbitrary number of independent data Blocks 136 o Data integrity detection against errors provided by the RFC3174 137 specified (see [2]) SHA-1 cryptographic signature 138 o An XML-based format 140 In the embedded systems domain, 8- and 16-bit processors are still 141 used in large numbers and will continue to be used for any forseeable 142 future. Simultaneously, more and more systems are using 64-bit and 143 even larger Word sizes. 145 SHF supports all of these systems by allowing the Word size to be 146 specified. The Word size MUST be an integer number of Bytes and at 147 least one (1) Byte. 149 SHF is able to represent both large and small data Blocks. The data 150 Block MUST contain at least one (1) Word. Additionally, the data 151 Block MUST NOT be larger than (2^64)-1 bits. 153 The SHF Dump MUST contain at least one (1) data Block. The maximum 154 number of Blocks supported is 2^64. Each data Block in the Dump MAY 155 have different Word sizes and start at different addresses. 157 The checksum (or message digest) used to verify the correctness or 158 data integrity of each Block is 20 Bytes (160 bits) long. The digest 159 MUST be calculated on the data actually represented by the SHF data 160 Block, NOT the representation, i.e. NOT the ASCII-code. SHA-1 is 161 only able to calculate a digest for a data Block no larger than 162 (2^64)-1 bits and this limits the size of each data Block in SHF to 163 (2^64)-1 bits. 165 4. SHF XML specification 167 The SHF format consists of an XML data structure representing a Dump. 168 The Dump consists of a Dump header section and one (1) or more Block 169 sections containing data. Each Block of data is independent of any 170 other Block. 172 A short, symbolic example of a SHF Dump is illustrated by the 173 following structure: 175 176 179 (Data) 180 181 183 4.1 Header section 185 The header section comprises the Dump tag, which includes the 186 following attributes: 188 o name: A compulsory string of arbitrary length used by any 189 interested party to identify the specific SHF Dump. 190 o blocks: An optional 64 bit hexadecimal value representing the 191 number of Blocks in the specific SHF Dump. Whenever available, 192 this value should be supplied. There are however potential 193 scenarios where the number of Blocks cannot be given beforehand. 194 If the value is present, it should be verified by implementers: if 195 the value is untrue the behaviour is implementation-defined. 197 After the opening Dump tag, one or more subsections of Blocks must 198 follow. Finally, the complete SHF Dump ends with a closing Dump tag. 200 4.2 Block subsection 202 The Block subsection contains a Block tag and a number of data words 203 The Block tag includes the following attributes: 205 o name: A compulsory string of arbitrary length used by any 206 interested party to identify the specific Block. 207 o start_address: A compulsory 64 bit hexadecimal value representing 208 the start address in Bytes for the data in the Block. 209 o word_size: A compulsory 64 bit hexadecimal value representing the 210 number of Bytes (the width) of one Word of the data. 212 o length: A compulsory hexadecimal representation of an unsigned 213 64-bit integer indicating the number of Words following inside the 214 Block element. If this value turns out to be untrue, the Block 215 MUST be discarded. 216 o checksum: A compulsory hexadecimal representation of the 20 Byte 217 SHA-1 digest of the data in the Block. 219 The total size of the data in the Block (in bits) is given by the 220 expression (8 * word_size * length). The expression MUST NOT be 221 larger than (2^64)-1. 223 After the opening Block tag, a hexadecimal representation of the 224 actual data in the Block follows. Finally, the Block section ends 225 with a closing Block tag. 227 5. SHF rules and limits 229 There are several rules and limits in SHF: 230 o All attribute values representing an actual value and the data 231 MUST be in hexadecimal notation. The only attribute excluded from 232 this rule is the name attribute in the Dump and Block tags. This 233 restriction has been imposed for ease of reading the dump: a 234 reader shall not be uncertain about whether a figure is in hex 235 notation or not, and can always assume it is hexadecimal. 236 o All attribute values with the exception for the checksum MAY omit 237 leading zeros. Conversely, the checksum MUST NOT omit leading 238 zeros. 239 o The data represented in a Block MUST NOT be larger than (2^64)-1 240 bits. 241 o The size of a Word MUST NOT be larger than (2^64)-1 bits. This 242 implies that a Block with a Word defined to the maximum width can 243 not contain more than one Word. An SHF consumer shall assure that 244 it can handle a certain Word length before beginning to parse 245 blocks of an SHF Dump. Failure to do so may cause buffer 246 overflows and endanger the stability and security of the system 247 running the consuming application. 248 o The attribute values representing an actual value MUST be in "Big 249 Endian-format". This means that the most significant hexadecimal 250 digits are to be put to the left in a hexadecimal Word, address or 251 similar field, so that e.g. the address value 1234 represents the 252 address 1234 and not 3412. While some computing architectures may 253 be using Little Endian Words as their native format, it is the 254 responsibility of any SHF producer running on such an architecture 255 to swap the attribute values to a Big Endian format. The reverse 256 holds for a consumer receiving the Big Endian SHF attributes: if 257 the consumer is Little Endian, the values have to be swapped 258 around. 259 o The words inside a Dump MUST likewise be stored in a Big Endian 260 format if the word size is larger than one Byte. Here the same 261 need for swapping Bytes around may arise as mentioned in the 262 previous paragraph. 264 6. SHF DTD 266 The contents of the element named "block" and the attributes 267 "blocks", "address", "word_size" and "checksum" should only contain 268 the characters that are valid hexbyte sequences. These are: 270 whitespace ::= (#x20 | #x9 | #xC | #xD | #xA) 271 hexdigit ::= [0-9A-Fa-f] 272 hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)* 274 A parser reading in an SHF file should silently ignore any other 275 characters that (by mistake) appear in any of these elements or 276 attributes. These alien characters should be treated as if they did 277 not exist. Also note that "whitespace" has no semantic meaning; it 278 is only valid for the reason of improving the human readability of 279 the Dump. Whitespace may be altogether removed and the hexbyte 280 sequences concatenated if desired. Notice that the fact that word 281 size is to be given in a number of bytes implies that the number of 282 hexadecimal digits inside a block need to be even. Malformed blocks 283 should be ignored by implementations. 285 295 297 298 302 303 310 7. SHF examples 312 This section contains three different SHF examples, illustrating the 313 usage of SHF and the attributes in SHF. 315 The first example is a simple SHF Dump with a single Block of data: 317 318 319 322 41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72 323 65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a 324 325 327 The second example is a program in 6502 machine code residing at 328 memory address 0x1000, which calculates the 13 first fibonacci 329 numbers and stores them at 0x1101-0x110d: 331 332 333 335 a9 01 85 20 85 21 20 1e 10 20 1e 10 18 a5 21 aa 336 65 20 86 20 85 21 20 1e 10 c9 c8 90 ef 60 ae 00 337 11 a5 21 9d 00 11 ee 00 11 60 338 339 341 01 00 00 00 00 00 00 00 00 00 00 00 00 00 342 343 345 The final example contains a Block of 40-bit wide data: 347 348 349 351 00100 00200 00000 00090 00000 00036 00300 00400 352 00852 00250 00230 00858 00500 00600 014DC 00058 353 002A8 000B8 00700 00800 000B0 00192 00100 00000 354 00900 00A00 00000 0000A 40000 00000 00B00 00C00 355 00000 00000 00000 00001 00D00 00E00 00000 00100 356 0CCCC CCCCD 00F00 01000 00000 00010 80000 00000 357 00100 00790 00000 00234 359 360 362 8. SHF security considerations 364 The SHF format is a format for representing hexadecimal data that one 365 wants to transfer, manage or transform. The format itself does not 366 guarantee that the represented data is not falsely represented, 367 malicious or otherwise dangerous. 369 The data integrity of the SHF file as a whole is to be provided, if 370 needed, by means external to the SHF file, such as the generic 371 signing mechanism described by RFC 3275 [3]. 373 9. IANA Considerations 375 This section contains the registration information for the MIME type 376 to SHF. 378 o Registration: application/shf+xml 379 o MIME media type name: application 380 o MIME subtype name: shf+xml 381 o Required parameters: charset 383 Required parameters: charset 385 This parameter must exist and must be set to "UTF-8". No other 386 character sets are allowed for transporting SHF data. The character 387 set designator MUST be uppercase. 389 Encoding considerations 391 This media type may contain binary content; accordingly, when used 392 over a transport that does not permit binary transfer, an appropriate 393 encoding must be applied. 395 Security considerations 397 A hex Dump in itself has no other security considerations than what 398 applies for any other XML file. However the included binary data may 399 in decoded form contain any executable code for a target platform. 400 If additional security is desired, additional transport security 401 solutions may be applied. For target code contained in a hex Dump, 402 developers may want to include certificates, checksums and the like 403 in hexdump form for the target platform. Such uses are outside the 404 scope of this document and a matter of implementation. 406 Interoperability considerations 408 n/a 410 Published specification 412 This media type is a proper subset of the the XML 1.0 specification 413 [WWWXML]. One restriction is made: no entity references other than 414 the five predefined general entities references ("&", "<", ">", "'", 415 and """) and numeric entity references may be present. Neither the 416 "XML" declaration (e.g., ) nor the "DOCTYPE" declaration (e.g., ) 417 need be present. (XML fragments are allowed.) All other XML 1.0 418 instructions (e.g., CDATA blocks, processing instructions, and so on) 419 are allowed. 421 Applications which use this media type: any program or individual 422 wishing to make use of this XML 1.0 subset for hexdump exchange. 424 Additional information 426 o Magic number: There is no single initial Byte sequence that is 427 always present for SHF files 428 o File extension: shf 429 o Macintosh File Type code: none 431 Intended usage: COMMON. 433 Author/Change controller: this MIME transport type is controlled by 434 the IETF. 436 10. Extensions 438 The attributes of elements in the SHF XML format may be extended when 439 need arise. For example, certain applications will want to represent 440 executable code as a SHF Dump and may then need a execution start 441 address to be associated with certain Dump Blocks, so that the 442 address can be configured as a starting point for the CPU part of any 443 processor code present in the Block, as opposed to the raw data which 444 is already given a start address by way of the "address" attribute. 445 This can be done by extending the Block tag with a "start_address" 446 attribute. 448 Another possible scenario is when a dump is applied to a computer 449 system with several independent address spaces, such as a system with 450 two CPU:s with independent memories. In this case, a user may want 451 to add an "address_space" attribute. 453 As long as such new attributes are added, with no attributes being 454 removed or redefined, the resulting Dump shall be considered a valid 455 SHF Dump, transported using the application/xml+shf transport type, 456 and parsers unaware of the modified namespace shall silently ignore 457 any such extended attributes, or simply duplicate them from input to 458 output when processing an SHF file as a filter. The management of 459 such extended attributes is a matter of convention between different 460 classes of users and not a matter of the IETF. 462 11. Additional information 464 Contact for further information: c.f., the "Author's Address" section 465 of this memo. 467 Acknowledgments: The SMIL memory Dump was kindly provided by Sten 468 Henriksson at Lund University. Proofreading and good feedback on the 469 SHF draft was generously provided by Peter Lindgren, Tony Hansen, 470 Larry Masinter and Clive D.W. Feather. We also want to thank the 471 Applications area workgroup for their help during development. 473 12. References 475 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 476 Levels", BCP 14, RFC 2119, March 1997. 478 [2] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 479 (SHA1)", BCP 14, RFC 3174, September 2001. 481 [3] Eastlake, 3rd, D., Joseph, J. and D. David, "(Extensible Markup 482 Language) XML-Signature Syntax and Processing", BCP 14, 483 RFC 3275, March 2002. 485 [4] Makoto, M., Simon, S. and D. Dan, "(Extensible Markup Language) 486 XML Media Types", BCP 14, RFC 3023, January 2001. 488 Authors' Addresses 490 Joachim Strombergson 491 InformAsic AB 492 Hugo Grauers gata 5a 493 Gothenburg 411 33 494 SE 496 Phone: +46 31 68 54 90 497 Email: Joachim.Strombergson@InformAsic.com 498 URI: http://www.InformAsic.com/ 500 Linus Walleij 501 Lunds Tekniska Hogskola 502 Master Olofs Vag 24 503 Lund 224 66 504 SE 506 Phone: +46 703 193678 507 Email: triad@df.lth.se 508 Patrik Faltstrom 509 Cisco Systems Inc 510 Ledasa 511 273 71 Lovestad 512 Sweden 514 Email: paf@cisco.com 515 URI: http://www.cisco.com 517 Intellectual Property Statement 519 The IETF takes no position regarding the validity or scope of any 520 Intellectual Property Rights or other rights that might be claimed to 521 pertain to the implementation or use of the technology described in 522 this document or the extent to which any license under such rights 523 might or might not be available; nor does it represent that it has 524 made any independent effort to identify any such rights. Information 525 on the procedures with respect to rights in RFC documents can be 526 found in BCP 78 and BCP 79. 528 Copies of IPR disclosures made to the IETF Secretariat and any 529 assurances of licenses to be made available, or the result of an 530 attempt made to obtain a general license or permission for the use of 531 such proprietary rights by implementers or users of this 532 specification can be obtained from the IETF on-line IPR repository at 533 http://www.ietf.org/ipr. 535 The IETF invites any interested party to bring to its attention any 536 copyrights, patents or patent applications, or other proprietary 537 rights that may cover technology that may be required to implement 538 this standard. Please address the information to the IETF at 539 ietf-ipr@ietf.org. 541 Disclaimer of Validity 543 This document and the information contained herein are provided on an 544 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 545 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 546 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 547 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 548 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 549 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 551 Copyright Statement 553 Copyright (C) The Internet Society (2005). This document is subject 554 to the rights, licenses and restrictions contained in BCP 78, and 555 except as set forth therein, the authors retain all their rights. 557 Acknowledgment 559 Funding for the RFC Editor function is currently provided by the 560 Internet Society.