idnits 2.17.1 draft-hallambaker-jbcd-container-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2018) is 2208 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 898 -- Looks like a reference, but probably isn't: '2' on line 901 -- Looks like a reference, but probably isn't: '3' on line 904 -- Looks like a reference, but probably isn't: '4' on line 907 == Missing Reference: 'EOF' is mentioned on line 656, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational April 11, 2018 5 Expires: October 13, 2018 7 JBCD Container 8 draft-hallambaker-jbcd-container-02 10 Abstract 12 This document is also available online at 13 http://mathmesh.com/Documents/draft-hallambaker-jbcd-container.html 14 [1] . 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 13, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Related Specifications . . . . . . . . . . . . . . . . . 5 54 3.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 55 4. Container Format . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Container Profile . . . . . . . . . . . . . . . . . . . . 6 57 4.1.1. Index Profiles . . . . . . . . . . . . . . . . . . . 6 58 4.1.2. Content Profiles . . . . . . . . . . . . . . . . . . 7 59 5. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.1. Container Metadata . . . . . . . . . . . . . . . . . . . 8 61 5.2. Container Data . . . . . . . . . . . . . . . . . . . . . 8 62 5.3. Content Metadata . . . . . . . . . . . . . . . . . . . . 8 63 5.3.1. Payload Signature . . . . . . . . . . . . . . . . . . 8 64 5.3.2. Payload Encryption . . . . . . . . . . . . . . . . . 9 65 5.4. Content Payload . . . . . . . . . . . . . . . . . . . . . 9 66 6. Index Mechanisms . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.2. Position Index . . . . . . . . . . . . . . . . . . . . . 10 69 6.3. Metadata Index . . . . . . . . . . . . . . . . . . . . . 10 70 7. Integrity Mechanisms . . . . . . . . . . . . . . . . . . . . 10 71 7.1. Digest Chain calculation . . . . . . . . . . . . . . . . 10 72 7.2. Binary Merkle tree calculation . . . . . . . . . . . . . 11 73 8. Cryptographic Enhancement . . . . . . . . . . . . . . . . . . 11 74 8.1. Content Frame . . . . . . . . . . . . . . . . . . . . . . 11 75 8.2. Cryptographic Singleton Container . . . . . . . . . . . . 12 76 8.3. Cryptographic Multi-Frame, Unitary content . . . . . . . 12 77 8.4. Cryptographic Multi-Frame, Serial content . . . . . . . . 12 78 9. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. Fast open with random access . . . . . . . . . . . . . . 12 80 9.2. Partitioning of very large data sets across hosts . . . . 13 81 9.3. Filtering and redaction . . . . . . . . . . . . . . . . . 13 82 9.4. Encryption of large data blocks . . . . . . . . . . . . . 13 83 9.5. Concurrent Writes . . . . . . . . . . . . . . . . . . . . 14 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 13. Appendix A: Examples and Test Vectors . . . . . . . . . . . . 14 88 13.1. Simple container . . . . . . . . . . . . . . . . . . . . 14 89 13.2. Payload and chain digests . . . . . . . . . . . . . . . 15 90 13.3. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . 17 91 13.4. Signed container . . . . . . . . . . . . . . . . . . . . 19 92 13.5. Encrypted container . . . . . . . . . . . . . . . . . . 19 93 14. Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 15. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 97 16.2. Informative References . . . . . . . . . . . . . . . . . 20 98 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Abstract 103 This document describes JBCD Container, a message and file syntax 104 that allows a sequence of data frames to be represented with 105 cryptographic integrity, signature and encryption enhancements to be 106 constructed in an append only format. The format supports data 107 integrity checks using digest chains and Merkle trees. The simplest 108 supports efficient append only write operations and efficient read 109 operations in either the forward or reverse direction. Support for 110 efficient random-access reads may be provided through the use of 111 binary trees or index records appended to the end of the file. 113 2. Introduction 115 JBCD Container is a message and file syntax that allows a sequence of 116 data frames to be represented with cryptographic integrity, 117 signature, and encryption enhancements to be constructed in an append 118 only format. JBCD Container was developed in response to needs that 119 arose out of the design of the Mathematical Mesh 120 [draft-hallambaker-jsonbcd] . It is built on the binary encodings of 121 JSON data objects, JSON-B and JSON-C [draft-hallambaker-jsonbcd] . 122 These requirements include: 124 o Recording Mesh transactions in persistent storage. 126 o Synchronizing transaction logs between hosts. 128 o Representing message archives (aka mail spool) 130 o Signing and encrypting single data items. 132 The features supported by JBCD Container include: 134 o The format is append only, thus providing for rapid write 135 operations and enabling the use of technologies that provide 136 atomic transactions. 138 o All length and index values support the use of integers of at 139 least 64 bits. 141 o Data frames may be of variable length. 143 o Data frames may be read in either direction. This allows the last 144 n frames to be read as efficiently as the first n frames. 146 o Appending a data frame to an existing file is efficient taking no 147 more than log2 (n) operations. 149 o A binary tree index MAY be constructed on an incremental basis, 150 allowing random access to the nth record in the file in log2 (n) 151 operations. 153 o An index MAY be appended to an existing container to allow random 154 access to the nth record in the file in log2 (n) operations 156 o Permits the use of modern data encodings (e.g. JSON [RFC7159] ). 158 o Supports digital signature and public key operations on the 159 payloads of individual data frames. 161 o Data frame content (i.e. payload data) may be overwritten without 162 invalidating the integrity of any other frame. This allows 163 content to be expunged in exigent circumstances (court order, 164 regulatory, confidentiality breach, etc.) without compromising the 165 integrity of the rest of the data in the container. 167 Many file proprietary formats are in use that support some or all of 168 these capabilities but only a handful have public, let alone open, 169 standards. JBCD Container is designed to provide a superset of the 170 capabilities of existing message and file syntaxes, including: 172 o Cryptographic Message Syntax [RFC5652] defines a syntax used to 173 digitally sign, digest, authenticate, or encrypt arbitrary message 174 content. 176 o The.ZIP File Format specification [ZIPFILE] developed by Phil 177 Katz. 179 o The BitCoin Block chain [BLOCKCHAIN] . 181 o JSON Web Encryption and JSON Web Signature 183 Attempting to make use of these specifications in a layered fashion 184 would require at least three separate encoders and introduce 185 unnecessary complexity. 187 Every data format represents a compromise between different concerns, 188 in particular: 190 Data Storage The space required to record data in the encoding. 192 Memory Overhead The additional volatile storage (RAM) required to 193 maintain indexes etc. to support efficient retrieval operations. 195 Number of Operations The number of operations required to retrieve 196 data from or append data to an existing encoded sequence. 198 While the cost of storage of all types has declined rapidly over the 199 past decades, so has the amount of data to be stored. JBCD Container 200 represents a pragmatic balance of these considerations for current 201 technology. In particular, since payload volumes are likely to be 202 very large, memory and operational efficiency are considered higher 203 priorities than data volume. 205 3. Definitions 207 3.1. Related Specifications 209 JBCD Container makes use of the following related standards and 210 specifications. 212 Encoding Content frame headers are encoded using JavaScript Object 213 Notation (JSON) [RFC7159] , JSON-B or JSON-C 214 [draft-hallambaker-jsonbcd] . 216 Cryptography The encryption and signature schemes used are based on 217 JSON Web Signature [RFC7515] and JSON Web Encryption [RFC7516] . 219 3.2. Requirements Language 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in RFC 2119 [RFC2119] . 225 4. Container Format 227 A JBCD Container consists of a series of JBCD Frames. Each Frame 228 consists of a non-empty sequence of JBCD records. 230 A JBCD frame consists of a forward length indicator, the framed data 231 and a reverse length indicator. The reverse length indicator is 232 written out backwards to allow the frame to be read in the reverse 233 direction: 235 [[This figure is not viewable in this format. The figure is 236 available at http://mathmesh.com/Documents/draft-hallambaker-jbcd- 237 container.html [2].]] 239 JBCD Bidirectional Frame 241 When first reading an existing file, an application will typically 242 read the first frame and the last frame (if the container has more 243 than one frame). This allows the reader to quickly determine the 244 format(s) used by the container, the number of frames in the 245 container and the location of any index frames (if present). 247 The container format is designed to support creation of write-once 248 and append-only file formats. Each frame SHOULD be written as an 249 atomic operation. 251 The first frame in a container and the first record in a frame have 252 special roles that are described in this document. 254 o Container data MUST NOT occur in any place other than the first 255 frame in the container or the first record in a frame. 257 o The first frame in a container describes the container format 258 options. These include the range of encoding options for frame 259 metadata supported and the container profiles to which the 260 container conforms. 262 o The first record in a frame MUST NOT contain payload data 264 4.1. Container Profile 266 A key objective of the JBCD Container format is that the simplest 267 possible reader be capable of reading any container file albeit with 268 possibly reduced performance. 270 A Container MAY conform to one or more profiles. Conforming to a 271 profile typically requires a writer to provide additional information 272 when writing a file but does not require a reader to interpret it 273 unless use of a feature (e.g. authentication) that depends on the 274 additional information is required. 276 4.1.1. Index Profiles 278 The following profiles are currently defined: 280 Tree Frame headers contain IndexPosition entries that specify the 281 start position of previous frames. This enables efficient random 282 access to any frame in the file. 284 Digest Frame headers contain PayloadDigest entries that specify the 285 digest value of the corresponding payload data in that frame. 287 Chain Frame headers contain ChainDigest entries that link each frame 288 to the preceding frame. 290 Merkle Frame headers contain TreeDigestPartial and TreeDigestFinal 291 entries linking all the frames in the container in a binary Merkle 292 Tree. 294 The use of Chain and Merkle Trees for integrity checks is described 295 below. 297 The use of Tree and Index frames is described below. 299 4.1.2. Content Profiles 301 The following profiles are currently defined: 303 Singleton A container with exactly one content frame. A container 304 declared as a singleton frame cannot have additional content 305 frames appended (but metadata frames may be) 307 Multi A container whose payload data is limited to content frames. 308 A container declared as a multi container may contain 0, 1 or more 309 content frames. 311 Archive A multi-container whose payload data is limited to content 312 frames whose last frame contains a metadata index for the content 313 frames in the container. 315 Unitary A multi-container in which each frame represents exactly one 316 payload object. 318 Serial A multi-container in which payload objects MAY be split 319 across multiple consecutive frames. 321 Interleaved A multi-container in which payload objects MAY be split 322 across multiple frames which may in turn be interleaved with 323 frames containing other payload objects in complete or partial 324 form. 326 5. Data Types 328 5.1. Container Metadata 330 Header Encoding format 332 5.2. Container Data 334 Archive Index 336 5.3. Content Metadata 338 Frame headers MAY contain content metadata parameters. 340 ContentType The IANA content type for the payload data 342 Paths One or more file or URI paths at which the payload data is to 343 be located. Paths MAY be relative or global. 345 Labels One or more labels applied to the frame to be used for 346 filtering purposes. 348 KeyValues One or more key value pairs providing index terms for the 349 frame. 351 5.3.1. Payload Signature 353 Payload data MAY be signed JSON Web Signature [RFC7515] . 355 Signatures are specified by the Signatures parameter in the content 356 header. The data that the signature is calculated over is defined by 357 the typ parameter of the Signature as follows. 359 Payload The frame payload data. 361 PayloadDigest The value of the PayloadDigest parameter 363 ChainDigest The value of the ChainDigest parameter 365 TreeDigestFinal The value of the TreeDigestFinal parameter 367 If the typ parameter is absent, the value Payload is implied. 369 A frame MAY contain multiple signatures created with the same signing 370 key and different typ values. 372 The use of signatures over chain and tree digest values permit 373 multiple frames to be validated using a single signature verification 374 operation. 376 5.3.2. Payload Encryption 378 Payload data MAY be encrypted using JSON Web Encryption [RFC7516] . 380 The payload data is encrypted under a session key whose encrypted 381 value is specified by the EncryptedKey entry. The encryption key for 382 the EncryptedKey is in turn specified by key exchange information 383 provided in a JWE Recipients object that is placed in the frame 384 header of either the frame that contains the encrypted payload data 385 or an earlier frame whose file position is specified by a 386 ExchangePosition entry. 388 Use of EncryptedKey entries allows a container to contain multiple 389 data segments encrypted using the same key agreement parameters. 391 5.4. Content Payload 393 Complete 395 Incremental 397 6. Index Mechanisms 399 An index may be appended to an existing file at any time. Since the 400 use of bidirectional frames makes reading the last record is as 401 efficient as reading the first, the last record in an indexed file is 402 usually either the index itself or a pointer to the last index. 404 An index frame consists of a frame header 406 Use of index frames provides read access to any record in the file in 407 O(1) operations but attempting to compiling a complete index with 408 every write incurs an O(n) penalty on write for both operations and 409 storage. Accordingly, random read access to a file while it is being 410 written is better supported using an index tree. 412 6.1. Tree 414 Binary search is supported by means of the TreePosition parameter 415 specified in the FrameHeader. This parameter specifies the value of 416 the immediately preceding apex. 418 Calculation of the immediately preceding apex is most easily 419 described by representing the array index in binary with base of 1 420 (rather than 0). An array index that is a power of 2 (2, 4, 8, 16, 421 etc.) will be the apex of a complete tree. Every other array index 422 has the value of the sum of a set of powers of 2 and the immediately 423 preceding apex will be the value of the next smallest power of 2 in 424 the sum. 426 For example, to find the immediately preceding apex for frame 5, we 427 add 1 to get 6. 6 = 4 + 2, so we ignore the 2 and the preceding frame 428 is 4. 430 The values of Tree Position are shown for the first 8 frames in 431 figure xx below: 433 [[This figure is not viewable in this format. The figure is 434 available at http://mathmesh.com/Documents/draft-hallambaker-jbcd- 435 container.html [3].]] 437 Merkle Tree Integrity check 439 An algorithm for efficiently calculating the immediately preceding 440 apex is provided in Appendix C. 442 6.2. Position Index 444 Contains a table of index, position pairs pointing to prior locations 445 in the file. 447 6.3. Metadata Index 449 Contains a list of IndexMeta entries. Each entry contains a metadata 450 description and a list of frame indexes (not positions) of frames 451 that match the description. 453 7. Integrity Mechanisms 455 Frame sequences in a JWC container MAY be protected against a frame 456 insertion attack by means of a digest chain, a binary Merkle tree or 457 both. 459 7.1. Digest Chain calculation 461 A digest chain is simple to implement but can only be verified if the 462 full chain of values is known. Appending a frame to the chain has 463 O(1) complexity but verification has O(n) complexity: 465 [[This figure is not viewable in this format. The figure is 466 available at http://mathmesh.com/Documents/draft-hallambaker-jbcd- 467 container.html [4].]] 469 Hash chain integrity check 471 The value of the chain digest for the the first frame (frame 0) is 472 H(IV+H(Payload0)), where IV is an initialization vector consisting of 473 a string of zero bytes and payloadn is the sequence of payload data 474 bytes for frame n 476 The value of the chain digest for frame n is H(H(Payloadn-1 477 +H(Payloadn)), where A+B stands for concatenation of the byte 478 sequences A and B. 480 7.2. Binary Merkle tree calculation 482 The tree index mechanism describe earlier may be used to implement a 483 binary Merkle tree. The value TreeDigest specifies the apex value of 484 the tree for that node. 486 Appending a frame to the chain has O(log2n) complexity provided that 487 the container format supports at least the binary tree index. 488 Verifying a chain has O(log2 n) complexity, provided that the set of 489 necessary digest inputs is known. 491 To calculate the value of the tree digest for a node, we first 492 calculate the values of all the sub trees that have their apex at 493 that node and then calculate the digest of that value and the 494 immediately preceding local apex. 496 8. Cryptographic Enhancement 498 8.1. Content Frame 500 Record 0 The key exchange keys under which the successive records 501 are encrypted. 503 Record 1 The encrypted content metadata. This frame MAY be empty 505 Record 2 The encrypted payload data. 507 Record 3 The encrypted signature data. This frame MAY be empty or 508 omitted. 510 8.2. Cryptographic Singleton Container 512 Frame 0 Describes the format of the container. 514 Frame 1 The content frame 516 8.3. Cryptographic Multi-Frame, Unitary content 518 This format is as for the singleton container except that Frame 0 may 519 be followed by any number of content frames 521 Frame 0 Describes the format of the container. 523 Frame 1 The first content frame 525 Frame 2 The second content frame 527 ? 529 ? 531 Frame n The nth content frame. 533 8.4. Cryptographic Multi-Frame, Serial content 535 9. Further Work 537 The container format is intended to be the basis of future work to 538 support: 540 o Very large container sizes (larger than the size of the host's 541 memory). 543 o Partitioning of very large data sets across multiple hosts with 544 parallel append. 546 o Fault tolerance 548 9.1. Fast open with random access 550 The container format is designed to be capable of supporting 551 efficient random access to frames in containers considerably larger 552 than the processing memory of the host computer without the need to 553 pre-load indexes. 555 A combination of the following strategies is being considered: 557 o Use memory mapped file views to container data to optimize random 558 access times while controlling memory use and time taken to 559 construct memory views. 561 o When the container is first bound, use the binary tree index data 562 in TreePosition parameters to support random access operations 563 until index building is complete. 565 o Perform Index building operations as a non-blocking background 566 task. 568 9.2. Partitioning of very large data sets across hosts 570 While storage devices capable of storing tends of Tb of data with 571 RAID redundancy are commonplace, it is generally desirable that there 572 be at least as many CPU cores as disks. Thus, partitioning of data 573 sets across multiple hosts becomes desirable for throughput even if a 574 single host could handle the storage requirement. 576 9.3. Filtering and redaction 578 In the types of applications envisaged in the Mesh, almost every data 579 set may be reduced to collections that are bound to a single account. 580 While it is obviously desirable that a user's mail messages (for 581 example) be replicated across multiple machines to provide fault 582 tolerance, fragmenting the copies of this data set across multiple 583 machines should be avoided unless the data volumes are so large as to 584 require it. 586 9.4. Encryption of large data blocks 588 The encoding scheme is 64-bit clean throughout and thus supports 589 containers and frames as large as 18 petabytes. Larger data volumes 590 could be supported through use of 128-bit integer pointers but even 591 if the technology to support such data volumes were developed, it is 592 highly unlikely anyone would want to represent data sets anywhere 593 near this size in a serial format. 595 Due to limitations in the design of the encryption schemes that may 596 be used (e.g. AES-GCM), the maximum encrypted frame size is 64GB. 597 While this is not currently a major concern for encryption of 598 individual data files, it is easy to see situations in which an 599 archive of encrypted files could exceed that amount. One possibility 600 would be to define a modification to AES -GCM which caused the 601 encryption key to be incremented by a fixed amount after encrypting a 602 certain amount of data, though this might well present implementation 603 challenges unless the maximum data block size was chosen to be 604 deliberately small so as to force code paths to be exercised. 606 Another possibility would be to limit the size of encrypted data 607 frames by requiring the frame pointer to be no larger than 32 bits 608 and require larger data items to be represented as a sequence of 609 frames. 611 9.5. Concurrent Writes 613 The container format deliberately avoids support for concurrent write 614 operations. Should this be desirable, some mechanism must be 615 provided to cache write fragments to an intermediate file and then 616 consolidate them for writing to the master log. 618 10. Security Considerations 620 11. IANA Considerations 622 12. Acknowledgements 624 13. Appendix A: Examples and Test Vectors 626 The data payloads in all the following examples are identical, only 627 the authentication and/or encryption is different. 629 o Frame 1..n consists of 300 bytes being the byte sequence 00, 01, 630 02, etc. repeating after 256 bytes. 632 For conciseness, the wire format is omitted for examples after the 633 first, except where the data payload has been transformed, (i.e. 634 encrypted). 636 13.1. Simple container 638 Here the simple container: 640 f4 2c 641 f0 2a 642 7b 0a 20 20 22 49 6e 64 65 78 22 3a 20 30 2c 0a 643 20 20 22 43 6f 6e 74 61 69 6e 65 72 54 79 70 65 644 22 3a 20 22 4c 69 73 74 22 7d 645 2c f4 646 f5 01 40 647 f0 0f 648 7b 0a 20 20 22 49 6e 64 65 78 22 3a 20 31 7d 649 f1 01 2c 650 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 651 10 11 12 13 14 15 16 17 18 19 1a 1b 652 ... 653 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 654 20 21 22 23 24 25 26 27 28 29 2a 2b 655 40 01 f5 656 [EOF] 658 Figure 1 660 The header values are: 662 Frame 0 664 { 665 "ContainerHeader": { 666 "Index": 0, 667 "ContainerType": "List"}} 669 Figure 2 671 Frame 1 673 { 674 "ContainerHeader": { 675 "Index": 1}} 677 Figure 3 679 13.2. Payload and chain digests 681 Frame 0 682 { 683 "ContainerHeader": { 684 "Index": 0, 685 "PayloadDigest": " 686 z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_SpIdNs6c5H0NE8XYXysP-DGNKHfuwv 687 Y7kxvUdBeoGlODJ6-SfaPg", 688 "ChainDigest": " 689 FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpLAb2JbsO1YQnJolmowXAYHhkOGY0 690 kg3jrKNTjds0myf4Dw1sdg"}} 692 Figure 4 694 Frame 1 696 { 697 "ContainerHeader": { 698 "Index": 1, 699 "PayloadDigest": " 700 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 701 NXpZ2iY96zTRI229zaJ5sw", 702 "ChainDigest": " 703 7JaijhBvQUOjBiO1_Zt6NtJil8iB0rW9HeM_4iYooc_AaAfutlF0LLVY6PO7INB- 704 eztypyEqVzgMil9JkjtRGQ"}} 706 Figure 5 708 Frame 2 710 { 711 "ContainerHeader": { 712 "Index": 2, 713 "PayloadDigest": " 714 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 715 NXpZ2iY96zTRI229zaJ5sw", 716 "ChainDigest": " 717 wJZFYd61nntCJ0Bv80l6-Cn-sR2u3iD0zCRjOLxje8dsKIuUnP4X1mgeNenNDBdX 718 ysrFs3vVAqkC-hfSAPF0Aw"}} 720 Figure 6 722 Frame 3 723 { 724 "ContainerHeader": { 725 "Index": 3, 726 "PayloadDigest": " 727 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 728 NXpZ2iY96zTRI229zaJ5sw", 729 "ChainDigest": " 730 RORNZxIcM23cZtXPh9vuHhkgiGa_O4a0ZiU0ku2OK4dB974clvh5F0VZsX7IwVBa 731 yAG2nDTdqhyZ-qOnTRiumA"}} 733 Figure 7 735 13.3. Merkle Tree 737 Frame 0 739 { 740 "ContainerHeader": { 741 "Index": 0, 742 "TreePosition": 0, 743 "PayloadDigest": " 744 z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_SpIdNs6c5H0NE8XYXysP-DGNKHfuwv 745 Y7kxvUdBeoGlODJ6-SfaPg", 746 "TreeDigest": " 747 FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpLAb2JbsO1YQnJolmowXAYHhkOGY0 748 kg3jrKNTjds0myf4Dw1sdg"}} 750 Figure 8 752 Frame 1 754 { 755 "ContainerHeader": { 756 "Index": 1, 757 "TreePosition": 0, 758 "PayloadDigest": " 759 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 760 NXpZ2iY96zTRI229zaJ5sw", 761 "TreeDigest": " 762 fPTYagAvSDP_755jpFUs-Wq6cgvtr5vrFwW-E12vsrbq1ReNsGzp-V2XqzFPiWaU 763 ckACPjegD7ioe1bGzxoWQQ"}} 765 Figure 9 767 Frame 2 768 { 769 "ContainerHeader": { 770 "Index": 2, 771 "TreePosition": 263, 772 "PayloadDigest": " 773 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 774 NXpZ2iY96zTRI229zaJ5sw", 775 "TreeDigest": " 776 7fyKKQNLGEeHX1oCsV8NtOdPm615SkDnM1vkcexx2tOuVd5kkZIdLdsWRCLic9lu 777 TSsUN6D6_-c-8ftbhL9dJg"}} 779 Figure 10 781 Frame 3 783 { 784 "ContainerHeader": { 785 "Index": 3, 786 "TreePosition": 263, 787 "PayloadDigest": " 788 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 789 NXpZ2iY96zTRI229zaJ5sw", 790 "TreeDigest": " 791 b9ca9Pv-6fxUg-V3ulOhhRngxebkZCxyDmWhQUYeADmSvvPbjMcNTUJxdDpKlMPr 792 DBInSWMChinsc5s9Tv4byw"}} 794 Figure 11 796 Frame 4 798 { 799 "ContainerHeader": { 800 "Index": 4, 801 "TreePosition": 1398, 802 "PayloadDigest": " 803 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 804 NXpZ2iY96zTRI229zaJ5sw", 805 "TreeDigest": " 806 g1hQeWJgDlNoTSGfMb6NhQk5-p6iaAI2_GiAhBM-F2Cp3UvJ7AR_bC2Drp5YElGX 807 AzC2K5qZ30l7j2D-jqykFw"}} 809 Figure 12 811 Frame 5 812 { 813 "ContainerHeader": { 814 "Index": 5, 815 "TreePosition": 1398, 816 "PayloadDigest": " 817 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 818 NXpZ2iY96zTRI229zaJ5sw", 819 "TreeDigest": " 820 p89BhjJAgMMoSrOmot6oaBGa6Dgz-zogZjZ9mm1Iz4yLHxm97nWAIBaZFiC1XkuC 821 oP-tr3tag_rHoZhgQV8_PQ"}} 823 Figure 13 825 Frame 6 827 { 828 "ContainerHeader": { 829 "Index": 6, 830 "TreePosition": 2537, 831 "PayloadDigest": " 832 8dyi62d7MDJlsLm6_w4GEgKBjzXBRwppu6qbtmAl6UjZDlZeaWQlBsYhOu88-ekp 833 NXpZ2iY96zTRI229zaJ5sw", 834 "TreeDigest": " 835 HEA7EeUGfSjZqjmN3PDp0FVbnixBBXfSQAYm_rNPHVWJVMDu3SfmxKvN_yBTtMXk 836 -Jad9cyXDKsecLNHLyoQWg"}} 838 Figure 14 840 13.4. Signed container 842 13.5. Encrypted container 844 14. Appendix C 846 15. Appendix B 847 public long PreviousFrame (long Frame) { 848 long x2 = Frame + 1; 849 long d = 1; 851 while (x2 > 0) { 852 if ((x2 & 1) == 1) { 853 return x2 == 1 ? (d / 2) - 1 : Frame - d; 854 } 855 d = d * 2; 856 x2 = x2 / 2; 857 } 858 return 0; 859 } 861 Figure 15 863 16. References 865 16.1. Normative References 867 [draft-hallambaker-jsonbcd] 868 Hallam-Baker, P., "Binary Encodings for JavaScript Object 869 Notation: JSON-B, JSON-C, JSON-D", draft-hallambaker- 870 jsonbcd-10 (work in progress), April 2018. 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997. 876 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 877 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 878 2014. 880 [RFC7515] "[Reference Not Found!]". 882 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 883 RFC 7516, DOI 10.17487/RFC7516, May 2015. 885 16.2. Informative References 887 [BLOCKCHAIN] 888 Chain.com, "Blockchain Specification". 890 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 891 RFC 5652, DOI 10.17487/RFC5652, September 2009. 893 [ZIPFILE] PKWARE Inc, "APPNOTE.TXT - .ZIP File Format 894 Specification", October 2014. 896 16.3. URIs 898 [1] http://mathmesh.com/Documents/draft-hallambaker-jbcd- 899 container.html 901 [2] http://mathmesh.com/Documents/draft-hallambaker-jbcd- 902 container.html 904 [3] http://mathmesh.com/Documents/draft-hallambaker-jbcd- 905 container.html 907 [4] http://mathmesh.com/Documents/draft-hallambaker-jbcd- 908 container.html 910 Author's Address 912 Phillip Hallam-Baker 913 Comodo Group Inc. 915 Email: philliph@comodo.com