Skip to content

Cryptographic Signing Standard

What a signature can and cannot say

A signature can bind an assertion to a key and a moment. It cannot make a false statement true, create the Architect, or replace the surrounding authority and provenance record. This standard gives both human and AI readers a precise way to use cryptography without venerating the mechanism itself.

Continue to the Verification Standard, where a signature becomes one input in a larger judgement.

Purpose

Defines signing classes, namespaces, record evidence, ceremony boundaries, and historical attribution without treating cryptography as constitutional authority.

Architect-review operating model

  • PROV-R152: A signing request SHALL identify signer authority, subject, digest, purpose, scope, expiry, ceremony evidence, and verification route.
  • PROV-R153: Key compromise, ambiguity, duplicate namespace, or disputed authority SHALL invalidate or quarantine the affected signing result pending review.
  • PROV-R154: Historical signatures SHALL remain attributable without implying present authority or unchanged content.
  • PROV-R155: This Draft SHALL NOT generate keys, perform ceremonies, sign live material, or activate credentials.

Interpretation cases: Conforming binds signature to reviewed subject; Prohibited treats cryptographic validity as permission; Boundary records an unsigned Draft; Failure quarantines a result; Loophole reuses a namespace; Misuse signs beyond scope; Care-control limits exposure and supports revocation.

Normative clauses

  • PROV-R030: Every signature shall declare its principal, credential, class, namespace, purpose, scope, validity interval, digest, and verification state.
  • PROV-R031: A signature valid in one class or namespace shall not imply validity in another.
  • PROV-R032: Signing evidence shall bind the exact content digest and preserve creation, effective, supersession, and revocation relationships.
  • PROV-R033: Ceremony evidence shall record independent review, limitations, applicability, and custody without disclosing private signing material.
  • PROV-R034: A signature authenticates only the covered content and declared purpose; it cannot create identity, authority, consent, or ratification.

Artifact attestation boundaries

  • PROV-R092: An artifact attestation signature shall bind the exact artifact digest, attestation class, namespace, purpose, and covered claims. It shall not expand the underlying attestation scope.
  • PROV-R093: Attestation coverage shall identify source inputs, transformations, producer, environment or unresolved status, and limitations. An absent field shall not be represented as complete coverage.
  • PROV-R094: An issuer, signer, build process, or technical account shall not approve its own artifact without an independent review and applicable authority evidence.
  • PROV-R095: Altered inputs, incomplete lineage, digest mismatch, unresolved issuer identity, or conflicting attestation evidence shall block dependent promotion and preserve the failure record.
  • PROV-R096: Attestation signing evidence shall remain separate from credential lifecycle, constitutional applicability, and deployment approval. No signature creates authority or authorizes production use.
  • PROV-R097: Public attestation material shall minimize disclosure and identify protected evidence, excluded claims, and verification limitations.

Build and deployment signing boundaries

  • PROV-R116: Release and deployment signatures shall use distinct declared namespaces and purposes for artifact, environment, approval, and rollback claims.
  • PROV-R117: A valid release signature shall not imply build reproducibility, environment authorization, approval, deployment success, or rollback readiness unless separately evidenced.
  • PROV-R118: Signing ceremony evidence shall identify independent review, exact digest, target environment, approval state, limitations, and protected evidence references without disclosing private signing material.
  • PROV-R119: Failed verification, incomplete approval, namespace mismatch, altered artifact, environment drift, or rollback uncertainty shall block dependent promotion and preserve the failure evidence.
  • PROV-R120: Build, deployment, and rollback signing records shall remain attributable and supersedable. A later signature shall not erase or silently rewrite earlier release history.
  • PROV-R121: This Draft does not authorize signing-key generation, deployment, environment mutation, production promotion, or a live signing endpoint.

Post-quantum migration boundaries

  • PROV-R128: Algorithm-agility records shall declare the signature namespace, retiring and proposed algorithms, affected credentials, validity intervals, and supported verification paths.
  • PROV-R129: Dual-verification tests shall preserve separate results for historical signatures, current signatures, integrity, authenticated origin, applicability, and unsupported cases.
  • PROV-R130: Deprecation shall not erase historical signatures, silently rewrite credential attribution, or treat unsupported verification as successful verification.
  • PROV-R131: Algorithm migration evidence shall identify compatibility, rollback, preservation, and unresolved-risk limitations before any conceptual replacement decision.
  • PROV-R132: Failed, conflicting, stale, unavailable, or unsupported migration evidence shall block dependent promotion or key-replacement decisions and preserve the failure record.
  • PROV-R133: This Draft does not authorize algorithm deployment, key replacement, cryptographic migration, or production cryptographic testing.

Failure handling

Malformed, unsupported, replayed, revoked, stale, conflicting, or namespace-mismatched signatures are non-authoritative and block dependent promotion. Historical signatures remain attributable even after revocation.

Exclusions

This Draft defines no key, agent, endpoint, signing service, or live ceremony.

Ceremony evidence model

A future ceremony record shall identify the content digest, signer and credential, class, namespace, purpose, approval, independent witness or review, time evidence, custody, result, limitations, and supersession relationship. Preparation, signing, verification, publication, and revocation are distinct events. A failed or interrupted ceremony remains evidence and cannot be silently retried as though no event occurred.

Namespace controls

Namespaces are purpose-specific and non-transitive. A release namespace cannot authorise a constitutional declaration, and an operational namespace cannot authorise Architect identity. Namespace changes require explicit migration evidence and historical linkage.

Ceremony threat model

Ceremony design shall account for coercion, substitution, replay, split knowledge, unavailable witnesses, clock disagreement, compromised workstations, namespace confusion, and incomplete rollback. Each threat shall have a detection signal, containment path, evidence requirement, and accountable disposition.