Skip to content

spec(4.1.1): let "all Merkle tree constructions" mean all #342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
imran-siddique merged 1 commit into from
Aug 26, 2026
Merged

spec(4.1.1): let "all Merkle tree constructions" mean all #342

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions spec/agent-manifest-spec-v0.2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1224,9 +1224,9 @@ The standard cryptographic profile uses the following primitives:

##### 4.1.1 Merkle Tree Domain Separation <!-- CHANGED: CRYPTO-005 - explicit domain separation per RFC 9162 to prevent length-extension attacks -->

All Merkle tree constructions in this specification (corpus `merkle_root`, tool `catalog_hash`) MUST use the RFC 9162 / RFC 6962 domain-separated hashing convention:
All Merkle tree constructions in this specification MUST use the RFC 9162 / RFC 6962 domain-separated hashing convention: <!-- CHANGED: #337 - the parenthetical named two of five constructions and went stale twice; the per-section definitions are now the single source -->

- Leaf hash: `SHA-256(0x00 || leaf_data)` where `leaf_data` is the per-item input bytes as defined in the relevant section (section 3.2.3 for catalog, section 3.2.5.1 for corpus).
- Leaf hash: `SHA-256(0x00 || leaf_data)`, where `leaf_data` is defined by the section specifying that construction.
- Interior node hash: `SHA-256(0x01 || left_child_hash || right_child_hash)`.

The `0x00` and `0x01` domain separation prefixes prevent second-preimage attacks that are possible with plain Merkle-Damgard SHA-256 trees lacking domain separation (as demonstrated in the Certificate Transparency literature). This construction is referenced in RFC 9162 Section 2.1.
Expand Down