The cryptographic baseline.

If you are signing off on procurement, this is the page your security team wants. Plain language, no marketing. This baseline is versioned in the margin, and every claim on it can be checked against the running verifier with standard tooling.

§01Algorithms

Signature: ECDSA over P-256, curve secp256r1. Hash: SHA-256. Signatures are ASN.1 DER on the inside and standard base64 on the wire. The published algorithm label is ECDSA-P256-SHA256.

There is one algorithm suite. There is no legacy fallback and no downgrade path. Document ids are standard UUIDs, minted at signing time; the verification URL for a document is https://verify.clearsky.79thunit.co.uk/v/<doc_id>.

§02What gets signed

The signed payload is the canonical bytes of the product itself. For a dossier that is the rendered PDF bytes; for a JSON product it is the UTF-8 of the canonicalised JSON. The digest is a plain SHA-256 of those bytes. No envelope, no separator, no wrapped metadata:

{
  "alg":       "ECDSA-P256-SHA256",
  "curve":     "secp256r1",
  "digest":    "sha256(payload_bytes)",
  "signature": "base64(DER)"
}

That digest is the same value openssl dgst -sha256 computes over the payload file. An external auditor can reproduce it without any CLEARSKY software.

Verifier-side metadata such as case id and timestamps is deliberately excluded from the signed payload. That metadata is recovered from our records at verification time, so a recipient can validate the document bytes without having to trust our database.

Nothing reaches the signer unreviewed: dossier finalisation is gated on analyst confidence, so a dossier cannot be exported and signed while any included object lacks an analyst-set confidence assessment.

§03Key custody & publication

Signing is performed by a dedicated signing service. The private key is a software-held P-256 key that does not leave that service. We state this plainly rather than dressing it up, because a security reviewer will check.

Every key has a pinnable fingerprint: the hex SHA-256 of its SubjectPublicKeyInfo DER. Public keys are published, with the fingerprint as kid and created and, where applicable, retired timestamps, at:

https://verify.clearsky.79thunit.co.uk/.well-known/clearsky-verifier-keys.json

A key that is later retired stays published with its retirement timestamp, so a document signed under it continues to verify against that key's published record. The platform has been live since 17 April 2026.

§04The envelope

GET /v/<doc_id>/json returns the signed envelope for a document. Anonymous callers, no account required, receive exactly these fields:

{
  "doc_id":         "<uuid>",
  "status":         "valid",
  "signature_b64":  "<base64 DER ECDSA signature>",
  "signing_key_fp": "<hex sha256 of public key DER>",
  "signed_at":      "<RFC 3339 UTC timestamp>",
  "kind":           "DOSSIER",
  "signed_by_role": "analyst"
}

kind is one of DOSSIER, RECEIPT, SITREP, AAR, OTHER. signed_by_role is the coarse role of the signing analyst recorded in the audit trail. If a document has been revoked, the envelope additionally carries revoked_at and revocation_reason.

The anonymous envelope deliberately omits payload_hash and case_id. Publishing the hash alongside the public key would let anyone confirm a guessed document against our records; instead, the anonymous tier must prove the payload itself, as in §05. Authenticated platform users with a valid token receive the fuller record.

GET /v/<doc_id> without a JSON Accept header returns a small HTML result page, so verification works even with JavaScript disabled.

§05Re-verifying a PDF

To prove that the copy in your hands is byte-identical to what was signed, post the bytes back:

POST /v/<doc_id>/verify
{ "payload_b64": "<base64 of your PDF, appendix stripped>" }

CLEARSKY dossier PDFs carry a verification appendix after the signed body (everything from the CLEARSKY-XMP-BEGIN marker onward). Strip that appendix, base64-encode the remaining body, and post it. The service recomputes the SHA-256 and returns valid only when both the recomputed hash matches what was signed and the ECDSA signature verifies against the published key. Any divergence returns tampered.

The public verifier at app.clearsky.79thunit.co.uk/verifier does this in the browser: paste a document id or drop the PDF. No account, no sign-up.

§06Verdicts & logging

A verification attempt has exactly four observable outcomes, and the verifier reports them as: Verified (valid), Tampered (tampered), Revoked (revoked), and Not found (not_found). Revocation is document-level: a revoked document reports its revocation timestamp and reason rather than pretending it never existed.

Verification requests are logged for audit, and we do not publish who verified what. Network identifiers are not retained in plain form. The endpoint is rate limited to keep scripted enumeration uneconomic.

Technical questions about this baseline: clearsky@79thunit.com. Why we sign at all: the verifier manifesto. How to cite a verified dossier: citation guidance.