A single qgpl CLI that produces, verifies, and audits Quantum-Safe Distribution Metadata for any artifact released under QGPL v3.0 — plus a portable file format anyone can re-implement.
QGPL v3.0 §5.1 requires Quantum-Safe Distribution Metadata with every release — hash, post-quantum signature, public key, algorithm identifier. Without tooling, that clause is unenforceable in practice and the license's central differentiator goes unused. The toolkit closes the gap: a reference implementation and a portable format anyone can re-implement.
Produce a .qgpl.json manifest with a post-quantum signature in one command. Hybrid PQ and classical optional through the 2026–2030 transition window.
Strict by default — every signature component must pass. --pq-only for archival recovery when the classical half ages out.
Walk an entire release directory and report which artifacts lack compliant Section 5 metadata. Exit codes are CI-friendly.
qgplSix commands cover the full lifecycle — init, key generation, sign, verify, inspect, audit.
| Command | What it does |
|---|---|
qgpl init |
Scaffold QGPL.toml, LICENSE, and NOTICE into a project. |
qgpl keygen |
Generate a PQ keypair (default ML-DSA-65). --root produces an offline SLH-DSA root key with safety guardrails. |
qgpl sign <artifact>… |
Emit <artifact>.qgpl.json and detached .qgpl.sig. Multi-file releases produce a single MANIFEST.qgpl.json. |
qgpl verify <artifact|manifest> |
Verify manifest, artifact, public key. --pq-only ignores the classical half. --strict-issuer requires a pinned root. --offline forbids network fetch. |
qgpl inspect <manifest> |
Human-readable: algorithm, hash, key fingerprint, signed time, issuer. |
qgpl audit <dir> |
Walk a release directory; report which files lack compliant metadata. Exit 1 on any spec violation. |
Exit codes: 0 ok · 1 spec violation · 2 usage error · 3 internal error.
.qgpl.json formatJSON, canonicalized with JCS (RFC 8785) before signing. Carries exactly the four elements QGPL §0 requires.
{
"qgpl_spec": "1.0",
"license": "QGPL-3.0",
"artifact": {
"name": "results-2026-05-24.csv",
"size": 1048576,
"hash": {
"alg": "SHA-256",
"value": "b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9"
},
"license_spdx": "QGPL-3.0"
},
"author": {
"name": "Dr. Šarūnas Grigaliūnas",
"orcid": "0000-0000-0000-0000"
},
"signature": {
"alg": "ML-DSA-65",
"value": "<base64>",
"signed_at": "2026-05-24T12:00:00Z"
},
"public_key": {
"alg": "ML-DSA-65",
"value": "<base64>",
"fingerprint": "sha256:1a2b3c…"
},
"issuer": {
"name": "The Open Reality Initiative — Release CI",
"uri": "https://qgpl.org/.well-known/qgpl/keys.json"
},
"timestamp": {
"rfc3161_token": "<base64>"
}
}Through the 2026–2030 transition window, manifests can carry a structured components array — one PQ, one classical — both signing the same canonical bytes. Strictly additive: every listed component must verify. No M-of-N substitution in v1.
A long-lived offline SLH-DSA root key signs a .well-known/qgpl/keys.json document; rotating online ML-DSA-65 signing keys sign day-to-day releases. Rotation does not invalidate the recipient's pin.
| Class | Identifier | Source |
|---|---|---|
| Hash | SHA-256, SHA-384, SHA-512, SHA3-256, SHAKE-128, SHAKE-256 | FIPS 180-4 / 202 |
| Signature | ML-DSA-44, ML-DSA-65, ML-DSA-87 | FIPS 204 |
| Signature | SLH-DSA-SHA2-{128,192,256}{s,f} | FIPS 205 |
| Signature | XMSS-SHA2_*, LMS-SHA256-* | NIST SP 800-208 |
| KEM (hybrid transport profile only) | ML-KEM-512, ML-KEM-768, ML-KEM-1024 | FIPS 203 |
Default for keygen / sign: ML-DSA-65. Recommended for archival (>50-year integrity horizon): SLH-DSA. Algorithm agility per QGPL §5.3 — when NIST publishes a revision or replacement, the toolkit adds the new identifier in a minor spec release; old identifiers stay readable.
Spec at v0.5.1. Conformance fixtures in docs/conformance/spec-0.4/. Reference implementation tracked separately when the spec freezes.
.well-known/qgpl/keys.json trust modeltimestamp.transparency_log)The toolkit cannot attest that the root key was actually generated on an offline machine. Issuers are expected to publish a written root-key provenance statement (when, on what kind of machine, how stored, who has access). Closing this technically requires hardware attestation and is on the v1.1 roadmap.
liboqs-OpenSSL, rustls-post-quantum, etc.Full draft spec — CLI, manifest, hybrid encoding, trust model, conformance contract.
docs/COMPLIANCE-TOOLKIT-SPEC.md Test vectors · spec 0.4Real artifact bytes with real hashes and placeholder crypto. Includes generate.py, which emits a fully-signed copy. ~12 KB.
The same files, in-repo, for diffing and review. Pinned to spec draft 0.4.
docs/conformance/spec-0.4/ Position paperAcademic write-up of the construction, the threat model, and the relationship between copyleft and post-quantum integrity.
docs/paper/qgpl-quantum-safe-copyleft.md