< draft-cel-nfsv4-hash-tree-interchange-format-02.txt   draft-cel-nfsv4-hash-tree-interchange-format-03.txt >
Network File System Version 4 C. Lever, Ed. Network File System Version 4 C. Lever, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track 8 November 2021 Intended status: Standards Track 4 May 2022
Expires: 12 May 2022 Expires: 5 November 2022
Attestation of File Content using an X.509 Certificate Attestation of File Content using an X.509 Certificate
draft-cel-nfsv4-hash-tree-interchange-format-02 draft-cel-nfsv4-hash-tree-interchange-format-03
Abstract Abstract
This document describes a compact open format for transporting and This document describes a compact open format for transporting and
storing an abbreviated form of a cryptographically signed hash tree. storing an abbreviated form of a cryptographically signed hash tree.
Receivers use this representation to reconstitute the hash tree and Receivers use this representation to reconstitute the hash tree and
verify the integrity of file content protected by that tree. verify the integrity of file content protected by that tree.
An X.509 certificate encapsulates and protects the hash tree metadata An X.509 certificate encapsulates and protects the hash tree metadata
and provides cryptographic provenance. Therefore this document and provides cryptographic provenance. Therefore this document
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 May 2022. This Internet-Draft will expire on 5 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Combining These Solutions . . . . . . . . . . . . . . . . 4 1.1. Combining These Solutions . . . . . . . . . . . . . . . . 4
1.2. Efficient Content Verification . . . . . . . . . . . . . 4 1.2. Efficient Content Verification . . . . . . . . . . . . . 4
1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Hash Tree Metadata . . . . . . . . . . . . . . . . . . . . . 6 3. Hash Tree Metadata . . . . . . . . . . . . . . . . . . . . . 6
4. File Provenance Certificates . . . . . . . . . . . . . . . . 7 4. File Provenance Certificates . . . . . . . . . . . . . . . . 7
4.1. Root Hash . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. New Certificate Fields . . . . . . . . . . . . . . . . . 7
4.2. Divergence Factor . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Root Hash . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Tree Height . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Divergence Factor . . . . . . . . . . . . . . . . . . 8
4.4. Block Size . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Tree Height . . . . . . . . . . . . . . . . . . . . . 8
4.5. Salt Value . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.4. Block Size . . . . . . . . . . . . . . . . . . . . . 8
4.6. Validating Certificates and their Signatures . . . . . . 8 4.1.5. Salt Value . . . . . . . . . . . . . . . . . . . . . 8
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 4.2. Extended Key Usage Values . . . . . . . . . . . . . . . . 8
4.3. Validating Certificates and their Signatures . . . . . . 9
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. X.509 Certificate Vulnerabilities . . . . . . . . . . . . 9 6.1. X.509 Certificate Vulnerabilities . . . . . . . . . . . . 9
6.2. Hash Tree Collisions and Pre-Image Attacks . . . . . . . 9 6.2. Hash Tree Collisions and Pre-Image Attacks . . . . . . . 10
6.3. File Content Vulnerabilities . . . . . . . . . . . . . . 10 6.3. File Content Vulnerabilities . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Object Identifiers for Hash Tree Metadata . . . . . . . . 10 7.1. Object Identifiers for Hash Tree Metadata . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Linear hashing is a common technique for protecting the integrity of Linear hashing is a common technique for protecting the integrity of
data. A fixed-size hash, or digest, is computed over the bytes in a data. A fixed-size hash, or digest, is computed over the bytes in a
data set using a deterministic and collision-resistant algorithm. An data set using a deterministic and collision-resistant algorithm. An
example of such an algorithm is [FIPS.180-4]. example of such an algorithm is [FIPS.180-4].
Filesystem designers often employ this technique to protect the Filesystem designers often employ this technique to protect the
skipping to change at page 7, line 44 skipping to change at page 7, line 51
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-fileContentAttestation OBJECT IDENTIFIER ::= { id-on II } id-on-fileContentAttestation OBJECT IDENTIFIER ::= { id-on II }
FileContentAttestation ::= SEQUENCE { FileContentAttestation ::= SEQUENCE {
treeRootDigest OCTET STRING, treeRootDigest OCTET STRING,
treeDivergenceFactor INTEGER (1..2), treeDivergenceFactor INTEGER (1..2),
treeHeight INTEGER, treeHeight INTEGER,
treeBlockSize INTEGER, treeBlockSize INTEGER,
treeSaltValue OCTET STRING treeSaltValue OCTET STRING
} }
4.1. Root Hash 4.1. New Certificate Fields
4.1.1. Root Hash
The root digest field stores the digest that appears at the root of The root digest field stores the digest that appears at the root of
the represented Merkle tree. The digest appears as a hexadecimal the represented Merkle tree. The digest appears as a hexadecimal
integer. integer.
4.2. Divergence Factor 4.1.2. Divergence Factor
The value in the tree divergence factor field represents the maximum The value in the tree divergence factor field represents the maximum
number of children nodes each node has in the represented Merkle number of children nodes each node has in the represented Merkle
tree. A value of two, for example, means each node (except the leaf tree. A value of two, for example, means each node (except the leaf
nodes) has no more than two children. nodes) has no more than two children.
4.3. Tree Height 4.1.3. Tree Height
The tree height field stores the distance from the represented Merkle The tree height field stores the distance from the represented Merkle
tree's root node to its lowest leaf node. A value of one, for tree's root node to its lowest leaf node. A value of one, for
example, means the tree has a single level at the root. example, means the tree has a single level at the root.
4.4. Block Size 4.1.4. Block Size
The block size field contains the number of file content bytes The block size field contains the number of file content bytes
represented by each digest (node) in the Merkle tree. A typical represented by each digest (node) in the Merkle tree. A typical
value is 4096, meaning each node in the tree contains a digest of up value is 4096, meaning each node in the tree contains a digest of up
to 4096 bytes, starting on 4096-byte boundaries. to 4096 bytes, starting on 4096-byte boundaries.
4.5. Salt Value 4.1.5. Salt Value
The tree salt value is a hexadecimal integer combined with the digest The tree salt value is a hexadecimal integer combined with the digest
values in some way that I have to look up. If the tree salt value is values in some way that I have to look up. If the tree salt value is
zero, salting is not to be used when reconstituting the represented zero, salting is not to be used when reconstituting the represented
Merkle tree. Merkle tree.
4.6. Validating Certificates and their Signatures 4.2. Extended Key Usage Values
Section 4.2.1.12 of [RFC5280] specifies the extended key usage X.509
certificate extension. This extension, which may appear in end-
entity certificates, indicates one or more purposes for which the
certified public key may be used in addition to or in place of the
basic purposes indicated in the key usage extension.
The inclusion of the codeSigning value (id-kp-codeSigning) indicates
that the certificate has been issued for the purpose of allowing the
holder to verify the integrity and provenance of file content.
4.3. Validating Certificates and their Signatures
When validating a certificate containing hash tree metadata, When validating a certificate containing hash tree metadata,
validation MUST include the verification rules per [RFC5280]. validation MUST include the verification rules per [RFC5280].
The validator reconstitutes a hash tree using the presented file The validator reconstitutes a hash tree using the presented file
content and the hash tree metadata in the certificate. If the root content and the hash tree metadata in the certificate. If the root
hash of the reconstituted hash tree does not match the value hash of the reconstituted hash tree does not match the value
contained in the treeRootHash, then the validation fails. contained in the treeRootHash, then the validation fails.
5. Implementation Status 5. Implementation Status
 End of changes. 17 change blocks. 
28 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/