Offline Review-Packet Integrity, Provenance, and Replay-Resistant Transport

Full report

On this page

Research Cutoff Date: July 2026 The exchange of self-contained review packets across decentralized, offline, or air-gapped environments presents a profound architectural challenge. When clients cannot authenticate against a centralized repository, the packet itself must provide unforgeable mathematical proof of its structural integrity, chronological state, and cryptographic provenance. Documented evidence and institutional assertions confirm that building robust, offline-verifiable data structures requires mitigating myriad vulnerabilities, from metadata non-determinism and serialization discrepancies to path traversal exploits and topological replay attacks1. Expert interpretation underscores that addressing these vulnerabilities requires a strictly defensive posture. A resilient offline review packet must decouple substantive payload data from transport metadata, enforce canonical serialization to achieve byte-for-byte determinism, and employ directed acyclic graphs to resolve state supersession without relying on live network resolution4.

Foundational Security Primitives

In distributed systems design, there is often a dangerous conflation of distinct cryptographic properties. Expert interpretation mandates the strict separation of integrity, authenticity, confidentiality, and encryption, as each addresses a fundamentally different threat vector and relies on distinct mathematical operations3. Integrity guarantees that a dataset has not been altered, truncated, or corrupted in transit or at rest. It is entirely agnostic to the identity of the sender. Documented evidence shows that integrity relies on cryptographic hashing algorithms, predominantly SHA-256, which produce deterministic, fixed-length digests from arbitrary inputs3. If a single bit within the payload shifts, the resulting digest diverges entirely, instantly flagging a violation. However, institutional assertions highlight that while an archive may possess integrity—evidenced by a matching hash—it provides no proof of origin. An attacker intercepting the packet could simply replace the payload, calculate a new hash, and forward it8. Authenticity answers the question of origin and provenance, ensuring that a trusted cryptographic identity vouched for the specific state of the file7. Emerging practices rely on asymmetric cryptography, where the packet's originator hashes the manifest and encrypts that hash using a private key (creating a digital signature). The recipient utilizes the originator's widely distributed public key to decrypt the hash and compares it to their own calculation7. If they match, authenticity is proven. It is critical to preserve the distinction between technical validation and substantive endorsement; cryptographic authenticity validates that a specific key signed the payload, but it does not inherently endorse the substantive truth, morality, or accuracy of the payload's contents7. Confidentiality ensures that unauthorized entities cannot interpret the contents of the payload, restricting visibility strictly to intended recipients. Encryption is the mathematical mechanism utilized to achieve confidentiality, transforming plaintext into ciphertext using symmetric algorithms (e.g., AES-256) or hybrid asymmetric systems. An offline review packet may possess integrity and authenticity while remaining entirely unencrypted, meaning its contents are publicly readable but tamper-evident.

Comparative Analysis of Standards and Institutional Practices

To establish a resilient conceptual packet specification, it is necessary to evaluate and compare existing standards governing archival transport, data canonicalization, and supply-chain integrity. Documented evidence reveals distinct approaches across various domains, ranging from federal digital preservation to software provenance and electronic identities.

Expert interpretation of these standards indicates a convergence around decoupled integrity and payload structures. BagIt isolates payloads into a data/ directory while housing cryptographic hashes in the root10. However, BagIt natively lacks cryptographic signature enforcement, explicitly deferring authentication to external protocols11. ASiC takes a more rigid approach, relying on the ZIP specification and advanced Public Key Infrastructure (PKI) semantics to create Extended (ASiC-E) and Simple (ASiC-S) containers14. While ASiC provides deep authenticity, its reliance on heavy XML or CMS signature formats can be brittle for lightweight, JSON-native application layers. The W3C Data Integrity standard addresses this by using RDF Dataset Canonicalization (URDNA2015) to prepare datasets for signing, but RDF graphs are often overly complex for simple review payloads22. Conversely, SLSA utilizes simpler JSON-based in-toto statements for provenance, strongly linking inputs to outputs, but SLSA is inherently designed for build pipelines rather than peer-to-peer review packet exchange17. By synthesizing these approaches, a robust hybrid emerges: integrating the strict archival determinism of Reproducible Builds, the canonicalization logic of RFC 8785, the structural simplicity of BagIt, and the supply chain rigor of NIST SP 800-161 yields the most effective defense against manipulation in offline environments.

Canonical Data Representation

A review packet's integrity is intrinsically tied to its internal data representations. If two independently functioning systems serialize the identical logical structure into different byte streams, their cryptographic hashes will fail to match, leading to false integrity violations and broken signatures1. Documented evidence demonstrates that standard JSON is not deterministic; object key order, number formatting, and whitespace vary significantly across serializers, programming languages, and runtime versions1.

JSON Canonicalization Scheme (RFC 8785)

To eliminate this non-determinism, emerging practices heavily rely on the JSON Canonicalization Scheme (JCS), formalized as RFC 87851. JCS mandates that all JSON data conform to the Internet JSON (I-JSON) subset, ensuring that the payload remains a valid JSON object even after being cryptographically signed4. JCS addresses several critical serialization discrepancies:

• Property Sorting and UTF-16: JCS requires the deterministic lexicographical sorting of property names4. Contested claims historically favored sorting by UTF-8 bytes for performance reasons, but JCS explicitly mandates sorting based on UTF-16 code units36. This distinction is critical for supplementary-plane characters, such as emojis or historic scripts. A character like U+10000 sorts before U+E000 in UTF-16, but after it in UTF-837. Failure to use UTF-16 code-unit ordering guarantees canonicalization mismatches and invalidates signatures across platforms35.
• Malformed UTF-8 and Lone Surrogates: Systems must aggressively reject lone UTF-16 surrogates (e.g., U+DEAD) and non-characters. These represent invalid Unicode and introduce interoperability failures during signature verification, as different decoders may strip or replace them with replacement characters (U+FFFD), altering the byte stream1.
• Duplicate Data Keys: Standard JSON parsers typically implement a "last-value-wins" policy for duplicate keys, though ECMA-404 does not strictly enforce this behavior38. Under RFC 8785, objects must absolutely not exhibit duplicate property names; parsers must terminate with an error (e.g., DUPLICATE\_KEY) to prevent semantic confusion, where a verifier validates one value but the application processes another4.
• NULs and Non-finite Values: JSON does not support non-finite floating-point numbers like NaN or Infinity natively, leading to undefined serialization behaviors4. RFC 8785 mandates that all numeric data be expressible as IEEE 754 double-precision values. Furthermore, it dictates strict formatting rules, utilizing the Ryū algorithm or equivalent ECMAScript-compatible formatting to guarantee that scientific notation and decimal outputs are minimal and identical across architectures4.

Unicode Normalization and Case-Folding Collisions

When offline review packets include attachments or reference external paths in their manifests, Unicode normalization becomes a critical vector for evasion and shadow-payload attacks. Filesystem implementations handle Unicode inconsistently. Institutional assertions point out that Apple's APFS historically enforced normalization on disk, whereas NTFS (Windows) and ext4 (Linux) generally treat file paths as opaque byte strings, leading to severe cross-platform validation discrepancies40. If a review packet manifest references an attachment named resume.pdf, a malicious actor might include a visually identical file using a confusable Unicode character—for example, substituting the Latin 'e' (U+0065) with a Cyrillic 'е' (U+0435). To a human reviewer, the filenames appear identical, but to a cryptographic hashing algorithm, they are entirely distinct files. Expert interpretation mandates strict adherence to Unicode Technical Standard (UTS) 39 regarding confusable detection41. A resilient review packet must normalize all attachment identifiers to Unicode Normalization Form C (NFC) and perform case-folding collision checks during manifest generation and validation. The system must implement skeleton-matching algorithms as defined in UTS 39; if two attachments normalize to the same string or trigger a skeleton-matching collision, the packet must be instantly rejected to prevent an attacker from smuggling a shadow payload past the integrity checks41.

Archive Determinism and Safety

When generating the transport layer—typically a ZIP or TAR archive—the archiver itself introduces metadata non-determinism. To achieve reproducible hashes for the outer envelope, the packaging mechanism must enforce strict determinism and defend against extraction-layer vulnerabilities.

Deterministic Archive Ordering and Timestamps

Institutional assertions from the Reproducible Builds project highlight that metadata, particularly file modification times (mtime), destroys archive reproducibility27. If the same source files are zipped on two different days, the resulting ZIP file hashes will diverge completely27. An offline review packet must utilize the SOURCE\_DATE\_EPOCH standard, which defines a fixed UNIX timestamp—either the commit time of the payload or 0 for January 1, 197026. Archivers must clamp all internal timestamps to this epoch, set internal user and group IDs (UID/GID) to a fixed value (typically 0 for root), and sort all directory and file entries lexicographically before appending them to the archive structure28.

Unsafe Paths, Symbolic Links, and Hidden Files

The extraction of hierarchical archives is highly vulnerable to Path Traversal, often termed the "Zip Slip" vulnerability (e.g., CVE-2018-1002200)2. Documented evidence shows that if an archive contains relative path sequences (e.g., ../../etc/passwd) or absolute paths (e.g., C:\\Windows\\System32\\payload.exe), a naive extraction utility will trust the embedded path and write files outside the intended target directory. This can lead to arbitrary file overwrite, remote code execution, and total system compromise44. To defend against malformed input, the extraction logic must:

1. Verify that the canonical, fully resolved path of the extracted file resides strictly within the bounds of the designated temporary extraction sandbox2.

2. Refuse to process symbolic links (symlinks) or hard links within the archive45. Symlinks can be manipulated to point to critical system directories, redirecting subsequent file writes to unintended disk locations45.

3. Reject hidden files and directories (e.g., .git/, .env) unless explicitly required by the minimal integrity profile, preventing configuration overlay attacks2.

4. Enforce strict deduplication; if an archive contains multiple file headers with the identical path, it must be flagged as malformed to prevent extraction-time race conditions and unpredictable last-value-wins behavior45.

Archive-Size and Compression-Ratio Limits

To protect offline verification nodes from resource exhaustion, strict bounds must be enforced during extraction. Emerging practices dictate that an application must track the cumulative size of extracted files, terminating the process immediately if the total uncompressed size exceeds a predetermined limit (e.g., 64 MiB), or if the compression ratio (uncompressed size divided by compressed size) exceeds a safe threshold (e.g., 10:1)1. This defends against "zip bombs," which are heavily compressed files containing gigabytes of repetitive data designed to exhaust memory and disk space upon decompression2. Furthermore, nested archives (archives within archives) should be strictly bounded or prohibited entirely to prevent recursive decompression attacks.

Provenance and Verification Workflows

The fundamental principle of offline verification is that the packet must contain all the cryptographic evidence necessary to prove its own legitimacy without requiring a round-trip to a centralized authority or repository.

Member Whitelists and Manifest Consistency

Drawing heavily from the BagIt specification, a review packet must contain a manifest that acts as a strict cryptographic whitelist10. The manifest explicitly lists every permitted file within the packet payload alongside its expected SHA-256 digest10. If the archive contains any file not listed in the manifest (an orphaned file), or if a file listed in the manifest is missing from the archive, the entire packet must be marked invalid8. This strict bijection ensures that attackers cannot silently append malicious scripts, nor can they remove context-critical attachments that might alter the reviewer's understanding of the submission3.

Attachment Hashes and Media-Type Controls

While JSON canonicalization secures the structured metadata, external binary attachments—such as images, PDFs, and diagnostic logs—must be secured via detached cryptographic digests. Each attachment must have its SHA-256 hash explicitly embedded within the canonicalized JSON envelope8. Furthermore, strict media-type controls must be enforced. If the manifest declares an attachment as application/pdf, the verifier must optionally validate the file's magic bytes to ensure it is not a disguised executable. Advanced frameworks, like PDF/A-3, allow for hybrid archiving by embedding arbitrary file types (XML, CSV) within the PDF itself, offering another layer of structural integrity for documents requiring visual rendering alongside machine-readable data19.

Non-Developer Verification Workflow

A core requirement for decentralized transport is the ability for non-developers and system administrators to verify packets using ubiquitous, built-in operating system tools, avoiding reliance on proprietary software or opaque validation portals. The workflow leverages standard shell commands:

1. Integrity Check: The user extracts the packet to an isolated sandbox directory. Utilizing standard Linux utilities, they execute sha256sum \-c manifest-sha256.txt3. This command reads the manifest and validates the digest of every referenced file in a single pass3.

2. Authenticity Check: The user validates the detached signature over the manifest using OpenSSL or GnuPG. With a trusted public key previously distributed via out-of-band channels, running a command such as openssl dgst \-sha256 \-verify pubkey.pem \-signature manifest.sig manifest-sha256.txt confirms that the verified cryptographic identity authored the precise state of the manifest7.

3. Visual Confirmation: A successful output ("Verified OK" or "Good signature") indicates the packet is structurally and cryptographically sound7.

State Supersession and Replay Resistance

Because offline review packets are self-contained and easily copied, they are highly vulnerable to replay attacks. In these scenarios, a valid but outdated packet is resubmitted to an offline node to overwrite newer data, reverse a decision, or trigger duplicate processing.

Taxonomies of Duplication and Replay

Contested claims in distributed systems engineering often confuse duplicate payloads with intentional replay attacks. Defensive architectures must differentiate between three distinct tiers of duplication:

• Exact-Byte Replay: The adversary intercepts and submits a bit-for-bit identical archive49. This can be caught highly efficiently at the ingress boundary by maintaining a Bloom filter or simple Least Recently Used (LRU) cache of recently seen outer archive SHA-256 hashes49.
• Formatting-Only Duplicates: An adversary alters the whitespace, modifies the archive compression ratio, injects arbitrary comments, or changes the SOURCE\_DATE\_EPOCH to alter the outer archive hash, while the internal substantive data remains entirely identical34. Because the outer hash changes, this bypasses the Bloom filter. The defense relies on extracting the packet and evaluating the canonical JSON hash of the inner payload; if the canonical payload hash matches a known record, it is rejected as a formatting duplicate51.
• Semantic Duplicate Submissions: A more sophisticated attack involves semantic duplicates, where the attacker generates a new packet with a fresh timestamp or cryptographic nonce, but the actual substantive content (e.g., the text of a review, the parameters of an approved configuration) is identical to a prior submission. Detecting this requires application-level logic that isolates the substantive fields from the metadata fields, generating a "substantive digest" for comparison.

Correction, Withdrawal, and Branching Supersession

Review workflows are inherently nonlinear; documents are frequently corrected, withdrawn, or replaced entirely. This necessitates a cryptographic supersession model. Expert interpretation suggests that every review packet must declare an explicit supersedes field containing the target packet's digest. When packet B supersedes packet A, a directed edge is created in the state history. If packet C also attempts to supersede packet A concurrently, a "branching supersession" occurs. The system must flag this divergence for manual conflict resolution, as decentralized nodes lack a central coordinator to instantly elect a canonical head52.

Cycle Detection in Directed Acyclic Graphs (DAGs)

If a decentralized node processes packets out of order, or if a sophisticated adversary attempts to corrupt the revision history, they may submit a packet that creates a topological loop (e.g., Packet A supersedes Packet B, which supersedes Packet C, which attempts to supersede Packet A). The revision history of review packets must form a strictly Directed Acyclic Graph (DAG)6. During offline validation, the verification node must traverse the supersession chain and apply rigorous cycle detection algorithms. Utilizing Kahn's Algorithm for topological sorting or Tarjan's Algorithm for identifying strongly connected components allows the node to detect loops in [Figure omitted from source export] time complexity5. If a cycle is detected, the entire involved packet chain is rendered topologically invalid and quarantined54. Vector clocks can also be employed to track partial causality and assist in resolving temporal ordering disputes across disjoint nodes52.

Metadata Leakage and Privacy

When submitting review packets—particularly in scenarios involving blind peer review, sensitive audits, or whistleblower disclosures—metadata leakage is a critical threat. The payload itself may be sanitized, but the digital exhaust left by software tooling can compromise privacy.

Mitigating Metadata Leakage

Review packets frequently contain PDFs, images, or archives that harbor invisible metadata, such as EXIF data (GPS coordinates, camera models), author names, software versions, and operating system identifiers. During the offline packaging phase, the packet generation utility must aggressively strip this extraneous metadata. PDF files must adhere to minimal structures, stripping author and creator tags while maintaining structural integrity21. Image files must have EXIF headers zeroed out. The JSON payload must be audited for implicit environmental leakage, such as local IP addresses or workstation hostnames.

Public-Safe Versus Private Receipts

When a verified node successfully processes a packet, it generates a receipt. A "private receipt" typically contains the full canonicalized payload, the signatures, and the submission timestamps, making it highly sensitive. If exposed, it reveals the entire transaction. A "public-safe receipt," however, utilizes cryptographic blinding to prove possession without revealing knowledge. Emerging practices involve generating a blinded commitment—a cryptographic hash of the payload concatenated with a high-entropy blinding factor (nonce) generated by the submitter57. This allows the submitter to possess proof of submission that can be mathematically verified later by revealing the nonce, without exposing the payload's content to the public or the broader network59.

Architecting the Packet Specification

Based on the exhaustive synthesis of the preceding standards, a resilient conceptual packet specification is outlined below.

Conceptual Packet Specification

A highly secure offline review packet follows a modified BagIt hierarchy wrapped in a deterministic Zip format, clamping all metadata to the SOURCE\_DATE\_EPOCH: review-packet-v1.zip (Strict lexicographical sort, fixed UID/GID) ├── manifest-sha256.txt \# Whitelist of all files with SHA-256 hashes ├── manifest.sig \# Detached signature over manifest-sha256.txt ├── payload.json \# Canonicalized JCS (RFC 8785\) metadata and assertions └── attachments/ \# Directory containing external resources ├── document.pdf \# Stripped of metadata, hashed in payload.json └── evidence.jpg \# EXIF stripped, hashed in payload.json

Minimum Integrity Profile vs. Higher-Assurance Signed Profile

Threat Models and Decision Matrices

To operationalize the defenses detailed above, strict taxonomies and decision matrices are required to ensure that software implementations behave predictably under duress.

Defensive Threat Model

Replay Decision Matrix

Failure Taxonomy

A robust system must not fail silently. When a review packet is rejected, the resulting failure code must fall into a deterministic taxonomy, enabling human operators to diagnose pipeline issues without compromising the security of the offline node.

Checklists and Implementation Guidelines

Privacy Checklist

• \[ \] Assess all attached binary media (PDF, JPEG, PNG) and execute metadata-stripping utilities (e.g., ExifTool routines) prior to archiving.
• \[ \] Verify that no filesystem metadata (file owners, groups, local modification times) is preserved in the ZIP headers; enforce SOURCE\_DATE\_EPOCH.
• \[ \] Ensure receipt generation utilizes blinded commitments rather than exposing raw plaintext hashes57.
• \[ \] Scrub the JSON payload for implicit environmental leakage (e.g., local IP addresses, workstation hostnames).

Accessibility Checklist (WCAG 2.2)

While offline review packets operate at the machine-to-machine protocol layer, the output artifacts often generate human-readable reports. Based on WCAG 2.2 guidelines63:

• \[ \] Ensure that offline package report documentation is rendered with appropriate semantic HTML or PDF/A-1a tags to preserve screen-reader compatibility21.
• \[ \] Verify that any failure taxonomy output provides high-contrast, text-based reasoning without relying purely on color-coded error states.
• \[ \] Provide keyboard-navigable structural manifests for non-developer verification workflows.
• Note: A bounded search regarding specific WCAG criteria for raw offline byte-level payload archives yielded NOT\_RETRIEVED, indicating that accessibility requirements apply primarily to the rendered diagnostic output rather than the underlying data structures.

Prioritized Recommendations

Based on the exhaustive synthesis of standards, cryptographic principles, and threat models, the following prioritized recommendations are provided for architecting offline review-packet transport systems:

1. Mandate JSON Canonicalization (RFC 8785\): Transition away from ad-hoc JSON serialization immediately. Enforcing strict UTF-16 lexicographical sorting, surrogate rejection, and IEEE 754 number formatting is non-negotiable for reproducible cryptographic hashing across disparate platforms4.

2. Enforce Safe Archive Extraction Limits: Protect offline nodes from Zip Slip and Zip Bomb attacks by enforcing strict canonical path resolution checks, stripping symlinks, and implementing hard memory/disk bounds (e.g., 64 MiB total, 10:1 compression ratio) during the extraction phase2.

3. Implement Topological DAG Cycle Detection: Treat all document revisions, withdrawals, and supersessions as a mathematical directed graph. Utilize Kahn's or Tarjan's algorithm to actively prevent cyclic dependencies that could permanently corrupt the offline node's state database5.

4. Adopt the SOURCE\_DATE\_EPOCH Paradigm: Ensure that every archive generated clamps its internal timestamps and filesystem metadata to a deterministic variable. This allows the transport layer to achieve the exact-byte determinism required for rapid, edge-layer replay detection using Bloom filters26.

5. Utilize Detached Manifests for Whitelisting: Follow the BagIt and ASiC philosophies by decoupling the substantive data files from the cryptographic manifest12. This separation of concerns establishes a strict whitelist, prevents shadow-payload injection, and allows for independent verification workflows using native CLI tools, fostering trust and operational transparency across non-developer user bases3.

Works cited

1. json-canon: A Strict RFC 8785 Implementation in Go for Deterministic JSON, https://dev.to/lenny321/json-canon-a-strict-rfc-8785-implementation-in-go-for-deterministic-json-3mfg

2. Zip Slip Vulnerability in Archive Extraction \- Sourcery.ai, https://www.sourcery.ai/vulnerabilities/zip-slip-vulnerability-java

3. Linux Integrity Verification: SHA256 and GPG Checks Explained \- Linux Security, https://linuxsecurity.com/news/server-security/checksums-in-linux-integrity-guide

4. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc8785/

5. Detect Cycle in a Directed Graph – Kahn's Algorithm (BFS Topological Check) in Python, https://codeanddebug.in/blog/detect-cycle-in-a-directed-graph-kahns-algorithm-bfs/

6. Directed acyclic graphs in perioperative observational research–A systematic review and critique against best practice recommendations | PLOS One, https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0281259

7. How to sign and verify using OpenSSL \- Page Fault Blog, https://pagefault.blog/2019/04/22/how-to-sign-and-verify-using-openssl/

8. How to Verify File Integrity: Checksums and GPG Signatures Explained \- MeshWorld, https://meshworld.in/blog/how-to/verify-file-integrity/

9. Sign and verify using OpenSSL \- Enrico Zimuel, https://www.zimuel.it/blog/sign-and-verify-a-file-using-openssl

10. BagIt \- Wikipedia, https://en.wikipedia.org/wiki/BagIt

11. RFC 8493 \- The BagIt File Packaging Format (V1.0) \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc8493/

12. draft-kunze-bagit-07 \- The BagIt File Packaging Format (V0.97) \- Digital Preservation, https://www.digitalpreservation.gov/documents/bagitspec.pdf

13. JSON Canonicalization Scheme (JCS) Projects \- AI Tinkerers \- Atlanta, https://atlanta.aitinkerers.org/technologies/json-canonicalization-scheme-jcs

14. Associated Signature Containers \- Wikipedia, https://en.wikipedia.org/wiki/Associated\_Signature\_Containers

15. Verify ASiC / .asice Signature Online Free \- Chaindoc, https://chaindoc.io/verify-asic

16. SLSA specification, https://slsa.dev/spec/v1.0/

17. SLSA Provenance \- Tekton, https://tekton.dev/docs/chains/slsa-provenance/

18. attestation/spec/v1/statement.md at main · in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md

19. PDF/A (ISO 19005): The Standard for Long-Term Electronic Document Preservation and Conversion Tools \- DEV Community, https://dev.to/derek-compdf/pdfa-iso-19005-the-standard-for-long-term-electronic-document-preservation-and-conversion-tools-3ml6

20. A Technical Introduction to PDF/A-1/2/3/4 \- PDFlib, https://www.pdflib.com/fileadmin/cookbooks/TET/TET-Cookbook/input/Whitepaper-Technical-Introduction-to-PDFA.pdf

21. Understanding PDF Standards: PDF/A, PDF/X, and Digital Signatures | PDFCheck Blog \- PDF Metadata Viewer, https://pdf.businesspress.io/blog/understanding-pdf-standards

22. Data Integrity EdDSA Cryptosuites v1.1 \- W3C on GitHub, https://w3c.github.io/vc-di-eddsa/

23. RDF Dataset Canonicalization \- W3C, https://www.w3.org/community/reports/credentials/CG-FINAL-rdf-dataset-canonicalization-20221009/

24. RDF Dataset Canonicalization \- W3C, https://www.w3.org/TR/rdf-canon/

25. Data Integrity 1.0 \- W3C, https://www.w3.org/community/reports/credentials/CG-FINAL-data-integrity-20220722/

26. SOURCE\_DATE\_EPOCH — reproducible-builds.org, https://reproducible-builds.org/docs/source-date-epoch/

27. SOURCE\_DATE\_EPOCH specification \- Reproducible Builds, https://reproducible-builds.org/specs/source-date-epoch/

28. Reproducible Builds: Increasing the Integrity of Software Supply Chains \- arXiv, https://arxiv.org/pdf/2104.06020

29. Using NIST SP 800-161 for Cybersecurity Supply Chain Risk Management \- Mitratech, https://mitratech.com/resource-hub/blog/nist-800-161-for-cybersecurity-supply-chain-risk-management/

30. NIST SP 800-161 Rev 1: C-SCRM Controls & Requirements | SCF, https://securecontrolsframework.com/grc-fundamentals/common-cybersecurity-frameworks/nist-sp-800-161-compliance-guidance

31. NIST SP 800-161 Rev 1 Compliance (C-SCRM) \- ComplianceForge, https://complianceforge.com/reasons-to-buy/common-compliance-requirements/nist-sp-800-161-compliance-resource-center

32. SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations \- NIST Computer Security Resource Center, https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final

33. RDF Dataset Canonicalization, https://lists.w3.org/Archives/Public/public-credentials/2021Mar/att-0220/RDFDatasetCanonicalization-2020-10-09.pdf

34. Ask HN: JSON RFC 8785 Serialization \- Hacker News, https://news.ycombinator.com/item?id=36529054

35. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8785

36. RFC 8785: JSON Canonicalization Scheme (JCS), https://www.rfc-editor.org/info/rfc8785/

37. GitHub \- lattice-substrate/json-canon: Deterministic RFC 8785 JSON Canonicalization Scheme (JCS) for Go: strict parser, canonical serializer, and stable CLI ABI., https://github.com/lattice-substrate/json-canon

38. Does JSON syntax allow duplicate keys in an object? \- Stack Overflow, https://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object

39. RFC 8785: JSON Canonicalisation Scheme · nlohmann json · Discussion \#2612 \- GitHub, https://github.com/nlohmann/json/discussions/2612

40. Using the Linux kernel's Case-insensitive feature in Ext4 \- Hacker News, https://news.ycombinator.com/item?id=24315471

41. Skeleton algorithm from Unicode TR39 for testing confusability of strings \- GitHub, https://github.com/mpkorstanje/tr39-confusables

42. Reproducible Builds \- Yocto Project, https://wiki.yoctoproject.org/wiki/Reproducible\_Builds

43. Designing build date epoch in Chainguard Images, https://www.chainguard.dev/unchained/designing-build-date-epoch-in-chainguard-images

44. snyk/zip-slip-vulnerability \- GitHub, https://github.com/snyk/zip-slip-vulnerability

45. Archive Extraction Path Traversal \- HackTricks, https://hacktricks.wiki/en/generic-hacking/archive-extraction-path-traversal.html

46. gramps-webapi: Zip Slip Path Traversal in Media Archive Import · CVE-2026-40258 \- GitHub, https://github.com/advisories/GHSA-m5gr-86j6-99jp

47. mholt/archiver Zip Slip Path Traversal \- JFrog Security Research, https://research.jfrog.com/vulnerabilities/archiver-zip-slip/

48. Verify a BagIt archive, according to RFC 8493 SYNOPSIS verify\_bagit, https://avpres.net/Bash\_AVpres/verify\_bagit\_man.pdf

49. 2.4 Preventing replay attacks \- USENIX, https://www.usenix.org/legacyurl/24-preventing-replay-attacks

50. encoding/json/v2 · golang go · Discussion \#63397 \- GitHub, https://github.com/golang/go/discussions/63397

51. The JSON Canonicalisation Scheme (RFC 8785\) in action and how to secure JSON objects with HMAC \- Connect2id, https://connect2id.com/blog/how-to-secure-json-objects-with-hmac

52. Vector Clocks in Distributed Systems \- GeeksforGeeks, https://www.geeksforgeeks.org/computer-networks/vector-clocks-in-distributed-systems/

53. Spinning Around In Cycles With Directed Acyclic Graphs | by Vaidehi Joshi \- Medium, https://medium.com/basecs/spinning-around-in-cycles-with-directed-acyclic-graphs-a233496d4688

54. what is the best way to implement to check for cycle in DAGs? : r/cpp\_questions \- Reddit, https://www.reddit.com/r/cpp\_questions/comments/s82jle/what\_is\_the\_best\_way\_to\_implement\_to\_check\_for/

55. Without real clocks, how can the order of offline changes be known? \- Yjs Community, https://discuss.yjs.dev/t/without-real-clocks-how-can-the-order-of-offline-changes-be-known/2189

56. What is PDF/A? The complete guide to PDF/A‑1/2/3/4 \- Nutrient, https://www.nutrient.io/blog/what-is-pdf-a/

57. Blinded Commitment: Definition & Cryptographic Use | ChainScore Glossary, https://www.chainscorelabs.com/en/glossary/cryptography-and-zero-knowledge-proofs/commitment-schemes/blinded-commitment

58. Commitment Schemes \- YouTube, https://www.youtube.com/watch?v=4w\_b8Msxy14

59. Using ZK Proofs to Fight Disinformation | by Dan Boneh \- Medium, https://medium.com/@boneh/using-zk-proofs-to-fight-disinformation-17e7d57fe52f

60. Zip Path Traversal | Security \- Android Developers, https://developer.android.com/privacy-and-security/risks/zip-path-traversal

61. EN 319 122-2 \- V1.0.0 \- Electronic Signatures and Infrastructures (ESI) \- ETSI, https://www.etsi.org/deliver/etsi\_en/319100\_319199/31912202/01.00.00\_20/en\_31912202v010000a.pdf

62. How effective are timestamps as a countermeasure for Replay attacks?, https://security.stackexchange.com/questions/172294/how-effective-are-timestamps-as-a-countermeasure-for-replay-attacks

63. Understanding WCAG 2.2 | WAI \- W3C, https://www.w3.org/WAI/WCAG22/Understanding/

64. Whitepaper: A Technical Introduction to PDF/A, https://origin2.componentsource.com/sites/default/files/resources/pdflib/545586/whitepaper-technical-introduction-to-pdfa.pdf