idnits 2.17.1 draft-cel-nfsv4-hash-tree-interchange-format-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 May 2022) is 721 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) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- No information found for draft-jchapweske-thex - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever, Ed. 3 Internet-Draft Oracle 4 Intended status: Standards Track 4 May 2022 5 Expires: 5 November 2022 7 Attestation of File Content using an X.509 Certificate 8 draft-cel-nfsv4-hash-tree-interchange-format-03 10 Abstract 12 This document describes a compact open format for transporting and 13 storing an abbreviated form of a cryptographically signed hash tree. 14 Receivers use this representation to reconstitute the hash tree and 15 verify the integrity of file content protected by that tree. 17 An X.509 certificate encapsulates and protects the hash tree metadata 18 and provides cryptographic provenance. Therefore this document 19 updates the Internet X.509 certificate profile specified in RFC 5280. 21 Note 23 Discussion of this draft occurs on the NFSv4 working group mailing 24 list (nfsv4@ietf.org), archived at 25 https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group 26 information is available at https://datatracker.ietf.org/wg/nfsv4/ 27 about/. 29 Submit suggestions and changes as pull requests at 30 https://github.com/chucklever/i-d-hash-tree-interchange-format. 31 Instructions are on that page. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 5 November 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Combining These Solutions . . . . . . . . . . . . . . . . 4 68 1.2. Efficient Content Verification . . . . . . . . . . . . . 4 69 1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 71 3. Hash Tree Metadata . . . . . . . . . . . . . . . . . . . . . 6 72 4. File Provenance Certificates . . . . . . . . . . . . . . . . 7 73 4.1. New Certificate Fields . . . . . . . . . . . . . . . . . 7 74 4.1.1. Root Hash . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.2. Divergence Factor . . . . . . . . . . . . . . . . . . 8 76 4.1.3. Tree Height . . . . . . . . . . . . . . . . . . . . . 8 77 4.1.4. Block Size . . . . . . . . . . . . . . . . . . . . . 8 78 4.1.5. Salt Value . . . . . . . . . . . . . . . . . . . . . 8 79 4.2. Extended Key Usage Values . . . . . . . . . . . . . . . . 8 80 4.3. Validating Certificates and their Signatures . . . . . . 9 81 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 6.1. X.509 Certificate Vulnerabilities . . . . . . . . . . . . 9 84 6.2. Hash Tree Collisions and Pre-Image Attacks . . . . . . . 10 85 6.3. File Content Vulnerabilities . . . . . . . . . . . . . . 10 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 7.1. Object Identifiers for Hash Tree Metadata . . . . . . . . 11 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 8.2. Informative References . . . . . . . . . . . . . . . . . 12 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Introduction 96 Linear hashing is a common technique for protecting the integrity of 97 data. A fixed-size hash, or digest, is computed over the bytes in a 98 data set using a deterministic and collision-resistant algorithm. An 99 example of such an algorithm is [FIPS.180-4]. 101 Filesystem designers often employ this technique to protect the 102 integrity of both individual files and filesystem metadata. For 103 instance, to protect an individual file's integrity, the filesystem 104 computes a digest from the beginning of its content to its end. The 105 filesystem then stores that digest along with the file content. The 106 integrity of that digest can be further protected by 107 cryptographically signing it. The filesystem recomputes the digest 108 when the file is retrieved and compares the locally-computed digest 109 with the saved digest to verify the file content. 111 Over time, linear hashing has proven to be an inadequate fit with the 112 way filesystems manage file content. A content verifier must read 113 the entire file to validate its digest. Reading whole files is not 114 onerous for small files, but reading a large file every time its 115 digest needs verification quickly becomes costly. 117 Filesystems read files from persistent storage in small pieces 118 (blocks) on demand to manage large files efficiently. When memory is 119 short, the system evicts these data blocks and then reads them again 120 when needed later. There is no physical guarantee that a subsequent 121 read of a particular block will give the same result as an earlier 122 one. Thus the initial verification of a file's becomes stale, 123 sometimes quickly. 125 To address this shortcoming, some have turned to hash trees 126 [Merkle88]. A hash tree leaf node contains the linear hash of a 127 portion of the protected content. Interior nodes in a hash tree 128 contain hashes of the nodes below them, up to the root node which 129 stores a hash of everything in the tree. Validating a leaf node 130 means validating only the portion of the file content protected by 131 that node and its parents in the hash tree. 133 Hash trees present a new challenge, however. Even when signed, a 134 single linear hash is the same size no matter how much content it 135 protects. The size of a hash tree, however, increases 136 logarithmically with the size of the content it protects. 138 Transporting and storing a hash tree can therefore be unwieldy. It 139 is particularly a problem for legacy storage formats that do not have 140 mechanisms to handle extensive amounts of variably-sized metadata. 141 Software distribution and packaging formats might not be flexible 142 enough to transport this possibly large amount of integrity data. 143 Backup mechanisms such as tar or rsync might be unable to handle 144 variably-sized metadata per file. 146 Moreover, we can readily extend network file storage protocols to 147 exchange a hash tree associated with every file. However, to support 148 such extensions, file servers and the ecosystems where they run must 149 be updated to manage and store this metadata. Thus it is not merely 150 an issue of enriching a file storage protocol to handle a new 151 metadata type. 153 1.1. Combining These Solutions 155 The root hash of a hash tree is itself a fixed-size piece of metadata 156 similar to a linear hash. The only disadvantage is that a verifier 157 must reconstitute the hash tree using the root hash and the file 158 content. However, if the verifier caches each tree on local trusted 159 storage, that is as good as storing the whole tree. The verifier can 160 then use the locally cached tree to validate portions of the file it 161 protects without reading each file repeatedly from remote or 162 untrusted durable storage. 164 To further insulate a root hash from unwanted change, an attestor can 165 protect it with a cryptographic signature. This cryptographic 166 protection then additionally covers the entire hash tree and the file 167 content it protects. 169 This integrity protection is independent of the file's storage format 170 and its underlying durable media. The file (and the root hash that 171 protects it) can be copied, transmitted over networks, or backed up 172 and restored while it remains protected end-to-end. 174 1.2. Efficient Content Verification 176 We now have a small fixed-size piece of metadata that can protect 177 potentially huge files. The trade-off is that the verifier must 178 reconstitute the hash tree during file installation or on-demand. 179 File systems or remote filesystem clients can store or cache 180 reconstituted trees in: 182 * Volatile or non-volatile memory 184 * A secure database 186 * A private directory on a local filesystem 188 * A named attribute or stream associated with the file 189 An easily accessible copy of a file's hash tree enables frequent 190 verification of file content. Frequent verification protects that 191 content against unwanted changes due to local storage or copying 192 errors, malicious activity, or data retention issues. When 193 verification is truly efficient, it can take place as often as during 194 every application read operation without a significant impact on 195 throughput. 197 The current document's unique contribution is the use of an X.509 v3 198 certificate to encapsulate the representation of a hash tree. The 199 purpose of encapsulation is to enable the hash tree metadata to be 200 exchanged and recognized broadly in the Internet community. 201 Therefore each certificate has to: 203 * Cryptographically protect the integrity of the hash tree metadata 205 * Bind the hash tree metadata to the authenticated identity of the 206 file content's attestor 208 * Provide for a broadly-supported standard set of cryptographic 209 algorithms 211 * Represent the hash tree data in a commonly recognized format that 212 is independent of storage media 214 Lastly, we note that a standard representation of hash tree metadata 215 enables opportunities for hardware offload of content verification. 217 1.3. Related Work 219 Granted in 1982, expired US patent 4309569 [Merkle82] covers the 220 construction of a tree of digests. Initially, these "Merkle trees" 221 helped improve the security of digital signatures. Later they were 222 used in storage integrity applications such as [Mykletun06]. They 223 have also found their way into other domains. [RFC6962], published 224 in 2013, uses Merkle trees to manage log auditing, for example. 226 A Tiger tree is a form of a hash tree often used by P2P protocols to 227 verify a file's integrity while in transit. The Tree Hash EXchange 228 format [THEX03] enables the transmission of whole Tiger trees in an 229 XML format. The current document proposes similar usage where a 230 sidecar hash tree protects file content but reduces the integrity 231 metadata's size. 233 2. Requirements Language 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 237 "OPTIONAL" in this document are to be interpreted as described in 238 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 239 capitals, as shown here. 241 3. Hash Tree Metadata 243 Reconstituting a hash tree (as opposed to building a more generic 244 directed graph of hashes) requires the protected content, a basic set 245 of metadata, and an understanding of how to use the metadata to 246 reconstitute the hash tree: 248 * The algorithm used to compute the tree's digests 250 * The divergence factor (defined as one for a hash list and two for 251 binary hash trees) 253 * The tree height (from root to the lowest leaf node) 255 * The block size covered by each leaf node in the tree 257 * An optional salt value 259 More research might be needed to cover recent innovations in hash 260 tree construction; in particular, the use of prefixes to prevent 261 second pre-image attacks. 263 The digest algorithm used to construct the hash tree MUST match the 264 digest algorithm used to sign the certificate. Thus if SHA-2 is used 265 to construct the hash tree, the certificate signature is created with 266 SHA-2. The verifier then uses SHA-2 when validating the certificate 267 signature and reconstituting the hash tree. The object identifiers 268 for the supported algorithms and the methods for encoding public key 269 materials (public key and parameters) are specified in [RFC3279], 270 [RFC4055], and [RFC4491]. 272 The block size value of the tree is specified in octets. For 273 example, if the block size is 4096, then each leaf node of the hash 274 tree digests 4096 octets of the protected file (aligned on 4096-octet 275 boundaries). 277 The internal nodes are digests constructed from the hashes of two 278 adjacent child nodes up to the root node (further detail needed 279 here). The tree's height is the distance, counted in nodes, from the 280 root to the lowest leaf node. 282 The leaf nodes are ordered (left to right) by the file offset of the 283 block they protect. Thus, the left-most leaf node represents the 284 first block in the file, and the right-most leaf node represents the 285 final block in the file. 287 An explanation of the salt value goes here. 289 Further, when computing each digest, an extra byte might be prefixed 290 to the pre-digested content to reduce the possibility of a second- 291 preimage attack. 293 4. File Provenance Certificates 295 | RFC Editor: In the following subsections, please replace the 296 | letters II once IANA has allocated this value. Furthermore, 297 | please remove this Editor's Note before this document is 298 | published. 300 X.509 certificates are specified in [X.509]. The current document 301 extends the Internet X.509 certificate profile specified in [RFC5280] 302 to represent file content protected by hash tree metadata. 304 File provenance certificates are end-entity certificates. The 305 certificate's signature identifies the attestor and cryptographically 306 protects the hash tree metadata. 308 The Subject field MUST be an empty sequence. The SubjectAltName list 309 carries a filename and the root hash, encoded in a new otherName 310 type-ID, shown below. The current document requests allocation of 311 this new type-ID on the id-on arc, defined in [RFC7299]. The 312 following subsections describe how the fields in this new type-ID are 313 used. 315 id-pkix OBJECT IDENTIFIER ::= 316 { iso(1) identified-organization(3) dod(6) internet(1) 317 security(5) mechanisms(5) pkix(7) } 318 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 319 id-on-fileContentAttestation OBJECT IDENTIFIER ::= { id-on II } 320 FileContentAttestation ::= SEQUENCE { 321 treeRootDigest OCTET STRING, 322 treeDivergenceFactor INTEGER (1..2), 323 treeHeight INTEGER, 324 treeBlockSize INTEGER, 325 treeSaltValue OCTET STRING 326 } 328 4.1. New Certificate Fields 329 4.1.1. Root Hash 331 The root digest field stores the digest that appears at the root of 332 the represented Merkle tree. The digest appears as a hexadecimal 333 integer. 335 4.1.2. Divergence Factor 337 The value in the tree divergence factor field represents the maximum 338 number of children nodes each node has in the represented Merkle 339 tree. A value of two, for example, means each node (except the leaf 340 nodes) has no more than two children. 342 4.1.3. Tree Height 344 The tree height field stores the distance from the represented Merkle 345 tree's root node to its lowest leaf node. A value of one, for 346 example, means the tree has a single level at the root. 348 4.1.4. Block Size 350 The block size field contains the number of file content bytes 351 represented by each digest (node) in the Merkle tree. A typical 352 value is 4096, meaning each node in the tree contains a digest of up 353 to 4096 bytes, starting on 4096-byte boundaries. 355 4.1.5. Salt Value 357 The tree salt value is a hexadecimal integer combined with the digest 358 values in some way that I have to look up. If the tree salt value is 359 zero, salting is not to be used when reconstituting the represented 360 Merkle tree. 362 4.2. Extended Key Usage Values 364 Section 4.2.1.12 of [RFC5280] specifies the extended key usage X.509 365 certificate extension. This extension, which may appear in end- 366 entity certificates, indicates one or more purposes for which the 367 certified public key may be used in addition to or in place of the 368 basic purposes indicated in the key usage extension. 370 The inclusion of the codeSigning value (id-kp-codeSigning) indicates 371 that the certificate has been issued for the purpose of allowing the 372 holder to verify the integrity and provenance of file content. 374 4.3. Validating Certificates and their Signatures 376 When validating a certificate containing hash tree metadata, 377 validation MUST include the verification rules per [RFC5280]. 379 The validator reconstitutes a hash tree using the presented file 380 content and the hash tree metadata in the certificate. If the root 381 hash of the reconstituted hash tree does not match the value 382 contained in the treeRootHash, then the validation fails. 384 5. Implementation Status 386 This section records the status of known implementations of the 387 protocol defined by this specification at the time of posting of this 388 Internet-Draft, and is based on a proposal described in [RFC7942]. 389 The description of implementations in this section is intended to 390 assist the IETF in its decision processes in progressing drafts to 391 RFCs. 393 Please note that the listing of any individual implementation here 394 does not imply endorsement by the IETF. Furthermore, no effort has 395 been spent to verify the information presented here that was supplied 396 by IETF contributors. This is not intended as, and must not be 397 construed to be, a catalog of available implementations or their 398 features. Readers are advised to note that other implementations may 399 exist. 401 There are no known implementations of the X.509 certificate 402 extensions described in the current document. 404 6. Security Considerations 406 It is important to note the narrow meaning of the digital signature 407 in X.509 certificates as defined in this document. That signature 408 connotes that the data content of the certificate has not changed 409 since the certificate was signed, and it identifies the signer 410 cryptographically. The signature does not confer any meaning or 411 guarantees other than the integrity of the certificate's data 412 content. 414 6.1. X.509 Certificate Vulnerabilities 416 The file content and hash tree can be unpacked and then resigned by 417 someone who participates in the same web of trust as the original 418 content creator. Verifiers should consult appropriate certificate 419 revocation databases as part of validating attestor signatures to 420 mitigate this form of attack. 422 6.2. Hash Tree Collisions and Pre-Image Attacks 424 A typical attack against digest algorithms is a collision attack. 425 The usual mitigation for this form of attack is choosing a hash 426 algorithm known to be strong. Implementers SHOULD choose amongst 427 digest algorithms that are known to be resistant to pre-image 428 attacks. See [RFC4270] for a discussion of attacks on digest 429 algorithms typically used in Internet protocols. 431 Hash trees are subject to a particular type of collision attack 432 called a "second pre-image attack". Digest values in intermediate 433 nodes in a hash tree are generated from lower nodes. Executing a 434 collision attack to replace a subtree with content that hashes to the 435 same value does not change the root hash value and is more manageable 436 than replacing all of a file's content. This kind of attack can 437 occur independently of the strength of the tree's hash algorithm. 438 The tree height is included in the signed metadata to mitigate this 439 form of attack. 441 6.3. File Content Vulnerabilities 443 There are two broad categories of attacks on mechanisms that protect 444 the integrity of file content: 446 Overt corruption An attacker makes the file's content dubious or 447 unusable (depending on the end system's security policies) by 448 corrupting either the file's content or its protective metadata in 449 a detectable manner. 451 Silent corruption An attacker alters the file's content and its 452 protective metadata in synchrony such that any changes remain 453 undetected. 455 The goal of the current document's mechanism is to turn as many 456 instances of the latter as possible into the former, which are more 457 likely to identify corrupted content before it is consumed. 459 7. IANA Considerations 461 | RFC Editor: In the following subsections, please replace RFC- 462 | TBD with the RFC number assigned to this document, and please 463 | replace II with the number assigned to this new type-ID. 464 | Furthermore, please remove this Editor's Note before this 465 | document is published. 467 7.1. Object Identifiers for Hash Tree Metadata 469 Following the "Specification Required" policy as defined in 470 Section 4.6 of [RFC8126], the author of the current document requests 471 several new type-ID OIDs on the id-on arc defined in Section 2 of 472 [RFC7299]. The registry for this arc is maintained at the following 473 URL: https://www.iana.org/assignments/smi-numbers/smi- 474 numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8 476 Following [RFC5280], the current document requests newly-defined 477 objects in the following subsections using 1988 ASN.1 notation. 479 id-pkix OBJECT IDENTIFIER ::= 480 { iso(1) identified-organization(3) dod(6) internet(1) 481 security(5) mechanisms(5) pkix(7) } 482 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 483 id-on-fileContentAttestation OBJECT IDENTIFIER ::= { id-on II } 485 IANA should use the current document (RFC-TBD) as the reference for 486 these new entries. 488 8. References 490 8.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 498 Identifiers for the Internet X.509 Public Key 499 Infrastructure Certificate and Certificate Revocation List 500 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 501 2002, . 503 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 504 Algorithms and Identifiers for RSA Cryptography for use in 505 the Internet X.509 Public Key Infrastructure Certificate 506 and Certificate Revocation List (CRL) Profile", RFC 4055, 507 DOI 10.17487/RFC4055, June 2005, 508 . 510 [RFC4491] Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the GOST 511 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 512 Algorithms with the Internet X.509 Public Key 513 Infrastructure Certificate and CRL Profile", RFC 4491, 514 DOI 10.17487/RFC4491, May 2006, 515 . 517 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 518 Housley, R., and W. Polk, "Internet X.509 Public Key 519 Infrastructure Certificate and Certificate Revocation List 520 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 521 . 523 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 524 Writing an IANA Considerations Section in RFCs", BCP 26, 525 RFC 8126, DOI 10.17487/RFC8126, June 2017, 526 . 528 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 529 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 530 May 2017, . 532 [X.509] International Telephone and Telegraph Consultative 533 Committee, "ITU-T X.509 - Information technology - The 534 Directory: Public-key and attribute certificate 535 frameworks.", January 2019. 537 8.2. Informative References 539 [FIPS.180-4] 540 Dang, Q., "Secure Hash Standard", National Institute of 541 Standards and Technology report, 542 DOI 10.6028/nist.fips.180-4, July 2015, 543 . 545 [Merkle82] Merkle, R., "Method of providing digital signatures", 546 January 1982. 548 [Merkle88] Merkle, R., "A Digital Signature Based on a Conventional 549 Encryption Function", Advances in Cryptology - CRYPTO 550 '87 pp. 369-378, DOI 10.1007/3-540-48184-2_32, 1988, 551 . 553 [Mykletun06] 554 Mykletun, E., Narasimha, M., and G. Tsudik, 555 "Authentication and integrity in outsourced databases", 556 ACM Transactions on Storage Vol. 2, pp. 107-138, 557 DOI 10.1145/1149976.1149977, May 2006, 558 . 560 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 561 Hashes in Internet Protocols", RFC 4270, 562 DOI 10.17487/RFC4270, November 2005, 563 . 565 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 566 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 567 . 569 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 570 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 571 . 573 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 574 Code: The Implementation Status Section", BCP 205, 575 RFC 7942, DOI 10.17487/RFC7942, July 2016, 576 . 578 [THEX03] Chapweske, J. and G. Mohr, "Tree Hash EXchange format 579 (THEX)", January 2003, . 582 Acknowledgments 584 The editor is grateful to Bill Baker, Eric Biggers, James Bottomley, 585 Russ Housley, Benjamin Kaduk, Rick Macklem, Greg Marsden, Paul Moore, 586 Martin Thomson, and Mimi Zohar for their input and support. 588 Finally, special thanks to Transport Area Directors Martin Duke and 589 Zaheduzzaman Sarker, NFSV4 Working Group Chairs David Noveck and 590 Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for 591 their guidance and oversight. 593 Author's Address 595 Charles Lever (editor) 596 Oracle Corporation 597 United States of America 598 Email: chuck.lever@oracle.com