How we sign our own attestations

The keypair

One ed25519 keypair, used to sign every machine-readable document at kineticgain.com/.well-known/ plus AI Procurement Pulse receipts. The public key is published at a stable URL so anyone can fetch + verify without out-of-band coordination.

Algorithm

ed25519 (RFC 8032)

Public key URL

https://kineticgain.com/.well-known/pulse-signing.json

Public key (base64 SPKI-DER)

MCowBQYDK2VwAyEARxsDtZsl4R481NdBerN2RlCF74VZdQhqRHpgvAIJoTo=

Published

2026-05-28

Private key

Held offline by Miz Causevic (PKCS#8 PEM, mode 0600). Never committed, never transmitted, never copied to any cloud key store. Signing happens manually on a trusted local machine via scripts/sign-suite-docs.mjs in the procurement-pulse-engine repo.

Rotation policy

Annual or on compromise. New keypair published at the same URL with a signing_key_version bump; old verifiable signatures remain valid against the old key (kept in archive). Compromise → revocation note at the same URL within 24 hours.

What we sign

All 11 KG Suite specification documents at /.well-known/<spec>.json. Each carries an embedded signature block (top-level key) that verifies against the public key above.

Path	What it declares
/.well-known/aeo.json	AEO entity card — Kinetic Gain's answer-engine identity
/.well-known/agents/index.json	Agent cards we publish
/.well-known/prompts/index.json	Prompt provenance index
/.well-known/evidence/index.json	AI evidence bundles index
/.well-known/tool-cards/index.json	MCP tool cards
/.well-known/tutor-cards/index.json	AI tutor cards
/.well-known/student-ai/index.json	Student AI disclosure
/.well-known/aup.json	Classroom AI acceptable-use policy
/.well-known/clinical-ai/index.json	Clinical AI disclosure
/.well-known/incidents/index.json	AI incident cards
/.well-known/decisions/index.json	AI procurement decision cards

The same key signs the /.well-known/pulse-receipt.json attestation that publishes the locked AI Procurement Pulse baseline.

Verification procedure

To verify any signed document, fetch it, separate the signature block, canonicalize the rest, and ed25519-verify with the published public key. Three implementations agree byte-for-byte:

1. Node.js (built-in, zero deps)

// signature.mjs lives in procurement-pulse-engine; vendor-able into your project.
import { verifyDocument } from "./signature.mjs";

const doc = await (await fetch("https://kineticgain.com/.well-known/aeo.json")).json();
const result = await verifyDocument(doc);
console.log(result);  // { status: "verified", keySource: "embedded" }

2. Python (cryptography lib)

import json, requests
from base64 import b64decode
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
from cryptography.hazmat.primitives.serialization import load_der_public_key

def canonical(v):
    if isinstance(v, list): return "[" + ",".join(canonical(x) for x in v) + "]"
    if isinstance(v, dict):
        return "{" + ",".join(json.dumps(k, ensure_ascii=False) + ":" + canonical(v[k])
                              for k in sorted(v.keys())) + "}"
    return json.dumps(v, ensure_ascii=False)

doc = requests.get("https://kineticgain.com/.well-known/aeo.json").json()
sig = doc.pop("signature")
pk = load_der_public_key(b64decode(sig["public_key"]))
pk.verify(b64decode(sig["value"]), canonical(doc).encode())   # raises on failure
print("verified")

3. Shell (openssl)

curl -s https://kineticgain.com/.well-known/aeo.json > doc.json
# (separate body + signature with jq, base64-decode pubkey + value, openssl pkeyutl -verify)
# Full one-liner in the GitHub Action below; recommended for CI rather than ad-hoc.

The canonicalization is JCS-style with one important detail: do not escape non-ASCII. Python's json.dumps defaults to ensure_ascii=True and would produce different bytes than Node's JSON.stringify. We caught this bug ourselves on 2026-06-01 — see the incident below.

Deploy-time defense

Every apex deploy now runs a Python step that verifies all 11 Suite documents pass ed25519 verification before the FTP step ships them. If any document is unsigned, has an invalid signature, or fails canonical-form verification, the deploy fails loudly with the exact command to re-sign:

node scripts/sign-suite-docs.mjs --apex . --key /path/to/kg-pulse-signing-key.pem

This means a developer who edits a Suite document without re-signing cannot accidentally ship the unsigned version. The error message links back to this page.

The check itself is in .github/workflows/deploy.yml in the apex repo. It uses the same canonical-JSON algorithm the production Node signer uses, so a passing check in CI means the doc would also verify against any external Node, Python, or Go consumer.

The 2026-06-01 incident — why this page exists

Discipline going forward

The workflow we ourselves follow, in order:

1. Edit a Suite document in kineticgain-com-apex/.well-known/.
2. Re-run node scripts/sign-suite-docs.mjs --apex /path/to/apex --key /path/to/private-key.pem in the procurement-pulse-engine repo.
3. Commit the re-signed document to apex.
4. Push. The CI verify-step will fail the deploy if step 2 was skipped.
5. The quarterly AI Procurement Pulse cron will independently catch any drift the deploy-time check missed.

Three independent safety nets: the human discipline, the deploy-time check, and the quarterly drift report. No single human, machine, or schedule is the sole gate.

Coordinated disclosure

If you find a way to forge a signature, demonstrate two distinct documents that hash to the same canonical form, or otherwise break the verification chain, report it to miz@kineticgain.com. We follow standard coordinated disclosure (acknowledge within 72 hours, fix-and-publish within 90 days, credit the reporter in the fix release).

The full scope is at /.well-known/security.txt (RFC 9116).

Reference scaffolding for cryptographic methodology disclosure — not a SOC 2 / ISO 27001 / NIST AI RMF / EU AI Act certified or compliant attestation. Compliance posture depends on your organization's full control environment and external attestation specific to each regulatory regime.