Scope boundary

Owns cryptographic agility in the active build-to-distribution path, including algorithm migration, dual-sign periods, verifier-policy evolution, and preservation of required signature sets across redistribution. It does not define release acceptance semantics or archive-lifetime trust continuity.

AID-H-003.002: AID-H-003.008 governs how signing algorithms and verifier requirements evolve; AID-H-003.002 defines and enforces the artifact promotion gate under the active approved policy. Changing cryptography must not silently change release acceptance criteria.

AID-M-002.005: AID-H-003.008 protects active build and distribution during cryptographic migration; AID-M-002.005 preserves classical-plus-post-quantum trust continuity across years of archival storage, rollover, and restore. Operational distribution agility and long-lived archive provenance have different timelines and verification chains.

AID-H-003.006: AID-H-003.008 governs the signature infrastructure and verifier policy; AID-H-003.006 governs the model SBOM and provenance content bound to the artifact. Crypto agility changes how evidence is signed, not what composition facts the attestation must contain.

Implementation guidance

• AID-H-003.008-G001: Version signing policy separately from the artifact so verifier requirements can evolve without rebuilding the entire workflow.
• AID-H-003.008-G002: Use staged dual-sign or hybrid-sign promotion during migration periods and reject artifacts that lose required signatures in transit or redistribution.

AID-H-003.008-G001

Concept:

Crypto agility fails if verifiers are hard-coded to accept exactly one legacy algorithm forever. Separate the artifact from the verification policy and require consumers to evaluate the current policy before accepting the artifact. Promotion policy should evaluate both (1) the artifact's content attestation and release-gate requirements under AID-H-003.002 and AID-H-003.006, and (2) the current verifier policy and accepted signature set under this sub-technique.

Load and validate the signed signer policy

The cryptographic-policy authority publishes a concrete policy with a typed signer count and accepted algorithm set. Consumers verify an immutable snapshot and reject an incomplete, stale, or internally inconsistent policy; no threshold is filled in at deployment time.

set -euo pipefail
umask 077
policy=policy/signer-policy.json
signature=policy/signer-policy.json.sig
snapshot=$(mktemp)
trap 'rm -f "$snapshot"' EXIT
install -m 0600 "$policy" "$snapshot"
cosign verify-blob --key /opt/aidefend/trust/signer-policy.pub --bundle "$signature" "$snapshot"
jq -e '
  (type == "object") and
  ((keys | sort) == ["accepted_signatures","migration_state","minimum_signers","policy_version","schema_version"]) and
  (.schema_version == "aidefend.signer-policy.v1") and
  ((.policy_version | type) == "string" and (.policy_version | length) > 0) and
  ((.migration_state | type) == "string" and (.migration_state | length) > 0) and
  ((.accepted_signatures | type) == "array" and (.accepted_signatures | length) > 0) and
  all(.accepted_signatures[]; (type == "object") and ((keys | sort) == ["required","type"]) and ((.type | type) == "string" and (.type | length) > 0) and ((.required | type) == "boolean")) and
  ([.accepted_signatures[].type] | length == (unique | length)) and
  (.minimum_signers as $minimum | ($minimum | type) == "number" and $minimum >= 1 and $minimum == ($minimum | floor) and $minimum <= (.accepted_signatures | length) and $minimum >= ([.accepted_signatures[] | select(.required)].length))
' "$snapshot" >/dev/null
install -D -m 0440 "$snapshot" /etc/aidefend/crypto/signer-policy.json
sha256sum "$snapshot" > evidence/signer-policy.sha256

Action checklist

• Sign the artifact, the provenance/SBOM attestation, and the verifier-policy bundle as separate but linked objects.
• Require the release gate to verify both content integrity requirements and the currently approved signature policy.
• Version the verifier policy independently so consumers can adopt new algorithms without redefining artifact content semantics.
• Fail closed if the verifier policy is missing, unsigned, or older than the minimum policy version required by the promotion environment.

Action: have CI sign both the artifact and the policy bundle used at promotion time. Consumers should verify the artifact against the signed policy instead of assuming a fixed algorithm forever.

AID-H-003.008-G002

Production implementation: policy-driven dual-signature preservation gate

# File: release/verify_signature_set.py
from __future__ import annotations
from datetime import datetime, timezone

def verify_set(policy: dict, receipt: dict, *, artifact_sha256: str, transfer_id: str) -> dict:
    now = datetime.now(timezone.utc)
    phases = [phase for phase in policy["phases"] if datetime.fromisoformat(phase["not_before"].replace("Z", "+00:00")) <= now < datetime.fromisoformat(phase["not_after"].replace("Z", "+00:00"))]
    if len(phases) != 1:
        raise PermissionError("no unique active migration phase")
    phase = phases[0]
    if receipt["schema_version"] != "aidefend.signature-verification-set.v1" or receipt["artifact_sha256"] != artifact_sha256 or receipt["transfer_id"] != transfer_id or receipt["policy_version"] != policy["policy_version"]:
        raise PermissionError("signature receipt binding differs")
    results = receipt["algorithm_results"]
    if set(results) != set(phase["required_algorithms"]) or any(results[name]["verified"] is not True for name in phase["required_algorithms"]):
        raise PermissionError("required signature set is incomplete or invalid")
    return {"schema_version": "aidefend.signature-set-admission.v1", "artifact_sha256": artifact_sha256, "transfer_id": transfer_id, "policy_version": policy["policy_version"], "phase_id": phase["phase_id"], "required_algorithms": phase["required_algorithms"], "status": "PASS"}

Enforcement: Signature verifiers run in independently pinned images and sign their per-algorithm receipts. The gate verifies those receipt signatures, actual artifact digest, signer identities, key status, proof and trusted-time evidence before calling this function. Re-run after each mirror, air-gap transfer, repack, or redistribution. Migration dates and algorithm sets exist only in the signature-verified policy; losing either required signature blocks promotion.

Before you begin

Apply AID-H-003.008-G002 only when artifact signing algorithms, keys, trust stores, or verifier requirements are being migrated or must remain crypto-agile.

Keep the action safely bounded

deny promotion or consumption when the required signature set, algorithm, identity, proof, freshness, or redistribution preservation fails.

Open-source tools

• Cosign
• in-toto
• slsa-verifier
• python-tuf
• liboqs (prototype PQC interoperability testing only; not recommended for production)
• Open Quantum Safe provider for OpenSSL (oqs-provider; prototype interoperability testing only; not recommended for production)
• OpenSSL 3.5+ (ML-DSA signing primitives; artifact-envelope integration required)

Commercial / hosted tools

• DigiCert Binary Signing
• CyberArk Code Sign Manager
• JFrog Artifactory
• Keyfactor Command
• AWS Key Management Service (ML-DSA signing)

Threat mappings

MITRE ATLAS

• AML.T0115 Publish Poisoned AI Artifacts
• AML.T0010 AI Supply Chain Compromise
• AML.T0010.003 AI Supply Chain Compromise: Model
• AML.T0010.004 AI Supply Chain Compromise: Container Registry
• AML.T0115.001 Publish Poisoned AI Artifacts: Models

MAESTRO

• Supply Chain Attacks (Cross-Layer)
• Supply Chain Attacks (L3)
• Compromised Container Images (L4)

OWASP LLM Top 10 2026

• LLM04:2026 Supply Chain

OWASP ML Top 10 2023

• ML06:2023 AI Supply Chain Attacks

OWASP Top 10 for Agentic Applications 2026

• ASI04:2026 Agentic Supply Chain Vulnerabilities

NIST Adversarial Machine Learning 2025

• NISTAML.051 Model Poisoning (Supply Chain)

Cisco Integrated AI Security and Safety Framework

• N/A

Google Secure AI Framework 2.0 - Risks

• MST: Model Source Tampering
• MDT: Model Deployment Tampering

Databricks AI Security Framework 3.0

• Model 7.3: ML Supply chain vulnerabilities