AZ-020 — Artifact Signing and Attestation Policy v1

Status

Acest document definește politica de semnare și atestare pentru artefactele ATLAS ZERO.

AZ-018 și AZ-019 au definit:

• vault-ul securizat,
• identitatea artefactelor,
• admission gate,
• manifest chain,
• snapshot-uri,
• supersession și revocare.

AZ-020 răspunde la întrebarea: cine are dreptul să afirme că un artefact este autentic, revizuit, aprobat, eligibil pentru release sau revocat și cum se verifică această afirmație înainte ca vault-ul sau pipeline-ul de release să o creadă?

Scopul documentului este să fixeze:

• clasele de semnături și atestări;
• rolurile autorizate;
• ce artefacte cer ce nivel de atestare;
• structura canonicală a atestărilor;
• regulile de validare;
• relația dintre signing, review, approval, supersession și revocation;
• integrarea cu vault-ul, manifesturile și release pipeline-ul.

Acest document se bazează pe:

• AZ-002 până la AZ-019, cu accent direct pe AZ-018 și AZ-019.

Termeni:

• MUST = obligatoriu
• MUST NOT = interzis
• SHOULD = recomandat puternic
• MAY = opțional

1. Obiectiv

AZ-020 răspunde la 10 întrebări:

1. Ce înseamnă semnare vs atestare pentru artefacte?
2. Ce roluri pot semna sau atesta?
3. Ce tipuri de atestare există?
4. Ce artefacte cer ce nivel de încredere?
5. Cum se leagă atestarea de artefact, manifest și scope?
6. Cum se tratează multiple semnături și co-approvals?
7. Cum se face revocarea unei atestări sau retragerea încrederii?
8. Cum se validează proveniența înainte de admitere în vault?
9. Cum se validează proveniența înainte de release?
10. Cum evităm semnături ambigue, reutilizabile în alt context sau insuficiente pentru artefacte critice?

2. Principii

2.1 Signatures prove origin or consent, not magic truth

O semnătură dovedește că o anumită policy/cheie a aprobat sau emis ceva. Nu dovedește singură corectitudinea tehnică a conținutului, decât dacă politica și procesul îi dau această semnificație.

2.2 Attestation is typed

Toate atestările MUST avea tip explicit. Nu există „semnătură generică bună pentru orice”.

2.3 Scope-bound approval

Orice atestare MUST ancora clar:

• artefactul,
• manifestul,
• lotul,
• release-ul,
• sau alt scope exact. O atestare pentru un scope MUST NOT fie reutilizabilă automat în alt scope.

2.4 Higher criticality requires higher assurance

Artefactele TIER_3 și TIER_4 SHOULD cere:

• review explicit,
• approval explicit,
• eventual multiple semnături, nu doar „generated by pipeline”.

2.5 Revocability and supersession are first-class

Încrederea într-un artefact sau într-o atestare se poate schimba. Sistemul MUST suporta:

• revocare,
• supersession,
• quarantine escalation.

2.6 Verification before trust

Vault-ul și release pipeline-ul MUST valida atestările înainte să le folosească drept bază de admitere sau activare.

3. Semnare vs atestare

3.1 Artifact signature

Semnătura brută este dovada criptografică a unei policy/chei asupra unui mesaj canonical.

3.2 Artifact attestation

Atestarea este obiectul semantic care spune:

• cine,
• ce,
• în ce rol,
• în ce scop,
• cu ce tip de verdict,
• la ce moment, a aprobat sau respins.

3.3 Rule

Vault-ul SHOULD opera în termeni de attestation objects, nu doar de semnături izolate.

4. Attestation classes

4.1 Standard classes

ATLAS ZERO SHOULD suporta cel puțin:

• AT_GENERATED_BY_PIPELINE
• AT_HASH_CONFIRMED
• AT_REVIEWED
• AT_SECURITY_REVIEWED
• AT_APPROVED_FOR_VAULT
• AT_APPROVED_FOR_RELEASE
• AT_APPROVED_FOR_MAINNET
• AT_REVOKED
• AT_SUPERSEDED
• AT_QUARANTINE_NOTICE
• AT_RECOVERY_CONFIRMED

4.2 Meaning

AT_GENERATED_BY_PIPELINE

Artefactul a fost produs de un pipeline autorizat.

AT_HASH_CONFIRMED

Hash-ul și identitatea au fost verificate.

AT_REVIEWED

Conținutul a fost revizuit de rolul relevant.

AT_SECURITY_REVIEWED

A trecut review de securitate sau proveniență critică.

AT_APPROVED_FOR_VAULT

Poate intra în vault ca artefact activ conform politicii relevante.

AT_APPROVED_FOR_RELEASE

Poate intra într-un release manifest.

AT_APPROVED_FOR_MAINNET

Nivel foarte înalt; se folosește doar pentru artefacte care intră direct în pachetul de lansare.

AT_REVOKED

Aprobarea sau încrederea este retrasă.

AT_SUPERSEDED

Această atestare este înlocuită de alta mai nouă.

AT_QUARANTINE_NOTICE

Artefactul sau atestarea trebuie tratată ca suspectă.

AT_RECOVERY_CONFIRMED

Folosit pentru artefacte și manifesturi rezultate din recovery validat.

5. Attestation roles

5.1 Standard role classes

Sistemul SHOULD distinge între:

• ROLE_PIPELINE
• ROLE_AUTHOR
• ROLE_REVIEWER
• ROLE_SECURITY_REVIEWER
• ROLE_RELEASE_MANAGER
• ROLE_GENESIS_CUSTODIAN
• ROLE_CONSTITUTION_CUSTODIAN
• ROLE_RECOVERY_OPERATOR
• ROLE_AUDITOR
• ROLE_EMERGENCY_AUTHORITY

5.2 Rule

Rolul care atestă MUST fi legat de policy-ul sa canonicală și validabil.

5.3 Separation recommendation

Pentru artefacte critice, generatorul și aprobatorul SHOULD NOT fi aceeași policy, decât dacă policy-ul explicit permite și riscul este mic.

6. Artifact criticality and required attestation level

6.1 TIER_0_INFO

May need:

• none or
• AT_HASH_CONFIRMED

6.2 TIER_1_NORMAL

SHOULD need:

• AT_GENERATED_BY_PIPELINE or AT_HASH_CONFIRMED

6.3 TIER_2_IMPORTANT

SHOULD need:

• AT_HASH_CONFIRMED
• AT_REVIEWED or equivalent policy-approved combination

6.4 TIER_3_CRITICAL

SHOULD need:

• AT_HASH_CONFIRMED
• AT_REVIEWED
• AT_APPROVED_FOR_VAULT and often AT_SECURITY_REVIEWED

6.5 TIER_4_CONSTITUTIONAL

SHOULD need:

• AT_HASH_CONFIRMED
• AT_REVIEWED
• AT_SECURITY_REVIEWED
• AT_APPROVED_FOR_VAULT
• AT_APPROVED_FOR_RELEASE where applicable
• possibly multi-party approval

6.6 Rule

The required attestation set MUST be policy-driven and deterministic for each artifact class and tier.

7. Attestation target model

7.1 An attestation MAY target:

• one artifact
• one manifest
• one batch
• one release
• one snapshot
• one recovery action
• one supersession relation
• one revocation event

7.2 Structure

AttestationTarget {
  target_class
  target_ref
  scope_hash?
}

7.3 target_class examples

• artifact
• manifest
• batch
• release
• snapshot
• recovery
• supersession
• revocation

7.4 Rule

Atestarea MUST define target_class and target_ref exactly.

8. Artifact attestation object

8.1 Canonical structure

ArtifactAttestation {
  version_major
  version_minor

  attestation_id
  attestation_type
  attestor_policy_ref
  attestor_role_class
  target
  attestation_scope_hash
  verdict_class
  statement_hash
  evidence_refs?
  valid_from_unix_ms?
  valid_until_unix_ms?
  revocation_policy_ref?
  supersedes_attestation_id?
  signature_envelopes
  metadata_hash?
}

8.2 attestation_id

attestation_id = H("AZ:ARTIFACT_ATTESTATION:" || canonical_attestation_body)

8.3 verdict_class

Valori recomandate:

• VERDICT_APPROVE
• VERDICT_CONFIRM
• VERDICT_REJECT
• VERDICT_REVOKE
• VERDICT_QUARANTINE
• VERDICT_SUPERSEDE

8.4 Rule

Semnăturile MUST acoperi exact forma canonică a body-ului cerută de policy.

9. Statement hash semantics

9.1 Purpose

statement_hash leagă atestarea de conținutul semantic exact aprobat.

9.2 Recommended derivation

statement_hash = H("AZ:ARTIFACT_ATTEST_STATEMENT:" || attestation_type || canonical_statement_payload)

9.3 Examples of statement payload

• artifact hash confirmed
• review summary hash
• security review findings hash
• release approval scope hash
• quarantine reason hash
• recovery validation summary hash

9.4 Rule

Text liber MAY exista off-chain, dar efectul normativ MUST depinde de payload canonical.

10. Signature envelopes

10.1 Reuse of generic signature envelope

Atestările SHOULD folosi SignatureEnvelope consistent cu restul protocolului sau un container compatibil.

10.2 Rule

Different signature schemes MAY be allowed only if registry-ul de policy și protocol version le acceptă explicit.

10.3 Multiple signatures

O atestare MAY avea:

• single signature
• multisig bundle
• committee bundle depending on policy.

11. Scope binding

11.1 Need

O aprobare pentru un artefact în batch A nu trebuie reutilizată automat pentru release B.

11.2 attestation_scope_hash

Acest câmp SHOULD ancora:

• batch_id
• release_id
• manifest_id
• snapshot_id
• chain_id
• network_class as needed.

11.3 Rule

Atestările critice MUST be scope-bound.

12. Validity windows

12.1 Need

Unele aprobări sunt temporare.

12.2 Rule

Atestările MAY avea:

• valid_from_unix_ms
• valid_until_unix_ms

12.3 Examples

• temporary quarantine
• temporary release hold override
• recovery approval valid only for one window
• mainnet approval valid only for one release candidate window

12.4 Rule

Atestările expirate MUST NOT satisface politici care cer atestare activă.

13. Revocation policy for attestations

13.1 Need

O atestare dată greșit sau devenită nesigură trebuie revocabilă.

13.2 Rule

Critical attestation types SHOULD define revocation_policy_ref.

13.3 Effects

Revocarea unei atestări MAY cause:

• artifact to become inactive for release
• manifest to become unusable for promotion
• artifact to move to quarantine
• need for new approval chain

13.4 Important distinction

Revocarea unei atestări nu înseamnă automat ștergerea artefactului. Înseamnă retragerea încrederii/provenienței pentru anumit scop.

14. Supersession of attestations

14.1 Need

Uneori aprobarea veche este înlocuită de una nouă.

14.2 Rule

supersedes_attestation_id MAY referi atestarea veche.

14.3 Use cases

• new security review replaces older one
• new release approval for updated manifest
• final mainnet approval supersedes candidate approval

14.4 Rule

Supersession chain MUST be acyclic.

15. Attestation families by purpose

15.1 Provenance family

• generated_by_pipeline
• hash_confirmed

15.2 Review family

• reviewed
• security_reviewed
• auditor_confirmed

15.3 Admission family

• approved_for_vault
• quarantine_notice
• revoked

15.4 Release family

• approved_for_release
• approved_for_mainnet

15.5 Recovery family

• recovery_confirmed
• superseded

16. Artifact signing policy matrix

16.1 Matrix concept

Policy SHOULD define, for each artifact class:

• minimum attestations required
• allowed attestor roles
• whether multiple signatures required
• whether security review mandatory
• whether release manager approval mandatory
• whether constitutional custodian approval required

16.2 Example matrix guidance

spec_document, TIER_3

• reviewed
• approved_for_vault

genesis_blob, TIER_4

• hash_confirmed
• security_reviewed
• approved_for_release
• approved_for_mainnet
• genesis_custodian approval

release_binary, TIER_3/TIER_4 depending scope

• generated_by_pipeline
• hash_confirmed
• security_reviewed
• approved_for_release

constitutional doc, TIER_4

• reviewed
• security_reviewed
• constitution_custodian approval
• approved_for_vault

16.3 Rule

This matrix MUST be explicit, not tribal knowledge.

17. Admission-time verification rules

17.1 Vault admission MUST verify:

1. artifact identity matches attested target
2. attestation type satisfies artifact policy
3. attestor role class is allowed
4. signature(s) valid
5. scope hash compatible
6. validity window active if required
7. attestation not revoked
8. supersession chain if present is coherent
9. minimum attestation set satisfied

17.2 Rule

If required attestations are missing, artifact MAY remain in staging or quarantine but MUST NOT become active vault truth.

18. Release-time verification rules

18.1 Release pipeline MUST verify:

1. all required artifacts present
2. all required artifact attestations present
3. release manifest itself attested appropriately
4. no critical artifact attestation revoked
5. no required attestation expired
6. compatibility scope matches target network/release
7. no conflicting supersession unresolved
8. required signers/roles satisfied

18.2 Rule

Release without full attestation closure MUST be blocked.

19. Mainnet-time verification rules

19.1 Before mainnet launch, pipeline SHOULD verify:

• genesis attestation chain complete
• release binary attestation chain complete
• mainnet approval attestation present for final package
• no active quarantine/revocation on critical artifacts
• scope matches exact launch release and exact genesis hash

19.2 Rule

A mainnet launch package MUST be scope-locked to exact release candidate and exact genesis.

20. Committee-based approvals

20.1 Need

Some artifacts may require more than one signer.

20.2 Model

An attestation MAY be approved by:

• multisig policy
• committee policy
• threshold bundle

20.3 Rule

The attestation object remains single canonical object; signature_envelopes or bundle structure prove threshold satisfaction.

20.4 Use cases

• mainnet release approval
• constitutional artifact approval
• recovery confirmation for critical scope
• emergency replacement binary authorization

21. Reviewer independence

21.1 Recommendation

For critical artifacts, reviewer and security reviewer SHOULD be distinct roles/policies.

21.2 Stronger recommendation

For TIER_4 artifacts, release manager SHOULD NOT be the only approver.

21.3 Rule

If independence is required by policy, same-policy dual signatures MUST NOT satisfy it.

22. Quarantine notices

22.1 Purpose

An attestation can also reduce trust, not only add it.

22.2 Example structure

A AT_QUARANTINE_NOTICE SHOULD indicate:

• target artifact/manifest
• reason hash
• scope
• who issued notice
• whether local-only or vault-policy-wide

22.3 Rule

Critical quarantine notices SHOULD cause automated revalidation before artifact remains active in sensitive scopes.

23. Revocation of artifact approvals

23.1 Cases

• artifact later found malformed
• signature chain compromised
• reviewed artifact discovered unsafe
• release candidate later found inconsistent
• recovery artifact found untrustworthy

23.2 Rule

Revoking AT_APPROVED_FOR_RELEASE MUST make artifact or release ineligible unless replaced by valid new approval.

23.3 Rule

Revoking AT_HASH_CONFIRMED is rare and severe; it implies integrity/provenance failure.

24. Attestation graph

24.1 Need

Artifacts, manifests and releases may accumulate multiple attestations.

24.2 Model

The attestation graph SHOULD be queryable by:

• target_ref
• attestation_type
• active/revoked/superseded state
• attestor role
• scope hash

24.3 Rule

Truth is not “latest signature by timestamp”. Truth is derived by policy and attestation status.

25. Active attestation derivation

25.1 For a given target and type, an attestation is active if:

• it exists
• it is valid structurally
• signatures are valid
• validity window is active if present
• it has not been revoked
• it has not been superseded in that exact semantic scope

25.2 Rule

Policies MUST use active attestation, not merely existing attestation.

26. Attestation conflict model

26.1 Conflicts examples

• one approval and one reject for same artifact and same release scope
• one quarantine notice and one mainnet approval in same unresolved scope
• two contradictory security reviews under exclusive policy

26.2 Rule

Policies MUST define conflict resolution. Recommended fail-safe:

• fail closed for critical artifacts
• quarantine until resolved
• require explicit superseding approval or revocation chain

27. Attestation evidence refs

27.1 Purpose

Reviews and approvals often depend on evidence.

27.2 evidence_refs MAY include

• review report hash
• conformance report hash
• audit finding closure hash
• snapshot verification hash
• build provenance manifest
• recovery replay result hash

27.3 Rule

For critical approvals, evidence_refs SHOULD be present and stable.

28. Provenance for generated artifacts

28.1 Generated-by-pipeline

AT_GENERATED_BY_PIPELINE SHOULD include:

• pipeline identity
• build environment hash
• source artifact refs
• output artifact id
• pipeline policy approval

28.2 Rule

Generated artifacts SHOULD be linkable to source inputs, not just signed blindly after fact.

29. Hash-confirmation attestations

29.1 Purpose

Confirms that a trusted role recomputed and confirmed artifact identity.

29.2 Recommended use

For:

• release binaries
• genesis files
• constitutional manifests
• snapshots used for recovery
• conformance corpus bundles

29.3 Rule

Hash-confirmation SHOULD refer to exact artifact_id, content_hash and canonical_hash.

30. Review attestations

30.1 Reviewed

AT_REVIEWED SHOULD state:

• review scope
• review summary hash
• review status
• reviewer role

30.2 Security reviewed

AT_SECURITY_REVIEWED SHOULD additionally state:

• security scope
• unresolved findings hash if any
• review severity summary hash
• approval or conditional approval semantics

30.3 Rule

A security review attestation SHOULD NOT mean “perfectly secure”. It means review process with specific scope and verdict occurred.

31. Release approval attestations

31.1 Purpose

Marks artifacts or release manifest as eligible for release process.

31.2 Recommended payload

• target release manifest ref
• exact artifact or release id
• release scope hash
• target network class
• compatibility summary hash
• approval verdict

31.3 Rule

Release approval MUST be tied to a specific release bundle, not broad “this binary is generally OK forever”.

32. Mainnet approval attestations

32.1 Purpose

Highest release-grade attestation.

32.2 Recommended requirements

For mainnet package, SHOULD require:

• release manager
• security reviewer or committee
• genesis custodian if genesis involved
• possibly protocol lead or constitutional authority per local process

32.3 Rule

Mainnet approval MUST be narrow:

• exact release bundle
• exact genesis hash
• exact chain_id / network class
• exact launch candidate

33. Recovery attestations

33.1 Purpose

Confirms that recovery-generated artifacts and manifests are acceptable.

33.2 Uses

• restored folder state
• recovery manifest
• rebuilt index checkpoint
• recovered release package after corruption event

33.3 Rule

Recovery-generated truth SHOULD require recovery-specific confirmation before becoming active in critical scopes.

34. Attestation validation pipeline

34.1 Canonical order

1. decode canonical
2. recompute attestation_id
3. validate attestation_type known
4. validate target exists or is valid referenced object
5. validate attestor role/policy exists
6. validate signatures
7. validate scope binding
8. validate time window
9. validate revocation/supersession status
10. validate type-specific policy requirements
11. derive active/inactive/conflicted status

34.2 Rule

This pipeline SHOULD be deterministic across implementations.

35. Duplicate and replay protection

35.1 Exact duplicate

Same attestation object reintroduced: harmless duplicate, not new truth.

35.2 Semantic duplicate

Different object wrapping same verdict and same scope under same attestor may be duplicate-semantic.

35.3 Rule

System SHOULD derive:

attestation_fingerprint = H("AZ:ATTEST_FP:" || attestation_type || target || scope_hash || verdict_class || attestor_policy_ref)

35.4 Purpose

Prevents:

• repeated counting
• duplicate reward or policy satisfaction
• ambiguity in active attestation sets

36. Attestation policy matrix storage

36.1 The signing/attestation policy SHOULD be itself represented in canonical form:

ArtifactAttestationPolicyMatrix {
  policy_version
  rules: [ArtifactPolicyRule]
}

36.2 ArtifactPolicyRule

ArtifactPolicyRule {
  artifact_type
  artifact_tier
  required_attestation_types
  allowed_attestor_roles
  minimum_distinct_role_count?
  require_security_review: bool
  require_release_manager: bool
  require_mainnet_scope_lock: bool
}

36.3 Rule

Vault and release pipeline MUST use one authoritative active matrix, not ad-hoc local copies.

37. Integration with AZ-019 manifests

37.1 Manifest entries MAY store:

• attestation_root
• attestation_refs
• approval_refs
• revocation refs

37.2 Rule

Manifest truth about artifact status SHOULD take attestation status into account where artifact policy requires it.

37.3 Example

An artifact may physically exist and be structurally valid but remain AS_STAGED until AT_APPROVED_FOR_VAULT is active.

38. Integration with AZ-018 admission machine

38.1 Admission decision depends on:

• artifact structural validity
• identity derivation
• duplicate/supersession state
• and required active attestations

38.2 Rule

Critical artifacts MUST NOT bypass attestation requirements just because hashes are correct.

39. Attestation revocation object

39.1 Canonical structure

ArtifactAttestationRevocation {
  version_major
  version_minor

  revocation_id
  target_attestation_id
  revoker_policy_ref
  reason_hash
  effective_unix_ms
  signature_envelopes
}

39.2 Rule

Revocation validity depends on revocation policy of target attestation type or target attestation object.

39.3 revocation_id

revocation_id = H("AZ:ARTIFACT_ATTEST_REVOCATION:" || canonical_revocation_body)

40. Attestation supersession object

40.1 Optional explicit object

For some pipelines, explicit supersession object is useful:

ArtifactAttestationSupersession {
  supersession_id
  old_attestation_id
  new_attestation_id
  superseding_policy_ref
  reason_hash?
}

40.2 Rule

Supersession MUST be acyclic and scope-consistent.

41. Critical anti-patterns

Systems SHOULD avoid:

1. using raw detached signatures with no attestation type
2. approving artifacts by filename only
3. mainnet approval with no genesis or release scope lock
4. same person/policy self-reviewing everything critical by default
5. expired approvals still counted as active
6. revocation by deletion instead of explicit revocation object
7. ambiguous security review that doesn't say approve/reject/conditional
8. counting two signatures from same role when policy requires distinct roles
9. release manager approval without verified build provenance
10. treating attestation text comments as normative instead of canonical payload

42. Formal goals

AZ-020 urmărește aceste obiective:

42.1 Provenance soundness

Critical artifacts can be linked to authorized producers and approvers.

42.2 Approval clarity

The system knows exactly which approvals are required for which artifact classes.

42.3 Active trust derivation

It is deterministically clear whether an attestation is active, revoked, superseded or insufficient.

42.4 Scope safety

Approvals cannot be silently reused outside their intended scope.

43. Formula documentului

Artifact Signing/Attestation = typed approval objects + role-bound signatures + scope lock + active status derivation + revocation/supersession support

44. Relația cu restul suitei

• AZ-018 definește admission gate și vault identity.
• AZ-019 definește manifest schema.
• AZ-020 definește cine are dreptul să spună că un artefact este autentic, revizuit sau aprobat pentru vault/release.

Pe scurt: AZ-018 și AZ-019 protejează forma și lanțul artefactelor; AZ-020 protejează proveniența și aprobarea lor.

45. Ce urmează

După AZ-020, documentul corect este:

AZ-021 — Secure Build and Release Pipeline

Acolo trebuie fixate:

• pipeline-ul concret de build,
• proveniența binarelor,
• reproducible builds,
• chain of custody dintre source, artifact, manifest și release,
• și regulile de promotion între staging, candidate și final release.

Închidere

Un vault fără politică de semnare și atestare păstrează fișiere intacte, dar nu știe pe cine să creadă despre ele. Un sistem serios cere mai mult: nu doar hash corect, ci și rol corect, nu doar semnătură validă, ci și scope corect, nu doar approval existent, ci approval activ și nerevocat.

Acolo începe proveniența verificabilă reală.