# Formats This document defines data structures and data formats. ## Overview Here we give an overview of our presentation language / serialization rules. All integers are represented by 64-bit unsigned integers in network byte order. Variable length lists have an integer specifying its length. Then each list item is enumerated. TODO: fixme. ## Items Every item type start with a versioned format specifier. Protocol version 1 uses format specifiers in the range 1--X. ### Request data structures Log endpoints that take input data use the following request data structures. #### `get_entries_v1` ``` 0 Format 8 16 24 +----------+----------------+----------------+ | 1 | Start Size | End Size | +----------+----------------+----------------+ uint64 uint64 uint64 ``` - Format is always 1 for items of type `get_entries_v1`. - Start size specifies the index of the first Merkle tree leaf to retrieve. - End size specifies the index of the last Merkle tree leaf to retrieve. #### `get_proof_by_hash_v1` ``` 0 Format 8 16 48 +----------+----------------+----------------+ | 2 | Tree size | Leaf hash | +----------+----------------+----------------+ uint64 uint64 fixed byte array ``` - Format is always 2 for items of type `get_proof_by_hash_v1`. - Leaf hash is computed as described in [RFC 6962/bis, §2.1.1](https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-35#section-2.1.1). - Tree size specifies which Merkle tree root inclusion should be proven for. #### `get_consistency_proof_v1` ``` 0 Format 8 16 24 +----------+----------------+----------------+ | 3 | Old size | New size | +----------+----------------+----------------+ uint64 uint64 uint64 ``` - Format is always 3 for items of type `get_consistency_proof_v1`. - Old size specifies the tree size of an older Merkle tree head. - New size specifies the tree size of a newer Merkle tree head. ### Proof and log data structures #### `inclusion_proof_v1` ``` --zero or more node hashes--> 0 Format 8 48 56 64 72 72+Length +----------+----------------+----------------+----------------+----------------+--------//--------+ | 4 | Identifier | Tree size | Leaf index | Length | Node hashes | +----------+----------------+----------------+----------------+----------------+--------//--------+ uint64 ed25519_v1 uint64 uint64 uint64 list body ``` - Format is always 4 for items of type `inclusion_proof_v1`. - Identifier identifies the log uniquely as an `ed25519_v1` item. - Tree size is the size of the Merkle tree that the proof is based on. - Leaf index is a zero-based index of the log entry that the proof is based on. - The remaining part is a list of node hashes. - Length specifies the full byte size of the list. It must be `32 * m`, where `m >= 0`. This means that an inclusion needs zero or more node hashes to be well-formed. - Node hash is a node hash in the Merkle tree that the proof is based on. Remark: the list of node hashes is generated and verified as in [RFC 6962/bis, §2.1.3](https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-35#section-2.1.3). #### `consistency_proof_v1` ``` --zero or more node hashes--> 0 Format 8 48 56 64 72 72+Length +----------+----------------+----------------+----------------+----------------+--------//--------+ | 5 | Identifier | Old size | New size | Length | Node hashes | +----------+----------------+----------------+----------------+----------------+--------//--------+ uint64 ed25519_v1 uint64 uint64 uint64 list body ``` - Format is always 5 for items of type `consistency_proof_v1`. - Identifier identifies the log uniquely as an `ed25519_v1` item. - Old size is the tree size of the older Merkle tree. - New size is the tree size of the newer Merkle tree. - The remaining part is a list of node hashes. - Length specifies the full byte size of the list. It must be `32 * m`, where `m >= 0`. This means that a consistenty proof needs zero or more node hashes to be well-formed. - Node hash is a node hash from the older or the newer Merkle tree. Remark: the list of node hashes is generated and verified as in [RFC 6962/bis, §2.1.4](https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-35#section-2.1.4). #### `signed_tree_head_v1` ``` ----one or more signature-identifier pairs-------> 0 Format 8 16 24 56 64 128 168 64+Length +----------+----------------+----------------+----------------+----------------+----------------+----------------+--//--+ | 6 | Timestamp | Tree size | Root hash | Length | Signature | Identifier | .... | +----------+----------------+----------------+----------------+----------------+----------------+----------------+--//--+ uint64 uint64 uint64 fixed byte array uint64 fixed byte array ed25519_v1 cont. list body ``` - Format is always 6 for items of type `signed_tree_head_v1`. - Timestamp is the time since the UNIX epoch (January 1, 1970 00:00:00 UTC) in milliseconds. - Tree size is the number of leaves in the current Merkle tree. - Root hash is the root hash of the current Merkle tree. - The remaining part is a list of signature-identifier pairs. - Length specifies the full byte size of the list. It must be `104 * m`, where `m > 1`. This means that a signed tree head needs at least one signature-identifier pair to be well-formed. - Signature is an Ed25519 signature over bytes 0--56. The signature is encodes as in [RFC 8032, §3.3](https://tools.ietf.org/html/rfc8032#section-3.3). - Identifier identifies the signer uniquely as an `ed25519_v1` item. Remark: there may be multiple signature-identifier pairs if the log is cosigned. #### `signed_checksum32_ed25519_v1` ``` 0 Format 8 40 56 56+Length 120+Length 160+Length +----------+----------------+----------------+-------//---------+----------------+--------//--------+ | 7 | Checksum | Length | Identifier | Signature | Namespace | +----------+----------------+----------------+-------//---------+----------------+--------//--------+ uint64 fixed byte array uint64 byte array fixed byte array ed25519_v1 ``` - Format is always 7 for items of type `signed_checksum32_ed25519_v1`. - Checksum is a 32-byte checksum that represents a data item of opaque type. - Length specified the full byte size of the following identifier. It must be larger than zero and less than 128. - Identifier identifies what the checksum represents. The aforementioned length constraint means that the identifier cannot be omitted or exceed 128 bytes. - Signature is an Ed25519 signature over bytes 0--56+Length. The signature is encodes as in [RFC 8032, §3.3](https://tools.ietf.org/html/rfc8032#section-3.3). - Namespace is an `ed25519_v1` item that identifies the signer uniquely. Remark: to keep this checksum entry as simple as possible it does not have a variable length checksum or any agility with regards to the signing namespace. This means that we need to have multiple leaf types that follow the pattern `signed_checksum{32,64}_namespace_v1`. ### Namespace data structures #### `ed25519_v1` ``` 0 Format 8 40 +----------+----------------+ | 8 | public key | +----------+----------------+ uint64 fixed byte array ``` - The format is always 8 for items of type `ed25519_v1`. - The public Ed25519 verification key is always 32 bytes. See encoding in [RFC 8032, §3.2](https://tools.ietf.org/html/rfc8032#section-3.2).