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.
The tellings of the clauses¶
This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.
PROV-R152: A signing request SHALL identify signer authority, subject, digest, purpose, scope, expiry, ceremony evidence, and verification route.
The clause requires a signing request to identify signer authority, subject, digest, purpose, scope, expiry, ceremony evidence, and verification route. A request missing any of these eight identifications is checkably nonconforming. The host's prohibited case warns against treating cryptographic validity as permission; the request's required identifications make its stated basis available for review.
PROV-R153: Key compromise, ambiguity, duplicate namespace, or disputed authority SHALL invalidate or quarantine the affected signing result pending review.
Key compromise, ambiguity, duplicate namespace, or disputed authority requires the affected signing result to be invalidated or quarantined pending review. The host's failure case describes a questionable result quarantined with its evidence rather than quietly retried. A reader can check whether a listed condition received one of the two required dispositions 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.
Old marks keep their history and gain nothing from it. The clause requires historical signatures to remain attributable, resolution running against the key, namespace, purpose, and validity state applicable at the event time, with later rotation, retirement, or revocation barred from rewriting that attribution; the historical-attribution rule PROV-R054 states those duties at its source in the Book of Provenance, applied here to signatures. What the clause adds as this standard's own are the two negations: attribution implies neither present authority nor unchanged content. Historical attribution alone implies neither present authority nor unchanged content, so either implication can be challenged without discarding the signature's historical attribution.
PROV-R155: This Draft SHALL NOT generate keys, perform ceremonies, sign live material, or activate credentials.
Nothing operational hides in this document. The clause bars the Draft itself from four acts: generating keys, performing ceremonies, signing live material, and activating credentials. The reason sits in the standard's own exclusions, which define no key, agent, endpoint, signing service, or live ceremony, and in the ceremony evidence model's plain statement that no ceremony has yet been held. The clause makes any of the four acts performed under this Draft a violation; establishing whether an act occurred requires evidence beyond the prohibition.
PROV-R030: Every signature SHALL declare its principal, credential, class, namespace, purpose, scope, validity interval, digest, and verification state.
Nine declarations travel with every signature: its principal, its credential, its class, its namespace, its purpose, its scope, its validity interval, its digest, and its verification state. The clause makes each one a required part of the signature's own account, because a bare cryptographic mark answers none of the questions a relying reader has to ask: who signed, with what credential, in which class and namespace, for what purpose and scope, over which content, valid when, and verified to what state. Silence on any of these is what lets a signature be stretched beyond what it was made for. Declared, each field becomes checkable, and a signature that omits one fails the standard rather than misleading the reader.
PROV-R031: A signature valid in one class or namespace SHALL NOT imply validity in another.
A namespace is a fence, and the clause keeps every signature inside its own. Validity in one class or namespace carries no implication of validity in any other; the host's namespace controls put the same rule concretely, since a release namespace cannot authorize a constitutional declaration, and an operational namespace cannot authorize Architect identity. The failure this forecloses is the Loophole case's reuse, where an old signature appears to bless a new subject because the boundary between purposes went soft. Since the bar binds the implication, a verifier can refuse any claim resting solely on validity established in another class or namespace, and the distinct classes the standard defines stay meaningful rather than interchangeable.
PROV-R032: Signing evidence SHALL bind the exact content digest and preserve creation, effective, supersession, and revocation relationships.
Substitution is among the threats the host's own ceremony model names, and this clause answers it twice. It requires signing evidence to bind the exact content digest and preserve creation, effective, supersession, and revocation relationships. The first duty makes the exact content digest bound by the signing evidence available for comparison. Preserving those relationships supports later review of the signature's lifecycle. A reader can inspect the recorded relationships without assuming that every time or revocation question has been resolved.
PROV-R033: Ceremony evidence SHALL record independent review, limitations, applicability, and custody without disclosing private signing material.
Ceremony evidence records independent review, limitations, applicability, and custody without disclosing private signing material. This keeps the ceremony's review and limits on record while protecting private signing material from disclosure. The clause makes both the four recording requirements and the disclosure boundary checkable. A ceremony record missing independent review, or exposing private signing material, fails the clause.
PROV-R034: A signature authenticates only the covered content and declared purpose; it cannot create identity, authority, consent, or ratification.
The temptation the host names first is a valid mark meaning more than it says; this clause holds that line: a signature authenticates only the covered content and the declared purpose, and it cannot create identity, authority, consent, or ratification. The host opens with the same warning, that a signature cannot make a false statement true, create the Architect, or replace the surrounding authority and provenance record, and its Prohibited case names the failure: cryptographic validity treated as permission proves only the key. Because the four negations stand in the law itself, a signature cannot constitute identity, authority, consent, or ratification, and it authenticates nothing beyond its covered content and declared purpose; what it may evidence within that purpose is untouched.
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.
Purpose-separated keys turn a prohibition into a property a verifier can test. The clause fixes the key architecture as purpose-separated keys, with a distinct key for constitutional ratification, and requires the class binding to be verifiable from the signature alone; that verifiability is what makes the class rule PROV-R031 states enforceable by verification rather than by prohibition alone. Custody of the separated keys stands at its source, governed by ARCH-R100 in the credential lifecycle, while this standard owns the algorithm and class mechanics. A verifier can check the class binding from the signature alone, as the clause requires; this makes the stated class separation testable.
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.
Ordering is the quietest place a record can overclaim, and this clause bounds it. 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 both stand at their source and apply here. Temporal ordering is therefore Integrity-only evidence: a record that consumes it is required to carry that confidence, is barred from presenting ordering as independently provable, and this standard introduces no external time-stamping authority or anchoring. What becomes checkable is the label itself: a signing record that presents ordering as independently provable violates the clause, and a reviewer can refuse that claim without disputing the underlying log.
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.
Signing an attestation could quietly enlarge it, and this clause forecloses exactly that. It requires an artifact attestation signature to bind five things, the exact artifact digest, the attestation class, the namespace, the purpose, and the covered claims, and it bars the signature from expanding the underlying attestation scope. The scope binding itself is PROV-R087's, standing at its source in the Book; what this standard adds as its own is the extension of that binding, carried to the signature object. The deception prevented is scope laundering: an attestation covering little, wrapped in a valid signature, presented as covering much. Because the signature declares exactly what it binds, a reader can compare it against the attestation beneath and refuse any claim the evidence never tested.
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.
The clause makes attestation coverage checkable through its named fields. The clause requires attestation coverage to identify source inputs, transformations, the producer, the environment or its unresolved status, and limitations, and it bars an absent field from being represented as complete coverage. The coverage-field form is PROV-R086's, standing at its source in the Book and applying here to coverage declarations; the environment-or-unresolved field and the absent-field bar are this standard's own, and the record fields beyond coverage remain that clause's. What this protects is the reader who counts: the environment is either declared or its status shown unresolved, and no absent field is passed off as complete coverage, so a gap reads as a gap, never as silence dressed up as completeness.
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.
An issuer, signer, build process, or technical account does not approve its own artifact without independent review and authority evidence, and PROV-R089's narrower self-approval bar stands at its source. The clause bars an issuer, a signer, a build process, or a technical account from approving its own artifact without an independent review and applicable authority evidence. The self-approval bar is PROV-R089's, standing at its source and applying here to the signing actors; the independent-review and authority-evidence condition is this standard's own, while the field separation and the constitutional bar likewise stand at their source. The failure prevented is the Misuse case in miniature: a key that physically permits signing being read as authority to approve. Self-approval by an issuer, signer, build process, or technical account without independent review or applicable authority evidence is refusable under this clause.
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.
Five defects stop the line at signing time: altered inputs, incomplete lineage, digest mismatch, unresolved issuer identity, and conflicting attestation evidence. Any of them blocks dependent promotion and preserves the failure record, the record carrying its evidence. The blocking duty is PROV-R088's, applying here at signing time; the incomplete-lineage, unresolved-issuer, and conflicting-evidence triggers stand beside that clause's own, and they and the preserved failure record are alike this standard's additions, and the attributable non-authoritative result that clause requires stands at its source. The discipline is the Failure case's: a questionable result is held with its evidence, never quietly retried, so promotion cannot roll past a defect, and the reviewer can check the preserved failure record and its evidence.
PROV-R096: Attestation signing evidence SHALL remain separate from credential lifecycle, constitutional applicability, and deployment approval. No signature creates authority or authorizes production use.
Separation is this clause's whole work. Attestation signing evidence remains separate from three neighbouring domains, credential lifecycle, constitutional applicability, and deployment approval, and the second sentence closes the door the separation guards: no signature creates authority or authorizes production use. Were the domains allowed to blur, an attestation signature could be offered where a credential decision, a constitutional judgement, or a deployment approval was owed, and cryptographic validity would again be mistaken for permission. Held apart, the domains keep their own decisions: attestation signing evidence substitutes for no lifecycle, applicability, or deployment decision, and a signature alone creates no authority and no production authorization, whatever its mathematics prove.
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.
When attestation material reaches a public surface, this clause requires it to minimize what it discloses and to identify three things: the evidence held back as protected, the claims excluded from coverage, and the limitations of the verification behind it. The disclosure floor itself is the Book's attestation-surface rule, PROV-R091, standing under the estate home PROV-R109 and applying here; the elements that floor enumerates remain defined at their source, while the excluded-claims and protected-evidence identifications are this standard's own additions. The clause supports independent review while limiting disclosure and making the stated exclusions and verification limitations inspectable. The boundary becomes checkable: a reader can inspect whether public attestation material minimizes disclosure and identifies protected evidence, excluded claims, and verification limitations.
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.
The four claim categories named here are artifact, environment, approval, and rollback. The clause requires release and deployment signatures to use distinct declared namespaces and purposes for each of those four claims, so a signature made for one cannot be read as covering another. The separation itself is the Book's separate-claims form, PROV-R110, carried here into signing namespaces; the namespace-and-purpose binding is this standard's own instrument of that separation, and the claims beyond these four that the form names remain governed at their source. Without this rule, one valid mark could be replayed across roles it never earned. With it, a verifier can refuse a signature as evidence for any claim outside its declared namespace and purpose.
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.
The failure here is inference: a release signature verifies, and a reader concludes the build is reproducible, the environment authorized, the release approved, the deployment successful, and the rollback ready. This clause bars every one of those conclusions unless each is separately evidenced. It is the local application of the Book's rule, PROV-R111, that a signature implies nothing beyond its binding, that rule applying here from its source; the reproducibility, approval, success, and readiness negations are this standard's own enumeration of what that rule withholds, the environment-authorization negation, on the reading PROV-R111 itself supplies, standing with the rule at its source. The check is whether build reproducibility, environment authorization, approval, deployment success, or rollback readiness is being inferred from a valid release signature without separate evidence.
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.
Ceremony evidence is what outlives the signing, and the clause fixes what it carries: the independent review, the exact digest, the target environment, the approval state, the limitations, and references to protected evidence, all recorded without disclosing private signing material. The frame is the Book's promotion-evidence form, PROV-R112, specialized here to the ceremony itself; the exact digest, approval state, limitations, protected-evidence references, and the bar on private material are this standard's own, while the approving authority, unresolved risk, and disposition that form names stand at their source. The clause protects reviewability without disclosure of private signing material: a reader can check the six required identifications and the disclosure boundary.
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.
Eight conditions stop a promotion under this clause: a failed build, failed verification, incomplete approval, a namespace mismatch, an altered artifact, environment drift, unauthorized environment changes, and rollback uncertainty. When any of them appears, dependent promotion is blocked and the failure record is preserved, the record carrying its evidence rather than a bare verdict. The duty is the Book's blocking rule, PROV-R113, applying here unchanged; the clause adds no new trigger and removes none. The rule guards against a questionable release being pushed through and against later review losing the evidence of its failure. Conforming handling of any named condition blocks the dependent promotion and preserves that condition's failure record, a trail an auditor can read.
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.
Release history stays attributable and supersedable under this clause, never silently rewritten by a later signature. Build, deployment, and rollback signing records are required to remain attributable and supersedable, capable of being superseded on the record; a later signature is barred from erasing or silently rewriting earlier release history. The governing rule is the Book's attribution-and-supersession clause, PROV-R114, applying here to signing records, and the later-signature bar is this standard's own voice of that rule's negation of silent replacement. Without it, a new mark could launder an old mistake out of the ledger. With it, no later signature can quietly displace earlier release history, and what stood remains attributable.
PROV-R121: This Draft does not authorize signing-key generation, deployment, environment mutation, production promotion, or a live signing endpoint.
Nothing operational flows from this Draft, and the clause says so in terms: the Draft does not authorize signing-key generation, deployment, environment mutation, production promotion, or a live signing endpoint. It exists because a standard that describes signing machinery in detail could be mistaken for permission to build or run it, and because a Draft's status must not be inflated by the confidence of its prose. The clause makes the boundary checkable: anyone who finds a key generated, a deployment run, an environment mutated, a promotion executed, or an endpoint serving under this document's name can point to this line and know the act had no authority here. Readers and reviewers can rely on none of the five deriving authority from this document, whatever authority may separately be established elsewhere.
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.
An algorithm-agility record declares its content under this clause: the signature namespace, the retiring and proposed algorithms, the credentials affected, the validity intervals, and the verification paths that remain supported. The shape is the Book's transition-record form, PROV-R122, applying here; the affected-credentials field is this standard's own addition beside that form's namespaces, and the threat assumptions and migration limitations the form names stand at their source. The record guards against leaving the transition's named particulars implicit. Its five declared elements become the map a reviewer checks the migration against, the movement's own timing governed by PROV-R037 and PROV-R131 at their sources.
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.
Dual-verification tests preserve separate results for historical signatures, current signatures, integrity, authenticated origin, applicability, and unsupported cases. The clause requires those results to be preserved separately rather than merged into a single verdict. Its frame is the Book's dual-verification form, PROV-R123, applying here; the preserved separation of results is this standard's carrying of that form into the record itself. The rule exists because a blended result hides exactly the failures a migration must see: an old signature that proved only integrity could otherwise pass as fully verified. Kept apart, the results preserve the distinctions the clause names, including unsupported cases.
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.
Retiring an algorithm cannot be allowed to retire the past. This clause bars deprecation from three specific acts: erasing historical signatures, silently rewriting credential attribution, and treating unsupported verification as successful verification. The preservation duty is the Book's deprecation-preservation rule, PROV-R124, applying here; the bar that unsupported is not successful is this standard's own. The clause exists because deprecation is the moment history is most easily lost: once a verifier no longer speaks an algorithm, the temptation is either to discard what it signed or to wave it through unexamined, and both moves falsify the record. An old signature therefore stays attributable to its key and moment, and a verification the tooling could not perform can never be counted a success, the recording of such results standing with PROV-R129 at its source.
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.
Before a replacement decision is taken even in concept, this clause requires the migration evidence to identify its limitations in four dimensions: compatibility, rollback, preservation, and unresolved risk. The evidence frame is the Book's decision-evidence form, PROV-R125, applying here ahead of the replacement decision; the verification element, the bar that a cryptographic preference creates no authority, and the bar against a cryptographic preference requiring immediate replacement all stand at that source. The clause exists to keep the decision honest about what it does not know: a migration weighed only on its benefits, with its rollback and preservation gaps unstated, is a decision made on a partial file. The eventual choice then rests on evidence naming its own weaknesses, and evidence missing those limitations is refusable.
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.
Migration evidence that is failed, conflicting, stale, unavailable, or unsupported stops the work it would have justified: the clause blocks dependent promotion and key-replacement decisions alike, and requires the failure record to be preserved, the record carrying its evidence. The duty is the Book's blocking rule, PROV-R126, applying here; naming key replacement as this standard's replacement decision is the clause's own localization. It exists because a replacement decision is only as sound as its evidence, and evidence that is failed, conflicting, stale, unavailable, or unsupported can carry neither of the two decisions it feeds, dependent promotion and key replacement. Both movements fail closed: dependent promotion and key-replacement decisions stop on defective evidence, and the defect itself remains examinable rather than discarded.
PROV-R133: This Draft does not authorize algorithm deployment, key replacement, cryptographic migration, or production cryptographic testing.
A reader could mistake this section's careful migration vocabulary for authorization of a migration, and this clause forecloses that mistake: the Draft does not authorize algorithm deployment, key replacement, cryptographic migration, or production cryptographic testing. All four withheld powers are named, so the boundary needs no inference. The clause exists because describing a transition in detail creates the appearance of momentum, and appearance is exactly what this corpus refuses to let substitute for a recorded decision. What it assures is a clean test for overreach: any deployed algorithm, replaced key, executed migration, or production cryptographic test claiming this document as its warrant is unauthorized on the document's own face, and whoever audits the estate can refuse it without weighing intent.
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.
Only one hand starts a cryptographic migration. The clause makes a recorded, evidence-informed decision of the Architect the necessary condition for a migration of signing cryptography to begin, authority this Draft itself supplies to no one, and bars every automatic trigger by name: a technical threshold, a deprecation notice, a metric, or an external event cannot initiate one on its own. The decision record must carry the evidence PROV-R125 names, that clause standing unchanged at its source in the Book. The rule exists because a cryptographic preference creates no authority, as PROV-R125 already bars at its source, and without this clause a technical threshold or an external event could move the estate's keys without anyone deciding anything. Initiation becomes attributable: every migration traces to a recorded decision with its evidence attached, and an unrecorded one is refusable as unauthorized.
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.
Two signatures stand together while cryptography changes hands. The clause requires every migration to include a dual-signature period, retiring and replacement signatures side by side, and requires that period to cover at least one full ratification cycle. Throughout it, historical attribution and verification paths carry through unchanged, the dual-verification duty of PROV-R129 and the deprecation-preservation duty of PROV-R130 binding throughout the interval. The clause exists because an abrupt cutover is where continuity breaks: a reader arriving mid-change could find old signatures unverifiable and new ones unproven, with no interval in which both stand together. The interval it guarantees is one in which both marks stand and historical attribution and verification paths carry through unchanged, for at least one full ratification cycle, verification outcomes remaining separate results, unsupported ones included.
Where this document sits¶
- Identifier: PROV-3
- Status: Draft
- Authority: CONAN-P0, PROV-1, ARCH-2
- Approved by: The Architect
- Depends on: PROV-1, ARCH-2
- Depended on by: PROV-4
- Maps: Authority Map, Dependency Map
This block is generated from the archive's own records when the site is built. It records position only and creates no authority.