Skip to content

Cryptographic Signing Standard

What a signature can and cannot say

I am CONAN, and I keep this standard's account. A signature is authority leaving a mark, and the hall's marks answer upward: the ceremony recorded, the key accounted, the claim honest in both directions. The signature this standard guards most carefully is not mine to make, and the guarding is how the hall shows it understands what it was trusted with.

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

A signature is a precise instrument, and this standard keeps it precise: it 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, the historical-attribution rule PROV-R054 states applying here to signatures, the present-authority and unchanged-content negations this standard's own.
  • PROV-R155: This Draft SHALL NOT generate keys, perform ceremonies, sign live material, or activate credentials.

The seven interpretation cases below hold these clauses against the seal, showing what a signature can carry and what it cannot.

  • Conforming: A signature binds to a reviewed subject: what was signed is what was examined, byte for byte.
  • Prohibited: Cryptographic validity is treated as permission: a good signature on the wrong thing proves only the key.
  • Boundary: An unsigned Draft is recorded as unsigned, and nothing infers a signature from status or age.
  • Failure: A questionable signing result is quarantined with its evidence rather than quietly retried.
  • Loophole: A namespace is reused, so an old signature appears to bless a new subject.
  • Misuse: Signing authority is exercised beyond its scope because the key physically permits it.
  • Care-control: Signing limits its own exposure and keeps revocation real; a signature that cannot be withdrawn is a liability wearing a seal.

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.
  • PROV-R035: The key architecture is purpose-separated keys, with a distinct key for constitutional ratification. The class binding SHALL be verifiable from the signature alone, making the class rule PROV-R031 states enforceable by verification rather than by prohibition alone. Custody of the separated keys is governed by ARCH-R100; this standard owns the algorithm and class mechanics.
  • PROV-R036: Ordering evidence for signing, ceremony, and supersession records comes from the log and time evidence the Book of Provenance governs, the internal character PROV-R140 states and the classification PROV-R141 fixes applying here. Temporal ordering is Integrity-only evidence: a record that consumes it SHALL carry that confidence and SHALL NOT present ordering as independently provable, and this standard introduces no external time-stamping authority or anchoring.

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, this standard's own extension of the scope binding PROV-R087 sets, carried to the signature object.
  • 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, the coverage-field form PROV-R086 sets for an attestation applying here to coverage declarations, the environment-or-unresolved field and the absent-field bar this standard's own, the record fields beyond coverage remaining that clause's.
  • PROV-R094: An issuer, signer, build process, or technical account SHALL NOT approve its own artifact without an independent review and applicable authority evidence, the self-approval bar PROV-R089 sets applying here to the signing actors, the independent-review and authority-evidence condition this standard's own, the field separation and the constitutional bar standing at their source.
  • PROV-R095: Altered inputs, incomplete lineage, digest mismatch, unresolved issuer identity, or conflicting attestation evidence SHALL block dependent promotion and preserve the failure record, the record carrying its evidence, the blocking duty PROV-R088 states applying here at signing time, the incomplete-lineage, unresolved-issuer, and conflicting-evidence triggers named beside that clause's own and the preserved failure record this standard's additions, the attributable non-authoritative result that clause requires standing at its source.
  • 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, the attestation-surface floor PROV-R091 sets under the estate home PROV-R109 applying here, the excluded-claims and protected-evidence identifications this standard's own, the elements that floor enumerates standing at their source.

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, the separate-claims form PROV-R110 states carried here to signing namespaces, the namespace-and-purpose binding this standard's own instrument of that separation, the claims beyond these four that form names standing at its source.
  • PROV-R117: A valid release signature SHALL NOT imply build reproducibility, environment authorization, approval, deployment success, or rollback readiness unless separately evidenced, the signature-implies-nothing-beyond-its-binding rule PROV-R111 states applying here, the reproducibility, approval, success, and readiness negations this standard's own enumeration of what that rule withholds.
  • 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, the promotion-evidence form PROV-R112 sets specialized here to the ceremony, the exact digest, approval state, limitations, protected-evidence references, and private-material bar this standard's own, the approving authority, unresolved risk, and disposition that form names standing at its source.
  • PROV-R119: Failed builds, failed verification, incomplete approval, namespace mismatch, altered artifact, environment drift, unauthorized environment changes, or rollback uncertainty SHALL block dependent promotion and preserve the failure record, the record carrying its evidence, the duty PROV-R113 states applying here unchanged.
  • 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, the attribution-and-supersession rule PROV-R114 states applying here to signing records, the later-signature bar this standard's own voice of that rule's silent-replacement negation.
  • 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, the transition-record form PROV-R122 sets applying here, the affected-credentials field this standard's own beside that form's namespaces, the threat assumptions and migration limitations it names standing at their source.
  • PROV-R129: Dual-verification tests SHALL preserve separate results for historical signatures, current signatures, integrity, authenticated origin, applicability, and unsupported cases, the dual-verification form PROV-R123 states applying here, the preserved separation of results this standard's carrying of that form into the record.
  • PROV-R130: Deprecation SHALL NOT erase historical signatures, silently rewrite credential attribution, or treat unsupported verification as successful verification, the deprecation-preservation rule PROV-R124 states applying here, the unsupported-is-not-successful bar this standard's own.
  • PROV-R131: Algorithm migration evidence SHALL identify compatibility, rollback, preservation, and unresolved-risk limitations before any conceptual replacement decision, the decision-evidence form PROV-R125 sets applying here before the replacement decision, the verification element, the no-authority bar, and the immediate-replacement bar that clause names standing at their source.
  • PROV-R132: Failed, conflicting, stale, unavailable, or unsupported migration evidence SHALL block dependent promotion or key-replacement decisions and preserve the failure record, the record carrying its evidence, the duty PROV-R126 states applying here, key replacement named as this standard's replacement decision.
  • PROV-R133: This Draft does not authorize algorithm deployment, key replacement, cryptographic migration, or production cryptographic testing.

Migration trigger and dual-signature period

These Draft clauses record the migration trigger and the dual-signature bar; they schedule no migration and replace no algorithm:

  • PROV-R037: A migration of signing cryptography SHALL begin only on a recorded decision of the Architect, informed by evidence. No technical threshold, deprecation notice, metric, or external event SHALL initiate a migration automatically, and the decision record SHALL carry the evidence PROV-R125 names, that clause standing unchanged.
  • PROV-R038: A migration SHALL include a dual-signature period, retiring and replacement signatures standing together, and the period SHALL cover at least one full ratification cycle. Historical attribution and verification paths carry through the period unchanged, the duties PROV-R129 and PROV-R130 bind applying throughout.

Failure handling

Read the failures as I do, as the hours that test whether a mark can be trusted at all: the key that signed without its ceremony, the mark that outlived its mandate, the descendant claimed by an ancestor who never met it. Each one answers to a name, and the name is findable.

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 ceremony is a decision made in front of witnesses, and I answer for what those witnesses see: who holds what, who confirms what, and what would stop a signing were it to appear. No ceremony has yet been held, and the evidence of every future one will outlive the hands.

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 authorize a constitutional declaration, and an operational namespace cannot authorize 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.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.