Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 154, Processes, data elements and documents in commerce, industry and administration.
This first edition of ISO 99999 cancels and replaces no prior standard.
Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html.
Introduction
0.1 The regulated-artifact trust problem
Regulated industries — legal metrology, pharmaceuticals, food safety, defense procurement, environmental monitoring — issue conformity certificates, test results, calibration records, and compliance attestations whose trustworthiness carries legal, economic, and safety consequences. These artifacts must be verifiable by inspectors, customs authorities, and trading partners across organizational and jurisdictional boundaries, often years or decades after issuance.
A pharmaceutical batch release certificate must demonstrate not just that a signing key was valid, but that the batch was produced by an authorized manufacturer, inspected by a certified operator, manufactured under compliant environmental conditions, and released at a verifiable time. A legal metrology certificate must prove that the measuring instrument was type-approved, tested by an accredited laboratory, and calibrated against traceable standards — and that this entire chain of authority remains valid at the time and place of verification.
No existing framework combines all of these properties. Traditional public key infrastructure (PKI) binds a key to an identity; it does not bind an artifact to the real-world conditions under which it was produced. Blockchain-based attestation systems (ISO 22739:20201)) provide immutability but no scope enforcement, no condition lifecycle, and no revocation propagation to bound artifacts. Software signing transparency systems (e.g., Sigstore) address code provenance but not multi-dimensional convergence. The result is that regulated industries rely on paper certificates, PDF scans, and ad-hoc digital signatures — none of which provide the trust guarantees that regulators and trading partners require.
Regulatory frameworks are increasingly mandating digital provenance. The EU Digital Product Passport (DPP) requires verifiable product lifecycle data for regulated goods. The US FDA Drug Supply Chain Security Act (DSCSA) mandates track-and-trace for pharmaceuticals. The OIML digital certificate initiative calls for machine-verifiable metrological conformity. These mandates create a demand for standardized trust infrastructure that no existing technology satisfies.
0.2 SIGNATIF
This document specifies SIGNATIF — the Sealed Interoperable Graduated Non-repudiable Anchored Trust Infrastructure Framework. SIGNATIF binds signing authority to a multi-dimensional scope, establishes artifact trustworthiness through the convergence of independent attestations from multiple trust dimensions (authority, person, time, location, environment, and extensible others), and treats trust as a lifecycle: trust is granted, sustained, and repudiated through formal threshold-gated mechanisms.
SIGNATIF is designed for the regulated-artifact trust problem: artifacts that must be verifiable offline by anyone holding the trust anchor bundle, graduated in confidence through objective coverage assessment, and revocable retroactively when the real-world conditions that made them trustworthy no longer hold.
NOTE 1 The concepts in this document were validated through a digital metrology certificate system developed under the OIML SMART program, which demonstrated multi-dimensional attestation, threshold signing, transparency logging, and scope enforcement in a five-tier legal metrology hierarchy.
NOTE 2 The name SIGNATIF derives from Latin signare (“to mark with a seal, to sign”), the root of sign, signature, and signet, combined with the adjectival suffix -tif. The signing root captures the framework’s premise: trustworthiness is established by what is verifiably signed, not by who is trusted.
0.3 Challenges with traditional PKI
Traditional PKI, as specified in ISO/IEC 9594-8 (X.509) and profiled for Internet use in IETF RFC 5280, is a mature and widely deployed infrastructure. It successfully supports server authentication (TLS), code signing, document signing (e.g., PAdES for PDF), email security (S/MIME), and device identity. Publicly trusted CAs are subject to organizational security requirements including WebTrust or ETSI EN 319 411 audits, which provide an information security management system framework analogous to ISO/IEC 27001.
PKI is well suited to its core problem: binding a public key to an identity via a single delegation chain, verified by walking from a trusted root to a leaf certificate. For many applications — particularly transient sessions where the signer and verifier interact in real time — this model is sufficient and its ecosystem maturity is a significant advantage. PKI’s standardized certificate formats, interoperable trust stores, mature HSM and key management infrastructure, established audit frameworks (WebTrust, ETSI), and decades of operational experience are substantial engineering assets. SIGNATIF reuses PKI’s cryptographic primitives and builds on its organizational assurance frameworks.
However, when PKI is applied to persistent artifacts whose trustworthiness must be independently verifiable over long periods, graduated in confidence, and revocable retroactively, limitations emerge. These limitations are not deficiencies in PKI’s implementation; they are consequences of its design boundary — PKI validates the key and identity; the application validates the content:
Threshold is optional, not required. PKI does not prohibit threshold signing at intermediate tiers — cryptographic threshold schemes implementations exist and HSM-based M-of-N quorum is common at the root. However, X.509 does not require threshold, and deployment practice overwhelmingly uses single-key intermediates. SIGNATIF makes threshold mandatory at every authority level as a conformance requirement.
Scope extensions exist but are inconsistently enforced. X.509 Name Constraints and Extended Key Usage are machine-checkable, signed extensions that constrain a CA’s authority. However, enforcement is implementation-dependent — many verifiers do not check Name Constraints — and these mechanisms constrain only names and key-usage types, not multi-dimensional authorization boundaries. SIGNATIF requires multi-dimensional scope enforcement as a hard, mandatory verification step at every delegation link.
Multiple signatures supported but no convergence model. Several PKI signature formats support multiple signatures on one document (CMS multiple signerInfos, PAdES, XMLDSig). However, the PKI model provides no standardized mechanism to evaluate the combined trustworthiness of independently-signed attestations — their semantic relationship, their independence, or how their convergence should be assessed. SIGNATIF provides a coverage report and classification policy for this purpose.
Chain validation is binary; trust graduation is policy-interpreted. A certificate is either valid or revoked at the chain-validation level. PKI does carry assurance metadata (EV/OV/DV certificate types, Certificate Policy OIDs, eIDAS (Regulation (EU) 2024/1183) qualified status), and verifiers can apply graduated policies based on these. However, the graduation is policy-interpreted and non-standardized in its computation. SIGNATIF provides a normatively specified coverage report and classification policy so that two conforming verifiers compute identical classification labels for the same dimensional coverage.
Revocation captures key compromise, not condition invalidation. PKI provides robust certificate-level revocation through CRLs and OCSP, with mature deployment. Its revocation model is designed for and effective at key-compromise and mis-issuance scenarios: when a CA or end-entity certificate is revoked, dependent sessions and new signature validations fail chain validation. However, PKI’s revocation is key-centric — it captures “this key is no longer trustworthy.” It cannot express “the real-world conditions under which this artifact was produced are no longer valid” — a calibration certificate expiring, a compliance status changing, an accreditation being withdrawn. This separation of key validity from content validity is a deliberate design boundary in PKI — the certificate validates the key; the application validates the content. Long-term validation schemes (CAdES-A, PAdES-LTV) partially address archive-time validity but still operate at the certificate/signature level. SIGNATIF integrates condition binding into the verification framework itself.
Timestamps are available but not required for verification. RFC 3161 timestamp authorities and X.509 counter-signatures provide strong external time evidence and are legally recognized in many jurisdictions (e.g., eIDAS qualified electronic timestamps). However, standard PKI path validation does not require timestamp evidence — notBefore/notAfter are issuer-asserted and suffice for chain validation. SIGNATIF makes independent time attestation a first-class trust dimension.
Transparency is mandatory in web PKI but not in PKI generally. Certificate Transparency (IETF RFC 6962) is mandatory for publicly trusted TLS certificate issuance, and major browsers reject certificates without embedded SCTs. However, CT is specific to the web PKI; code signing, email (S/MIME), document signing, and private PKI deployments do not require transparency. SIGNATIF makes transparency log inclusion a universal requirement across all deployment types.
Authorization is static at the certificate level. Certificates assert “this key is authorized” as a fact for the certificate’s validity period. X.509 attribute certificates can bind attributes to a holder, but these attributes describe the holder, not conditions about a specific artifact’s content. SIGNATIF scope conditions are predicates about the artifact’s content and production context, evaluated at verification time.
Possession-based authenticity by default. A static PKI certificate and its signed artifact can be copied and replayed. Challenge-response mechanisms exist in PKI ecosystems (mTLS channel binding, nonce-based protocols) but are application-layer additions. SIGNATIF specifies challenge-response as a conformance capability for device signers.
Attributes bind to holders, not to artifact production conditions. X.509 attribute certificates and qualified certificates carry cryptographically signed attributes (roles, clearance levels, qualifications). However, these describe the certificate holder, not the conditions under which a specific artifact was produced. SIGNATIF scope conditions bind to the artifact’s content and production context.
These limitations are specific to the persistent-artifact trust problem. For server authentication, code signing under active policy enforcement, and document signing within organizational trust boundaries, PKI remains the appropriate and mature choice (see Annex B for a detailed comparison). SIGNATIF addresses the problem space where these limitations become operationally significant: artifacts that must be verifiable offline, graduated in trust, revocable retroactively, and attested by multiple independent dimensions of reality.
0.3.1 Simplicity and complexity: a nuanced comparison
Whether SIGNATIF is simpler or more complex than PKI depends on the dimension of comparison and the perspective of the stakeholder:
Where SIGNATIF is simpler:
Scope enforcement is algorithmic, not policy-interpreted. PKI constrains CA authority through dozens of certificate extensions (Name Constraints, EKU, Certificate Policies, Policy Mappings, Inhibit Any-Policy) that interact in implementation-dependent ways, backed by external policy documents (the CA/B Forum Baseline Requirements run to hundreds of pages). SIGNATIF uses one multi-dimensional scope structure verified by one deterministic narrowing algorithm. The verifier does not interpret policy; it runs an algorithm on signed fields.
Trust assessment is standardized. In PKI, deciding how much to trust a certificate requires each application to interpret EV/OV/DV status, Certificate Policy OIDs, CT presence, and revocation freshness — each application re-derives the logic. SIGNATIF provides one coverage report; the application compares the classification to its acceptance threshold.
Cross-domain trust is artifact-level, not CA-level. PKI cross- certification involves bridge CA topology, cross-certificates with constraints, and path building across multiple hierarchies. SIGNATIF handles cross-domain trust through co-signatures on the artifact itself — no bridge CAs, no cross-certificate management.
Revocation is unified. PKI offers CRLs, OCSP, OCSP stapling, OCSP must-staple, CRLite, CRLSets, and short-lived certificates — multiple competing mechanisms with different deployment profiles. SIGNATIF has one propagation model with one offline strategy (CRL grace period).
Where SIGNATIF is more complex — or can be, depending on configuration:
Issuance scales with dimensional coverage. An artifact may carry N co-signatures from independent trust dimensions. However, a minimal deployment with a single data dimension and 1-of-1 threshold at every level produces artifacts structurally equivalent to PKI-signed documents. Complexity is opt-in: a deployment adds dimensions and threshold only where its trust model requires them.
Threshold is required at every level — but 1-of-1 is conforming. PKI’s single-key CA model is a special case of SIGNATIF’s threshold model with T = N = 1. A single party holding all signing keys (N-of-N with one party) is also conforming. No ceremony infrastructure is needed for 1-of-1. SIGNATIF generalizes PKI: PKI-like deployments are one configuration of the SIGNATIF framework.
Transparency infrastructure is mandatory — but can be minimal. SIGNATIF requires a transparency log, but the minimum is a single operator with a single mirror and no gossip quorum (a lower classification label). Deployments add mirrors, gossip, and multi-log attestation proportionate to their risk model.
The verification pipeline has more steps — but each is optional except the hard checks. The minimum verification is: format validity, signature validity, chain integrity, scope narrowing, and revocation status — structurally similar to PKI path validation. Transparency, time anchoring, cross-domain diversity, multi-log quorum, and classification are soft checks that contribute to the classification label but are not required for basic acceptance.
PKI as a special case of SIGNATIF: A SIGNATIF deployment configured with 1-of-1 threshold at every level, a single data dimension, no scope conditions, transparency with a single log and no gossip, and a binary acceptance policy (accept the minimum classification label) is functionally equivalent to a PKI deployment. This is not a degenerate case — it is a conforming configuration. Organizations can start with this PKI-equivalent baseline and incrementally add dimensions, threshold protection, transparency infrastructure, and graduated trust as their requirements evolve. SIGNATIF is not PKI plus extra complexity; it is a general framework in which PKI’s trust model is one configuration among many.
The net trade-off: For simple trust problems — single signer, binary acceptance, no offline verification beyond cached CRLs — PKI is the simpler choice and benefits from decades of ecosystem maturity. For problems requiring multi-party attestation, graduated assessment, condition lifecycle management, offline verification, or threshold protection at intermediate levels, SIGNATIF provides these as integrated, standardized, algorithmically verified mechanisms — rather than requiring each application to assemble them ad hoc from PKI primitives, policy documents, and custom code.
0.4 The trust convergence problem
Consider an artifact that asserts a real-world fact: a quantity value, a timestamp, an environmental context, and an authorizing party. For a verifier to trust this artifact, multiple independent dimensions of reality must converge:
Authority. Was the signing key authorized by a legitimate delegation chain whose scope covers this artifact?
Person. Was a specific human operator accountable for the act, bound to the artifact by a separate signature?
Time. Can the time of signing be established independently of the signer’s own assertion, anchored to an external time source?
Location. Was the artifact produced at a location consistent with its claimed provenance?
Environment. Were the ambient conditions (temperature, humidity, sensor state) at the time of signing consistent with the artifact’s validity conditions?
In traditional PKI, only the first dimension — authority — is represented cryptographically. The remaining dimensions are carried as unsigned metadata, trusting the signer to report them honestly. A compromised key is sufficient to forge an artifact with fabricated time, location, and environmental context.
SIGNATIF makes every dimension a cryptographic co-signature dimension, each backed by its own trust tree, each independently verifiable. The artifact becomes a convergence point of independent attestations rather than a single-authority assertion.
0.5 Why SIGNATIF
Persistent artifacts — records whose trustworthiness must outlive the signing session and, in many cases, outlive their issuers — face a problem that traditional PKI was not designed to solve. PKI binds a key to an identity; it does not bind an artifact to the real-world conditions under which it was produced, does not require independent convergence of multiple trust dimensions, does not graduate trust based on the depth and breadth of attestation, and cannot revoke an artifact when the conditions that made it trustworthy no longer hold.
SIGNATIF exists because these capabilities are not optional refinements of PKI — they cannot be achieved in a standardized, interoperable, cryptographically enforced manner within the PKI model as currently specified. Adding scope enforcement to X.509 certificates does not make scope machine-checkable; adding multiple signatures to a PDF does not create a convergence model; adding a CRL entry does not propagate to condition-dependent artifacts. These require a new architecture.
0.5.1 Why not multiple PKIs?
A natural question is: why not issue separate certificates from separate PKI hierarchies — one for authority, one for operator identity, one for timestamping, one for location — and have each independently sign the same artifact?
Multiple PKIs can achieve multi-party signing, and several of SIGNATIF’s capabilities can be approximated with PKI extensions and application-level glue. X.509 Name Constraints can restrict a CA’s domain; PAdES supports multiple signatures on a PDF; OCSP provides real-time revocation status; CT logs exist for multiple hierarchies. A sufficiently determined application developer could build an ad-hoc convergence system on top of multiple PKIs.
However, the result would be non-standardized, non-interoperable, and enforced by application policy rather than by cryptographic invariant. The following distinctions explain why SIGNATIF exists as a separate framework:
Convergence is enforced, not assumed. Multiple PKI signatures can be applied to the same document, but nothing in the PKI model ensures all signers attest the same canonical bytes. PAdES counter-signatures create ordering dependencies (signature 3 signs over signature 2); if signature 2 is later revoked, the dependency chain becomes ambiguous. SIGNATIF requires all co-signatures to attest the same canonical payload hash independently, with no ordering dependency, and partial attestation is non-conforming.
Scope is cryptographically checked, not policy-defined. X.509 Name Constraints and Extended Key Usage can restrict a CA’s authority, but enforcement is implementation-dependent — many verifiers ignore Name Constraints. SIGNATIF’s scope is checked at every delegation link as a hard verification failure. The scope is multi-dimensional (domain, class, conditions), not name-based.
Conditions bind to artifact content, not certificate holder. X.509 attribute certificates can bind attributes to a holder, and OCSP provides real-time certificate status. But neither mechanism can express “this attestation is valid only if the measured value in the artifact is within tolerance” — a predicate about the artifact’s content evaluated at verification time. SIGNATIF scope conditions are such predicates.
Revocation propagates to conditions, not just keys. In multiple PKIs, revoking a calibration certificate tells the verifier the certificate is revoked. It does not flag the measurement records that used that calibration — there is no hash-binding between the artifact and the real-world states under which it was produced. The application must discover and enforce this link itself, with no standardized mechanism. SIGNATIF standardizes the hash-binding and propagates state revocation to all dependent artifacts.
Combination is standardized, not reinvented. Multiple PKIs produce N independent pass/fail results. Each application decides what these mean — and every application reinvents the logic. SIGNATIF provides a coverage report and classification policy that two conforming verifiers compute identically, enabling interoperability between independently developed verification systems.
Transparency covers artifacts, not just certificates. CT logs track certificate issuance, not artifacts. A multi-PKI deployment would need separate, ad-hoc logging for each PKI’s signed artifacts. SIGNATIF requires every certificate and artifact to be in a transparency log, and inclusion is a verification requirement.
The argument is not that multiple PKIs cannot approximate some SIGNATIF capabilities. The argument is that standardization, cryptographic enforcement, and cross-implementation interoperability require a framework that treats convergence, scope, conditions, transparency, and graduated trust as integrated, normatively specified mechanisms — not as ad-hoc application-level conventions layered on top of disconnected certificate hierarchies.
0.6 How SIGNATIF works
SIGNATIF addresses the persistent-artifact trust problem through five integrated mechanisms:
Cryptographic scope. Each authority’s authorization boundary is a signed, multi-dimensional field (domain, class, conditions) that narrows monotonically at every delegation link. Scope violations are detected at verification time, not by after-the-fact audit.
Convergent attestation. Each artifact carries co-signatures from multiple independent trust dimensions — authority, person, time, location, environment, and extensible others. Trustworthiness is established by the convergence of independent attestations, not by a single signer.
Threshold at every level. No single key compromise compromises any authority in the hierarchy. Threshold signing is required at every level, not just the root.
Trust as a lifecycle. Trust is granted through signing, sustained through transparency and time-anchoring, and repudiated through revocation that propagates to condition-dependent artifacts. When the real-world conditions that made an artifact trustworthy change, the framework detects it and flags the affected artifacts — including those signed under still- valid keys.
Graduated, offline-verifiable trust. The verifier produces an objective coverage report reflecting dimensional coverage and verification path robustness, applies the scheme’s classification policy to derive a grade label, and applies its own acceptance threshold to that label. All of this is verifiable offline by anyone holding the trust anchor bundle.
These mechanisms are specified as modular requirements (see Clause 5), allowing implementations to claim conformance to the roles they perform (verifier, issuing authority, root authority, etc.) without implementing the entire framework.
0.7 Differentiation from traditional PKI
This document specifies a trust infrastructure whose design differs from traditional PKI (X.509, web TLS) in several structural respects. Each difference exists because traditional PKI was designed for a different problem — authenticating a server identity in a transient session — and was not designed to authenticate the trustworthiness of persistent artifacts. Table 1 summarizes the structural differences.
| # | Traditional PKI | This document (SIGNATIF) |
|---|---|---|
| 1 | Scope is policy-defined (Baseline Requirements), not carried in the certificate. | Scope is a first-class signed field, cryptographically enforced at every chain link; widening any dimension is a hard verification failure. |
| 2 | One signer per object. | N signatures per artifact, each from a different trust dimension (data, person, time, location, environment). |
| 3 | Root key held by one entity; single point of compromise. | Threshold at root and at every delegated authority; no single key compromises any level. |
| 4 | Bridge CAs are single entities. | Federated Trust Authorities are threshold groups of independent organizations with aggregate keys. |
| 5 | Certificate Transparency is an optional monitoring overlay. | Transparency inclusion is a verification requirement; un-logged artifacts are downgraded or rejected. |
| 6 | Valid or revoked; binary. | Graduated trust classification reflecting coverage report; enables risk-based policy. |
| 7 | Revocation invalidates a certificate; artifacts already signed remain valid. | Revocation propagates to every artifact transitively bound to the revoked state. |
| 8 | notBefore / notAfter are self-asserted by the issuer. | Artifacts anchored to an external time source; independent proof of existence at a time. |
| 9 | One root per hierarchy; cross-certification operates at CA level. | Hierarchical, federated, cross-recognized, and mesh topologies are first-class conformance profiles. |
| 10 | Certificates assert “this key is authorized”; authorization is static. | Scope includes executable conditions evaluated at verification time; binds authority to live state. |
| 11 | Certificates are static and copyable; authenticity is proven by possession. | Challenge-response: verifier challenges for a fresh nonce-bound signed artifact; counterfeits cannot answer. |
| 12 | Multiple CT logs exist but multi-log inclusion is not required. | Federated artifacts require inclusion in M-of-K independent logs; no single operator controls the record. |
| 13 | Cross-certification is CA-to-CA; happens above the artifact. | Cross-domain trust fusion at the artifact level: the artifact itself carries co-signatures from independent hierarchies. |
| 14 | One dimension: authority / identity. | Multi-dimensional: time, location, and environment are cryptographic co-signature dimensions with their own trust trees. |
0.8 Document structure
This document is organized as follows:
Clause 1 states what is and is not specified.
Clause 2 defines the terminology used throughout.
Clause 4 states the design principles underlying the differentiators above.
Clause 5 defines the conformance class hierarchy and profiles.
Clause 6 specifies the trust graph model and the delegation structure.
Clause 7 specifies the artifact format and signature binding, including co-signatures, cross-domain fusion, and multi-dimensional attestation.
Clause 8 specifies the cryptographic algorithms, composite signatures, and algorithm agility.
Clause 9 through Clause 19 specify the operational requirements: threshold signing, scope governance, revocation, transparency, verification, key lifecycle, delivery, ceremonies, deployment manifest, governance, and algorithm agility.
Clause 20 specifies the security considerations and threat model.
Annex A provides the normative conformance test suite.
Annex B compares SIGNATIF with traditional PKI and provides use case guidance.
Annex C specifies the scheme-maintained registry requirements.
Annex D presents a sample supply-chain provenance domain profile.
Annex E demonstrates a concrete reference technology instantiation.
Annex F describes cross-technology interoperability between heterogeneous deployments.
Annex G describes composition with W3C Verifiable Credentials.
Annex H describes composition with the EU Digital Product Passport.
1 Scope
This document specifies a trust infrastructure for the issuance and verification of trusted artifacts — verifiable signed data objects whose trustworthiness is established by the convergence of multiple independent trust dimensions, each backed by its own trust tree.
This document specifies the following:
the trust model, including the delegation structure from a root trust authority through delegated trust authorities to end certificates, and the trust graph that generalizes a linear chain to a directed acyclic graph;
the scope model, including scope dimensions, monotonic narrowing, executable scope conditions, and the four-layer enforcement of scope at every chain link;
the artifact format and signature binding requirements, including the co-signature model for multi-party attestation, cross-domain trust fusion, and multi-dimensional reality attestation;
the threshold signing model, requiring threshold quorum at every trust authority level and specifying the ceremony protocol;
the federated trust authority model, in which threshold groups of independent organizations share an aggregate key;
the transparency model, including append-only Merkle logs, inclusion proofs, consistency proofs, mirrors, gossip, and multi-log attestation;
the revocation model, including certificate revocation lists and propagation of revocation to artifacts transitively bound to a revoked state;
the verification pipeline, including trust graph path-finding, coverage report production, classification policy, acceptance policy, and time freshness enforcement;
the algorithm agility model, including the algorithm identifier registry, deprecation process, and migration governance;
the trust topology profiles: hierarchical, federated, cross-recognized, and mesh;
the key lifecycle, including generation, storage, rotation, and ceremony requirements;
the delivery and discovery mechanisms, including chain resolution, trust anchor bundles, machine-readable passports, and challenge-response;
the conformance class hierarchy and the abstract test suite.
The following are out of scope of this document:
implementation details for the realization of any SIGNATIF component;
domain-specific content, schemas, or data models that a particular adopter community may define as profiles of this document;
the internal design of hardware security modules, secure enclaves, or other key protection mechanisms, except where they interact with the ceremony protocol;
the governance procedures of any specific root trust authority, except for the structural requirements on all root trust authorities, which are specified in the governance clause;
network transport protocols for artifact delivery, except for the requirements on chain resolution and discovery;
legal or regulatory recognition of SIGNATIF-based artifacts in any jurisdiction.
2 Terms, definitions and abbreviated terms
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
ISO Online browsing platform: available at https://www.iso.org/obp
IEC Electropedia: available at https://www.electropedia.org
General
For the purposes of this document, the following terms and definitions apply.
Terms are listed in concept order within sub-clause groupings, not in alphabetical order. Cross-references to related terms use the {{term}} syntax.
ISO Online browsing platform: www.iso.org/obp
IEC Electropedia: www.electropedia.org
Note 1 to entry: Consistent with IETF RFC 4949, “trust” in compound terms (trust authority, trust anchor, trust chain) follows established security terminology. The subjective act of trusting — a relying party’s decision to depend on an artifact — corresponds to the verifier’s acceptance policy (see 13.6). This document specifies the infrastructure that produces verifiable trustworthiness evidence (coverage report) from which that trust decision is made.
Note 2 to entry: ISO and IEC maintain terminology databases for use in standardization at the following addresses:
2.2 Trust authorities
trust infrastructure
shared set of trust anchors, transparency logs, and registries that multiple applications rely on when verifying artifacts
trust authority
entity that holds signing authority within a trust graph (2.3.2) under an scope (2.4.1), and is represented by an aggregate key (2.2.6)
Note 1 to entry: A trust authority may operate as a single-key entity, a threshold group, or a federation of independent organizations.
root trust authority
RTA
trust authority (2.2.2) that serves as the root of a delegation hierarchy and defines the initial scope (2.4.1) under which all subordinate authorities operate
Note 1 to entry: A root trust authority may be a single entity, a threshold group, or a federated trust authority.
delegated trust authority
DTA
trust authority (2.2.2) that has received signing authority through delegation from a parent trust authority and whose scope (2.4.1) is a subset of the parent’s scope on every scope dimension (2.4.2)
Note 1 to entry: A delegated trust authority may itself delegate to subordinate delegated trust authorities, forming a chain of zero or more levels.
federated trust authority
FTA
delegated trust authority (2.2.4) whose members are independent organizations that cooperate under a threshold scheme to produce a single aggregate key (2.2.6)
Note 1 to entry: No single member organization controls a federated trust authority. The threshold ensures that a specified number of members must cooperate to exercise the authority’s signing power.
aggregate key
public key that represents a trust authority (2.2.2), produced either from a single signing key or composed from multiple keys under a threshold scheme
quorum
pair of parameters (T, N) specifying the number of members of a threshold group that are needed to produce a valid threshold signing (2.5.1) signature
2.3 Trust chains and graphs
trust chain
ordered sequence of delegations from a root trust authority (2.2.3) through one or more delegated trust authorities (2.2.4) to an end certificate (2.3.3)
trust graph
trust DAG
directed acyclic graph of all trust authorities (2.2.2) and their delegation relationships, generalizing the linear trust chain (2.3.1) to admit multiple paths, cross-hierarchy edges, and federated trust authorities (2.2.5)
Note 1 to entry: The trust graph arises from threshold memberships, federated authorities spanning hierarchies, cross-domain co-signatures, and mutual recognition links.
end certificate
credential that authorizes a specific signing key to produce trusted artifacts (2.3.4) and that carries the narrowest scope (2.4.1) in its trust chain (2.3.1)
Note 1 to entry: An end certificate does not delegate authority further; it binds a key to the authority to sign artifacts within its scope.
trusted artifact
signed data object produced under the authorization of an end certificate (2.3.3), carrying one or more co-signatures (2.5.3) from one or more trust dimensions (2.7.1)
Note 1 to entry: The trusted artifact is the deliverable of this document’s framework. All elements above it in the trust graph (2.3.2) exist to establish its trustworthiness.
canonical payload
deterministic byte-string representation of the artifact data that all co-signatures (2.5.3) attest
Note 1 to entry: Canonicalization ensures that every signer attests the same bytes, regardless of serialization format. Profiles of this document specify the canonicalization algorithm for each supported format.
2.4 Authorization scope
authorization scope
scope
multi-dimensional authorization boundary that defines the extent of a trust authority (2.2.2)‘s signing power, carried as a signed field in every certificate and cryptographically enforced at every delegation link
Note 1 to entry: Authorization scope is the foundational concept of the SIGNATIF trust model: an entity is not trusted in the abstract, but only within its authorization scope. The scope constrains the class of trusted artifacts (2.3.4) that the authority’s keys are authorized to sign.
authorization scope dimension
scope dimension
one axis of an authorization scope (2.4.1), along which the scope is constrained independently of other dimensions
Note 1 to entry: Authorization scope dimensions include, non-exhaustively: domain (field of application), subdomain, class, instance, and identity. A dimension may carry the wildcard value, indicating no constraint on that axis.
authorization scope narrowing
scope narrowing
act of constraining one or more scope dimensions (2.4.2) when delegating from a parent trust authority (2.2.2) to a child, such that the child’s authorization scope (2.4.1) is a subset of the parent’s scope on every dimension
authorization scope condition
scope condition
executable predicate included in an authorization scope (2.4.1), evaluated at verification time against the content and context of a trusted artifact (2.3.4)
Note 1 to entry: An authorization scope condition may assert, for example, that a measured value falls within a tolerance, that a certification is valid at the signature time, or that a compliance status holds. An artifact signed by a key whose scope conditions are not met fails verification.
monotonic narrowing invariant
property of a delegation chain whereby the child authorization scope (2.4.1) is a subset of (or equal to) the parent scope on every scope dimension (2.4.2) at every delegation link
Note 1 to entry: Widening any dimension at any delegation link constitutes a hard verification failure.
2.5 Signing
threshold signing
cryptographic protocol in which at least T of N designated key holders cooperate to produce a single aggregate signature under the group’s aggregate key (2.2.6), without any individual holder possessing the full signing capability
ceremony
signing ceremony
protocol by which a quorum (2.2.7) of key holders cooperates to produce a threshold signing (2.5.1) signature, including the procedural, logistical, and cryptographic steps
Note 1 to entry: A ceremony record is a verifiable transcript of the ceremony (see Clause 16).
co-signature
signature on the same canonical payload (2.3.5) of a trusted artifact (2.3.4), produced by a signer from an independent trust dimension (2.7.1) or an independent trust chain (2.3.1)
Note 1 to entry: Co-signatures are distinguished from a composite signature in that each co-signature attests the payload independently, whereas a composite signature combines two algorithms into a single signature.
composite signature
single signature produced by the AND-composition of two or more signature algorithms over the same canonical payload (2.3.5)
Note 1 to entry: Composite signatures provide transition security during post-quantum migration (see Clause 19).
2.6 Trust lifecycle
trust repudiation
repudiation
formal revocation of previously-granted trust, executed by authorized parties through threshold-gated revocation mechanisms, in response to key compromise, scope violation, or fraud
Note 1 to entry: Trust repudiation is a defining property of the SIGNATIF framework. Trust is treated as a lifecycle with a defined termination, not as a permanent state. This contrasts with traditional PKI, which assumes trust persists once granted. Repudiation propagates to all trusted artifacts (2.3.4) transitively bound to the revoked state (see 11.5 and 11.6).
2.7 Trust dimensions
trust dimension
independently verifiable aspect of reality attested by a co-signature (2.5.3) on a trusted artifact (2.3.4)
Note 1 to entry: Trust dimensions include, non-exhaustively: data (the primary signature), person (operator attestation), time, location, environment, authorization, identity, and oracle. Each dimension is backed by its own trust tree.
dimension attestation
co-signature (2.5.3) tagged with a trust dimension (2.7.1) type, attesting the canonical payload (2.3.5) from the perspective of that dimension
dimension convergence
property of a trusted artifact (2.3.4) on which multiple trust dimensions (2.7.1) have attested, each independently verifiable
Note 1 to entry: Dimension convergence is the mechanism by which the artifact becomes a convergence point of independent attestations rather than a single-authority assertion.
time key
signing key representing a time authority, used to produce a dimension attestation (2.7.2) of type time
2.8 Verification
trust anchor
root anchor
public key of a root trust authority (2.2.3) that a verifier accepts as the starting point for verification paths in the trust graph (2.3.2)
Note 1 to entry: A trust anchor is configured out-of-band in the trust anchor bundle (2.8.2). Consistent with IETF RFC 4949, a trust anchor is trusted because it is directly provisioned, not because it is cryptographically proven.
trust anchor bundle
self-contained set of trust anchors (2.8.1) (root aggregate keys (2.2.6) or their fingerprints) sufficient for offline verification of any trusted artifact (2.3.4) within the bundle’s recognized scope
Note 1 to entry: A trust anchor bundle is the starting point for all verification paths in the trust graph (2.3.2).
verification pipeline
ordered sequence of checks applied to a trusted artifact (2.3.4), including signature validation, trust chain (2.3.1) or trust graph (2.3.2) path-finding, scope (2.4.1) enforcement, transparency log (2.9.1) inclusion proof, revocation status, coverage report production, and classification policy application
scheme
organization that instantiates this framework for a domain by maintaining its registries, defining scope dimensions and classification policies, and publishing a deployment manifest
Note 1 to entry: The scheme is the registration authority for the registries of Annex C.
classification label
grade label
scheme-defined label assigned to a trusted artifact (2.3.4) by applying the classification policy to the coverage report, reflecting the artifact’s dimensional coverage (2.8.6), scope (2.4.1) validity, transparency inclusion, and revocation status
Note 1 to entry: The classification label enables risk-based verification policy: a verifier may accept a lower label for low-stakes artifacts while requiring a higher label for high-stakes ones.
dimensional coverage
set of verified trust dimensions (2.7.1) attested on a trusted artifact (2.3.4), recorded in the coverage report as input to the classification policy
inclusion proof
cryptographic proof (typically a Merkle audit path) that a trusted artifact (2.3.4) or its end certificate (2.3.3) is included in a transparency log (2.9.1)
2.9 Transparency
transparency log
append-only, cryptographically verifiable log (typically a Merkle tree) that records all issued end certificates (2.3.3) and trusted artifacts (2.3.4) for public audit
mirror
log mirror
independent operator that replicates a transparency log (2.9.1) and serves inclusion proofs and log entries to verifiers
Note 1 to entry: Mirrors detect log misbehaviour through gossip (2.9.3) with other mirrors and with the primary log operator.
gossip
protocol by which independent mirrors (2.9.2) and verifiers cross-check their views of a transparency log (2.9.1) by comparing fingerprints of log state
multi-log attestation
attestation model in which a trusted artifact (2.3.4) or end certificate (2.3.3) is included in at least M of K independent transparency logs (2.9.1), where M and K are specified by the issuing authority’s policy
2.10 Machine-readable projection
passport
machine-readable public projection of an end certificate (2.3.3) or trusted artifact (2.3.4), optimized for compact storage and rapid presentation (for example, via a two-dimensional barcode)
Note 1 to entry: A passport is a presentation format, not a separate trust object. The underlying certificate or artifact remains the authoritative source.
2.11 Abbreviated terms
The abbreviated terms are given in Table 2. Where an abbreviation is a defined term of a published standard, the meaning follows that standard.
| Abbreviation | Meaning |
|---|---|
| SIGNATIF | Sealed Interoperable Graduated Non-repudiable Anchored Trust Infrastructure Framework |
| CA | certification authority (ISO/IEC 9594-8) |
| CBOR | Concise Binary Object Representation (RFC 8949) |
| COSE | CBOR Object Signing and Encryption |
| CRL | certificate revocation list |
| CSR | certification request (PKCS #10) |
| CT | certificate transparency |
| DAG | directed acyclic graph |
| DPP | digital product passport |
| DTA | delegated trust authority |
| ETSI | European Telecommunications Standards Institute |
| FTA | federated trust authority |
| JCS | JSON Canonicalization Scheme (RFC 8785) |
| JSON | JavaScript Object Notation (ISO/IEC 21778) |
| JWS | JSON Web Signature |
| ML-DSA | Module-Lattice-Based Digital Signature Algorithm |
| MTI | mandatory to implement |
| OCSP | online certificate status protocol (ISO/IEC 27099) |
| OIML | International Organization of Legal Metrology |
| PKCS | Public-Key Cryptography Standards |
| PKI | public key infrastructure |
| PQ | post-quantum |
| RTA | root trust authority |
| SLH-DSA | Stateless Hash-Based Digital Signature Algorithm |
| SPKI | subject public key info |
| TLS | transport layer security |
| URI | uniform resource identifier (ISO 5127) |
| VC | verifiable credential |
| XMLDSig | XML Signature |
3 Conventions and notation
3.1 Requirements language
The verbal forms used in this document conform to the ISO/IEC Directives, Part 2. In particular:
“shall” indicates a requirement strictly to be followed in order to conform to the document;
“should” indicates that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others;
“may” indicates a permissible course of action within the limits of the document;
“can” indicates a possibility and capability that can be known to the user.
3.2 Notation
The following notation is used throughout this document. The notation is summarized in Table 3.
| Notation | Meaning |
|---|---|
| (T, N) | Quorum: at least T of N members shall cooperate |
3.3 Identifier conventions
Requirements in this document are identified by the path /req/<class>/<fragment>. Conformance tests are identified by the path /conf/<class>/<fragment> and target the corresponding requirement.
Cross-references to terms use the {{term}} syntax. Cross-references to clauses use the
4 Principles
4.1 General
The requirements of this document are derived from a set of design principles. Each principle distinguishes the trust infrastructure specified here from traditional public key infrastructure (PKI) patterns that were designed for server-identity authentication and are structurally inadequate for establishing the trustworthiness of persistent artifacts.
NOTE 1 This clause is motivational. The binding normative requirements derived from these principles are specified in clauses 6 through 19. In case of any apparent conflict, the normative clauses take precedence.
The name SIGNATIF encodes eight architectural properties. These properties are not merely descriptive — each maps to normative requirements in this document. Table 4 lists the eight properties by letter.
| Letter | Property | Architectural meaning |
|---|---|---|
| S | Sealed | Every trusted artifact is cryptographically sealed: independent co-signatures cover the same canonical payload, one per trust dimension (data, person, time, location, environment, and others defined by the scheme). Convergence of independent attestations, not single-signer authority, establishes trustworthiness. See 7.9. |
| I | Interoperable | The framework is scheme-independent. One verification pipeline and one coverage-report format serve many application schemes; scheme-specific rules enter through published registries and deployment profiles rather than forked technology. See Clause 5. |
| G | Graduated | Trustworthiness is graduated, not binary. The verifier produces an objective coverage report of hard and soft check results; the scheme’s classification policy maps it to a classification label; the verifier’s acceptance policy turns the label into a decision. See 13.5. |
| N | Non-repudiable | Issuance is attributable and undeniable. Authority is exercised by threshold quorum and by federated trust authorities spanning organizational boundaries — never by an unaccountable single key — and inclusion in publicly auditable transparency logs provides third-party evidence of what was issued. After the fact, no participant can credibly deny an attestation made in its name. See Clause 9 and Clause 12. |
| A | Anchored | Signing authority flows through a delegation hierarchy — root trust authority through delegated trust authorities to end certificate to trusted artifact — with the scope narrowing monotonically at every link, and every verification path terminating at a root anchor in the trust anchor bundle. Verification requires no phone-home to the issuer and no proprietary component. See 6.2, 10.3, and 6.5. |
| T | Trust | The domain of this document is trust: the establishment, assessment, and withdrawal of confidence in signed artifacts. Trust is graduated — the verifier maps an objective coverage report to a classification label — and it is a lifecycle: granted authority can be withdrawn through threshold-gated revocation that propagates to every transitively bound artifact. See 13.5 and 11.5. |
| I, F | Infrastructure, Framework | SIGNATIF operates at the infrastructure level — shared anchors, logs, and registries independent of any single application — and is a framework, not a product or protocol: it defines requirements that independent implementations conform to, and that domain-specific profiles instantiate. See Clause 5. |
The principles are grouped thematically below. Each principle appears in at least one requirements class defined in Clause 5.
NOTE 2 These principles distinguish SIGNATIF from traditional PKI patterns optimized for server-identity authentication. They address the persistent- artifact trust problem specifically; they are not criticisms of PKI, which remains the appropriate and mature technology for TLS, code signing under active policy enforcement, and identity binding. See Annex B for use-case suitability guidance.
4.2 Authority and delegation
4.2.1 Cryptographic scope enforcement
The scope of a trust authority is a first-class signed field, cryptographically enforced at every chain link. Widening any scope dimension at any delegation point causes a hard verification failure. This contrasts with traditional PKI, in which a CA’s scope is defined by external policy (Baseline Requirements) and is not verifiable from the certificate itself.
4.2.2 Threshold at every level
A quorum of cooperating key holders is needed to exercise the signing authority of any trust authority, including but not limited to the root trust authority. There is no single point of cryptographic compromise at any level of the trust graph.
4.2.3 Federated trust authorities
A federated trust authority is a threshold group of independent organizations sharing a single aggregate key, such that no single organization controls the authority. This contrasts with traditional PKI bridge CAs, which are single entities.
4.2.4 Topology flexibility
The trust graph admits hierarchical, federated, cross-recognized, and mesh topologies as first-class conformance profiles. No implementation is required to assume a single-root hierarchy.
4.3 Multi-party and multi-dimensional attestation
4.3.1 Multi-party co-signed artifacts
A trusted artifact carries one or more co-signatures, each from a different signer, attesting the same canonical payload. The artifact is a convergence point of independent attestations rather than a single-authority assertion.
4.3.2 Multi-dimensional reality attestation
Time, location, and environment are cryptographic trust dimensions, each backed by its own trust tree and each producing its own dimension attestation. These dimensions are not carried as unsigned metadata.
4.3.3 Cross-domain trust fusion
co-signatures from independent trust chains or independent root trust authorities are carried on the same trusted artifact. Cross-domain trust recognition occurs at the artifact level, not solely at the trust authority level.
4.4 Scope and binding
4.4.1 Live scope conditions
A scope includes scope conditions — executable predicates evaluated at verification time against the content and context of the artifact. An artifact signed by a key whose scope conditions are not met fails verification, regardless of cryptographic signature validity.
4.4.2 Revocation propagation
Revocation of a trust authority state propagates to every trusted artifact transitively bound to that state, across all trust dimensions and all trust chains. A revoked authority’s prior signatures do not remain valid.
4.4.3 Challenge-response authenticity
A verifier is able to challenge a device for a fresh trusted artifact bound to a nonce, such that a static copy of a prior artifact cannot satisfy the challenge. Authenticity is established by the ability to produce a timely, nonce-bound response, not by possession of a static credential.
4.5 Transparency and time
4.5.1 Mandatory transparency
Inclusion of every end certificate and every trusted artifact in a transparency log is a verification requirement. Artifacts not provably included in a recognized log are downgraded or rejected.
4.5.2 Multi-log attestation
A federated trust authority requires inclusion of its artifacts in at least M of K independent transparency logs, such that no single log operator controls the record.
4.5.3 External time anchoring
The time of signing is established by an independent time key or by anchoring to an external, irrefutable time source. The signer’s self-asserted timestamp is not the sole evidence of when an artifact was signed.
4.6 Trust assessment
4.6.1 Graduated trust
The classification label of a trusted artifact reflects the depth and breadth of its dimensional coverage, not merely the binary validity of its primary signature. A verifier is able to apply risk-based policy to the classification label.
5 Conformance
5.1 General
This document defines requirements for multiple roles within the trust infrastructure: verifiers, issuing authorities, root authorities, transparency operators, and device signers. Requirements are grouped into requirements classes, each addressing a specific capability.
A conforming implementation may claim conformance to one or more requirements classes, depending on the role it performs. Requirements classes are designed to be modular: an implementation that serves only as an offline verifier need not implement the ceremony or key-lifecycle requirements.
Requirements in this document are capability-based: they specify what an implementation shall be able to do, without mandating a specific implementation technology or internal architecture.
5.2 Mandatory-to-implement baseline
To ensure interoperability between independently developed implementations, the following mandatory-to-implement (MTI) baseline applies. An implementation claiming a conformance class shall implement at least the MTI components for that class. The baseline specifies algorithm classes, not specific algorithms, to accommodate deployments with different regulatory or national algorithm requirements (e.g., SM2/SM3 in China, FIPS-approved algorithms in the United States). Table 5 defines the mandatory-to-implement baseline by conformance class.
| Conformance class | Mandatory-to-implement |
|---|---|
| /conf/basic-verifier | At least one classical signature algorithm from the scheme’s algorithm registry, at least one format profile, embedded chain discovery, trust anchor bundle loading |
| /conf/full-verifier | All basic-verifier MTI, plus at least one post-quantum or composite algorithm from the registry, transparency inclusion proof verification, CRL processing, coverage report and classification |
| /conf/issuing-authority | All full-verifier MTI, plus threshold signing ceremony protocol, key generation for at least one registered algorithm, ceremony record production |
| /conf/root-authority | All issuing-authority MTI, plus deployment manifest generation, governance record publication |
| /conf/transparency-operator | Append-only transparency log operation, tree head signing, external time anchoring |
| /conf/mirror | Log replication, gossip protocol, inclusion proof serving |
| /conf/device-signer | At least one classical signature algorithm from the registry, at least one format profile, per-device key lifecycle, challenge-response capability |
Two independently developed implementations claiming /conf/basic-verifier interoperate if they share at least one common classical algorithm and one common format profile. Implementations targeting a specific deployment context (e.g., a national regulatory regime) shall document which algorithm(s) and format profile(s) they implement.
A claim of conformance to a requirements class shall be supported by passing the conformance tests defined in the corresponding conformance class in Annex A.
5.3 Core conformance classes
The following core requirements classes address the primary roles in the trust infrastructure. Dependencies between classes are acyclic. Table 6 lists the core requirements classes.
| Requirements class | Conformance class | Capabilities | Depends on |
|---|---|---|---|
| /req/basic-verifier | /conf/basic-verifier | Artifact format, signature validation, trust-chain path-finding | — |
| /req/full-verifier | /conf/full-verifier | All basic-verifier capabilities, plus scope enforcement, revocation, time attestation, transparency inclusion, coverage report and classification | /req/basic-verifier |
| /req/issuing-authority | /conf/issuing-authority | Threshold signing, ceremony protocol, key lifecycle, end certificate issuance | /req/full-verifier |
| /req/root-authority | /conf/root-authority | Governance, deployment manifest, scope definition, delegation to DTAs | /req/issuing-authority |
| /req/transparency-operator | /conf/transparency-operator | Transparency log operation, inclusion proof issuance, multi-log coordination | — |
| /req/mirror | /conf/mirror | Transparency log mirroring, gossip, inclusion proof serving | — |
| /req/device-signer | /conf/device-signer | Artifact format, per-device key lifecycle, challenge-response | /req/basic-verifier |
NOTE Figure 1 provides a diagram of the requirements class dependencies. | |||
5.4 Trust topology profiles
A trust infrastructure deployment shall conform to at least one topology profile. A deployment may conform to more than one. Table 7 lists the topology profiles.
| Profile | Structure | Notes |
|---|---|---|
| /conf/hierarchical | Strict tree; one root; linear chains from root to end certificate | Simplest profile; single-root anchor bundle |
| /conf/federated | Multiple independent roots; multi-root anchor bundle; FTAs may span roots | No single root controls all paths |
| /conf/cross-recognized | Hierarchical deployment with explicit cross-recognition links between roots | Bilateral or multilateral root-level agreements |
| /conf/mesh | General DAG; hierarchy-spanning FTAs; arbitrary cross-domain co-signatures | Most general topology; highest verification complexity |
5.5 Dimension profiles
A trusted artifact may carry dimension attestations from one or more trust dimensions. Trust dimensions are extensible: the set of possible dimensions is not fixed. The following profiles are initially defined; additional dimension profiles may be registered per Annex C and claimed by implementations. Table 8 lists the initially defined dimension profiles.
| Profile | Dimension | Description |
|---|---|---|
| /conf/dimension-data | Data | Primary signature attesting the canonical payload |
| /conf/dimension-person | Person | Operator co-signature binding a human accountable party to the artifact |
| /conf/dimension-time | Time | Time authority co-signature establishing signing time independently |
| /conf/dimension-location | Location | Location authority co-signature (e.g. GNSS-based) attesting provenance location |
| /conf/dimension-environment | Environment | Sensor co-signature attesting ambient conditions at signing time |
| /conf/dimension-authorization | Authorization | Regulatory or policy authority co-signature attesting that the signing act was permitted |
| /conf/dimension-identity | Identity | Manufacturer or identity authority co-signature attesting device or entity genuineness |
| /conf/dimension-oracle | Oracle | External data feed co-signature attesting the value of an external datum at a stated time |
| /conf/multi-dimensional | Three or more | Convergence of three or more independent trust dimensions on a single artifact |
NOTE The /conf/multi-dimensional profile requires at least three independent dimension attestations from different trust dimensions. | ||
5.6 Format profiles
This document is format-agnostic: the canonical payload and signature binding requirements are specified independently of serialization. Format profiles follow the pattern /conf/format-<name>, where <name> identifies a specific format registered in the scheme’s format profile registry. The following are examples of format profiles; schemes may register additional profiles. Table 9 gives examples of format profiles.
| Profile | Format | Reference |
|---|---|---|
| /conf/format-xmldsig | W3C XML Signature with Exclusive XML Canonicalization | W3C Recommendation: XML Signature Syntax and Processing Version 2.0, W3C Recommendation: Exclusive XML Canonicalization Version 1.0 |
| /conf/format-jws | JSON Web Signature (compact or JSON serialization) | IETF RFC 7515 |
| /conf/format-cose | CBOR Object Signing and Encryption (Sig_Structure) | IETF RFC 8152 |
An implementation claiming conformance to a format profile shall satisfy the format-agnostic binding requirements in Clause 7 in addition to the profile-specific format requirements.
5.7 Requirements classes overview
The detailed requirements and conformance tests for each requirements class are specified in the relevant subject-matter clauses and rendered from structured data:
Clause 6: /req/architecture/*
Clause 7: /req/artifact-format/*
Clause 8: /req/algorithms/*
Clause 9: /req/threshold-signing/*
Clause 10: /req/scope/*
Clause 11: /req/revocation/*
Clause 12: /req/transparency/*
Clause 13: /req/verification/*
Clause 14: /req/key-lifecycle/*
Clause 15: /req/delivery/*
Clause 16: /req/ceremony/*
Clause 17: /req/manifest/*
Clause 18: /req/governance/*
Clause 19: /req/algorithm-agility/*
The full set of conformance tests is rendered in Annex A.
6 Architecture and trust model
6.1 General
A trust infrastructure that conforms to the SIGNATIF framework as described in this document aims to provide verifiable artifacts whose trustworthiness is established by the convergence of multiple independent trust dimensions, each backed by its own trust tree.
The architecture consists of four main areas of concern:
Trust authorities: the entities that hold signing authority and their delegation relationships (6.2);
The trust graph: the directed acyclic graph that generalizes the linear chain to admit multiple paths, federations, and cross-domain links (6.3);
Chain discovery: the mechanisms by which a verifier resolves the path from an artifact to a root anchor (6.4);
The trust anchor bundle: the self-contained set of root anchors that enables offline verification (6.5).
6.3 Trust graph
6.3.1 From chain to graph
Traditional PKI models trust as a linear chain: root, intermediate CA, leaf certificate. The SIGNATIF framework generalizes this to a trust graph — a directed acyclic graph (DAG) in which multiple valid paths may exist between an artifact and a root anchor (Figure 2).
The trust graph arises from four structural features:
Threshold memberships. A single delegated trust authority can be reached through multiple member key paths.
Federated trust authorities. A federated trust authority spans multiple independent organizations, creating cross-organization edges.
Cross-domain co-signatures. A trusted artifact can carry co-signatures from different trust chains, creating horizontal edges at the artifact level.
Mutual recognition. Two root trust authorities may mutually recognize each other, creating root-level edges.
6.3.2 Path-finding
The verifier’s task in the SIGNATIF framework is not to walk a single chain but to find paths in the trust graph from the artifact to any anchor in the trust anchor bundle. Multiple valid paths may exist; the coverage report records all valid paths, and the classification policy may require paths through multiple independent roots for higher classification labels.
The path-finding algorithm is implementation-neutral. This document specifies the requirements that any conforming path-finder shall satisfy (see 6.7), including:
monotonic scope narrowing at every link;
cryptographic signature validation at every link;
transparency log inclusion for every delegation certificate and end certificate on the path;
revocation status checking for every authority on the path.
6.4 Chain discovery
6.4.1 General
A verifier shall be able to reconstruct the full delegation chain from an artifact to a root anchor. Discovery strategies are recognized; additional strategies may be registered; an implementation may support one or more.
6.4.2 Embedded chain
The artifact carries the full delegation chain inline. The root is resolved from the trust anchor bundle by fingerprint. This strategy is fully offline-capable but produces larger payloads.
6.4.3 Transparency-log references
Each certificate carries a delegatedBy reference (a transparency-log sequence number or equivalent pointer). The verifier fetches and caches the referenced certificates on first encounter. This strategy produces compact payloads but requires network access on first encounter.
6.4.4 Hybrid (reference design)
The artifact embeds the end certificate and the immediate delegation chain, resolves the root from the anchor bundle, and includes transparency-log sequence numbers for freshness and audit. This is the recommended strategy for production deployments.
6.5 Trust anchor bundle
A trust anchor bundle is a self-contained set of root trust authority anchors — root aggregate keys or their fingerprints — together with the metadata needed to identify and validate them. The trust anchor bundle is the starting point for all verification paths.
A trust anchor bundle shall be:
Self-contained. A verifier holding the bundle and the artifact shall require no additional network access to complete verification (for embedded or hybrid chain strategies).
Versioned. Each bundle carries a version identifier and a validity period. Bundle updates are themselves transparently logged.
Distributable. The bundle shall be expressible in a deterministic format suitable for out-of-band distribution (e.g., via physical media, secure channel, or published fingerprint).
6.6 Generalization from domain-specific hierarchies
The delegation model is domain-agnostic. Domain-specific hierarchies map onto it by identifying their tiers with the appropriate trust authority level.
EXAMPLE A pharmaceutical supply-chain deployment maps its tiers as follows: a global regulatory body maps to the root trust authority; national drug agencies map to delegated trust authorities at successive scope narrowings; manufacturer quality-assurance authorities map to delegated trust authorities with production-line scope; per-batch signing keys map to end certificates; and signed batch release records map to trusted artifacts.
Other domains — pharmaceutical supply chains, academic credentials, environmental monitoring — may define their own tier mappings. The requirements of this document apply uniformly regardless of the domain.
6.7 Requirements
Architecture and trust model has its formalized requirements class described in Table 11, Requirements class 1, with its requirements listed from Table 12, Requirement 1 to Table 22, Requirement 11.
| Identifier | /req/architecture/four-level-model |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | The trust infrastructure shall implement a delegation model in which signing authority flows from a root trust authority, through zero or more delegated trust authorities, to an end certificate that authorizes a key to produce trusted artifacts. |
| Guidance | The four levels are root trust authority, delegated trust authority, end certificate, and trusted artifact. A delegation chain may pass through zero or more delegated trust authorities. |
| Identifier | /req/architecture/delegation-certificate |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | A delegation from a parent trust authority to a child shall be expressed as a signed credential that binds the child’s aggregate key, the quorum parameters if the child is threshold, the narrowed scope, and a reference to the ceremony protocol if applicable. |
| Guidance | The delegation certificate is itself a verifiable artifact subject to chain verification, scope enforcement, and transparency inclusion. If the child is a single-key authority (1-of-1), the quorum parameters are omitted. |
| Identifier | /req/architecture/delegation-scope-narrowing |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | Every delegation shall narrow the scope such that the child’s scope is a subset of the parent’s scope on every scope dimension, in accordance with the monotonic narrowing invariant. |
| Guidance | Widening any scope dimension at any delegation link constitutes a verification failure. Detailed scope requirements are specified in /req/scope/. |
| Identifier | /req/architecture/end-certificate-contents |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | An end certificate shall carry the authorized public key or its fingerprint, the scope under which the key is authorized to sign, any scope conditions, and a reference to the issuing trust authority’s delegation chain. |
| Guidance | An end certificate shall not delegate authority further. Scope conditions are executable predicates evaluated at verification time. |
| Identifier | /req/architecture/trust-graph-pathfinding |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | A verifier shall be able to find one or more paths in the trust graph from a trusted artifact to a root anchor in the trust anchor bundle, validating the cryptographic signature and the scope narrowing at every link on each path. |
| Guidance | Multiple valid paths may exist. The coverage report records all valid paths and the classification policy determines the label from the convergence pattern. The path-finding algorithm is implementation-neutral. |
| Identifier | /req/architecture/path-transparency-inclusion |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | For every delegation certificate and end certificate on a verification path, the verifier shall confirm inclusion in a recognized transparency log. |
| Guidance | Artifacts or certificates not provably included in a recognized log shall be downgraded or rejected. Detailed transparency requirements are specified in /req/transparency/. |
| Identifier | /req/architecture/path-revocation-checking |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | For every trust authority on a verification path, the verifier shall determine the revocation status and propagate any revocation to artifacts transitively bound to that authority. |
| Guidance | Detailed revocation requirements are specified in /req/revocation/. |
| Identifier | /req/architecture/chain-discovery |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | A verifier shall support at least one chain discovery strategy — embedded chain, transparency-log references, or hybrid — sufficient to reconstruct the full delegation chain from artifact to root anchor. |
| Guidance | The embedded chain strategy carries the full chain inline and is fully offline-capable. The transparency-log reference strategy uses sequence number pointers and requires network access on first encounter. The hybrid strategy embeds the immediate chain and includes transparency-log references for freshness. |
| Identifier | /req/architecture/anchor-bundle-self-contained |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | A trust anchor bundle shall contain the root aggregate keys or their fingerprints and the metadata needed to identify and validate them, such that a verifier holding the bundle and an artifact with an embedded or hybrid chain requires no additional network access to complete verification. |
| Guidance | The bundle is the starting point for all verification paths. |
| Identifier | /req/architecture/anchor-bundle-versioning |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | A trust anchor bundle shall carry a version identifier and a validity period, and bundle updates shall be recorded in a transparency log. |
| Guidance | Bundle versioning enables verifiers to determine whether they hold a current or stale anchor set. |
| Identifier | /req/architecture/anchor-bundle-distributable |
|---|---|
| Included in | Requirements class 1: Architecture and trust model (/req/architecture) |
| Statement | A trust anchor bundle shall be expressible in a deterministic format suitable for out-of-band distribution. |
| Guidance | Examples of out-of-band distribution include physical media, secure channels, and published fingerprints verified against multiple independent sources. |
7 Artifact format and signature binding
7.1 General
A trusted artifact is the deliverable of the SIGNATIF framework. It is a signed data object carrying one or more signatures over a deterministic canonical representation of its payload. This clause specifies the format-agnostic binding requirements that all conforming artifact formats shall satisfy, the recognized format profiles, and the models for co-signatures, cross-domain trust fusion, and multi-dimensional attestation.
This document is format-agnostic: the binding requirements are specified independently of serialization. Specific signature envelope formats (e.g., XMLDSig, JWS, COSE) are defined as conformance profiles in 7.4; the COSE profile encodes artifacts as CBOR (IETF RFC 8949).
7.2 Signature binding requirements
Any conforming signature wrapper shall guarantee the following five binding properties:
Canonical representation binding. The signature shall bind to a deterministic canonical payload — a byte-string representation of the payload data such that the same logical content always produces the same bytes, regardless of serialization format or encoding.
Algorithm identification. The wrapper shall explicitly identify the signing algorithm and its parameters, such that the verifier knows unambiguously how to validate the signature.
Signer identification. The wrapper shall reference or embed the signer’s public key or end certificate, enabling the verifier to locate the key and its delegation chain.
Chain availability. The wrapper shall carry or reference the full chain from the signer to a root anchor, in accordance with at least one chain discovery strategy (see 6.4).
Self-description. The wrapper shall be self-describing: a verifier shall be able to determine all inputs needed for validation from the wrapper and the trust anchor bundle alone, without external convention.
7.3 Canonical payload
The canonical payload is the deterministic byte-string representation of the artifact data that all signatures and co-signatures attest. Every signer — regardless of trust dimension, organization, or trust chain — attests the same canonical bytes.
A conforming canonicalization algorithm shall satisfy the following characteristics:
Determinism. The same logical content shall always produce the same canonical byte string, regardless of the serialization format, encoding, or implementation that produced it.
Recoverability. The canonical byte string shall be sufficient to reconstruct the logical content without loss.
Unambiguity. The canonicalization rules shall be fully specified, leaving no implementation-defined behavior that could cause two implementations to produce different canonical bytes for the same logical content.
Collision resistance. Two distinct logical contents shall not produce the same canonical byte string (subject to the underlying hash function’s collision resistance).
The specific canonicalization algorithm is specified by each format profile (see 7.4). An implementation claiming a format profile shall use the canonicalization algorithm specified by that profile. Canonicalization algorithms used by the initially registered profiles are listed in Table 23:
| Format profile | Canonicalization characteristics |
|---|---|
| JWS-based | Object keys in deterministic order (e.g., lexicographic), no insignificant whitespace, deterministic number representation, UTF-8 encoding |
| COSE-based | Definite-length encoding, map keys in deterministic order, integers in minimum-length encoding |
| XMLDSig-based | Canonical XML (e.g., Exclusive C14N) for the signed subtree, UTF-8 encoding |
Additional format profiles and their canonicalization algorithms may be registered in the scheme’s registry. The choice of format profile is a deployment decision; this document does not mandate a specific format.
A co-signer cannot selectively attest part of the artifact. Partial attestation is not conforming.
7.4 Format profiles
The choice of signature envelope format is a deployment decision. This document does not mandate a specific format. An implementation claiming a format profile shall satisfy the binding requirements in 7.2 in addition to the profile-specific canonicalization characteristics. The format profiles listed in Table 24 are initially registered; additional profiles may be registered per Annex C.
| Profile | Format | Reference |
|---|---|---|
| /conf/format-xmldsig | W3C XML Signature with Exclusive XML Canonicalization (Exc-C14N) | W3C Recommendation: XML Signature Syntax and Processing Version 2.0, W3C Recommendation: Exclusive XML Canonicalization Version 1.0 |
| /conf/format-jws | JSON Web Signature, compact or JSON serialization, with detached content | IETF RFC 7515 |
| /conf/format-cose | CBOR Object Signing and Encryption, Sig_Structure | IETF RFC 8152 |
The co-signature encodings for the initially registered profiles are listed in Table 25.
| Profile | Co-signature encoding |
|---|---|
| /conf/format-jws | General JSON serialization with one signature per co-signer; the dimension tag, signer identity, and chain reference are carried in the protected header, and the signing input is BASE64URL(sha256(canonical payload)) as the detached payload |
| /conf/format-cose | COSE_Sign with one signature recipient per co-signer; the dimension tag, signer identity, and chain reference are carried in the protected bucket, and the detached payload is the digest of the canonical payload |
| /conf/format-xmldsig | One ds:Signature element per co-signer over the same ds:Reference to the canonicalized payload; the dimension tag, signer identity, and chain reference are carried as signed ds:Object properties of that reference |
Future formats may be registered upon demonstration of conformance to the five binding requirements and specification of their canonicalization algorithm.
7.5 Per-domain payload schema
The payload of a trusted artifact follows a domain-specific schema. The schema is identified by a URI ($id) and is versioned. Multiple payload schemas may coexist within one SIGNATIF deployment, enabling different domains to define their own artifact content structures.
A payload schema shall be deterministic: two artifacts with the same logical content shall canonicalize to the same bytes under the schema.
7.6 Version compatibility
Artifact format versioning follows semantic compatibility rules:
Major version changes are breaking. Verifiers shall reject artifacts whose major version exceeds the verifier’s supported maximum.
Minor version changes are backward and forward compatible. Verifiers shall ignore unknown fields introduced in minor versions.
The version is carried explicitly in the wrapper, not implied by the format profile.
7.7 Co-signatures and multi-party attestation
7.7.1 General
A co-signature is an additional signature on the same canonical payload of a trusted artifact, produced by a signer from an independent role, organization, or trust dimension. Co-signatures are the mechanism by which the artifact becomes a convergence point of independent attestations rather than a single-authority assertion.
7.7.2 Co-signature block
Each co-signature block shall contain:
Signer identity. An end certificate reference or key fingerprint.
Chain reference. A reference to the signer’s root (which may differ from the primary signer’s root).
Algorithm. The signing algorithm and parameters. Each co-signer may use a different algorithm.
Dimension tag. The trust dimension type this co-signature attests (e.g., data, person, time, location, environment).
Signature. The cryptographic signature over the canonical payload.
7.7.3 Independent verification
Each co-signature shall be verified independently:
each has its own chain to its own root;
the verifier checks each signature, chain, and scope independently;
no co-signature depends on another for its cryptographic validity (policy dependencies are separate, see Clause 13).
7.7.4 Canonical payload binding
All co-signatures shall attest the same canonical payload. A co-signer cannot selectively attest part of the artifact.
7.7.5 Format profile encoding obligation
Each format profile registered in the scheme’s format profile registry shall specify how co-signature blocks, dimension tags, and chain references are encoded in that format. A format profile that does not define a co-signature encoding shall not claim conformance to the multi-dimensional attestation requirements of this document.
7.8 Cross-domain trust fusion
7.8.1 General
co-signatures on a trusted artifact may originate from independent trust chains — different roots, different governance frameworks. The artifact becomes a cross-domain trust junction: a single data object on which multiple independent governance frameworks have converged.
7.8.2 No root cross-recognition required
Cross-domain co-signing does not require the participating roots to cross-certify each other. The co-signatures themselves are the cross-domain trust recognition, established at the artifact level rather than at the CA level.
The verifier holds anchors for multiple roots in the trust anchor bundle. Cross-domain verification uses these anchors directly.
7.8.3 Trust cement properties
Once co-signatures are applied to an artifact, the following properties hold:
A co-signature cannot be stripped without breaking the artifact’s self-description.
Each co-signer committed to the exact same canonical payload and cannot deny its attestation.
The transparency log records the artifact with all co-signatures, and the record cannot be rewritten.
Each co-signature may carry its own time anchor, preventing backdating.
7.9 Multi-dimensional attestation
7.9.1 General
Each trust dimension is an independently verifiable aspect of reality, attested by its own dimension attestation (a co-signature tagged with the dimension type). Dimensions are independent: each has its own trust tree and root, and no cross-recognition between dimension roots is required (Figure 3).
Table 26 lists examples of trust dimensions and their attestation sources.
| Dimension | What it attests | External anchor (example) |
|---|---|---|
| data | The primary content (measured value, record) | Transparency log |
| person | A human witnessed or authorized the act | Hardware token |
| time | The artifact existed at a stated time | External timestamp source |
| location | The event occurred at stated coordinates | Location authority signal |
| environment | Ambient conditions were within stated bounds | Calibrated sensor |
| authorization | The action was permitted under a policy | Regulatory framework |
| identity | The device or person is genuine | Identity authority |
| oracle | External data had a stated value at a time | Multi-source agreement |
7.9.2 Convergence
All dimension attestations shall sign the same canonical payload. The artifact is the convergence point: each dimension is an independent attestation of trustworthiness, and the artifact is where they intersect. More dimensions converging on an artifact produce a more favorable classification label (see Clause 13 for the classification policy).
7.9.3 Time as a first-class dimension
The time dimension is attested by a time key — a co-signature from a time authority that records the existence of the artifact hash at a stated time and anchors that record to an external, irrefutable time source. The time dimension is objective, tamper-evident, and cross-domain: it is valid regardless of the organizational hierarchy under which the artifact was produced.
7.10 Living artifacts
A trusted artifact may accumulate dimension attestations over time. As additional dimensions converge, the artifact’s classification label may improve as additional dimensions are attested.
EXAMPLE At time T0, a device signs a data record (data dimension). At T1, an operator co-signs (person dimension). At T2, a time authority anchors the artifact (time dimension). At T3, a location authority co-signs (location dimension). Each addition increases the dimensional coverage in the coverage report, which the scheme’s classification policy may map to a more favorable classification label.
The accumulation protocol shall ensure that each added dimension attestation signs the original canonical payload, not a modified version.
7.11 Requirements
Artifact format and signature binding has its formalized requirements class described in Table 27, Requirements class 2, with its requirements listed from Table 28, Requirement 12 to Table 47, Requirement 31.
| Identifier | /req/artifact-format/canonical-binding |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A signature wrapper shall bind the signature to a deterministic canonical payload — a byte-string representation of the payload data such that the same logical content always produces the same bytes — and the signature input shall be the digest of that canonical payload, computed with the digest algorithm specified by the applicable format profile. |
| Guidance | The canonicalization and digest algorithms are specified by the applicable format profile. Signing the digest rather than the payload bytes is what lets independent co-signers over large payloads converge on the same signed input. |
| Identifier | /req/artifact-format/algorithm-identification |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A signature wrapper shall explicitly identify the signing algorithm and its parameters, such that the verifier can unambiguously determine how to validate the signature. |
| Guidance | Each co-signer may use a different algorithm. |
| Identifier | /req/artifact-format/signer-identification |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A signature wrapper shall reference or embed the signer’s public key or end certificate, enabling the verifier to locate the key and its delegation chain. In publicly presentable artifacts and passports, the signer identity of a co-signature block shall be a key fingerprint or pseudonym; named-identity binding shall be held in an access-controlled register by the responsible authority. |
| Guidance | Signer identifiers are URIs (IETF RFC 3986). See also the privacy considerations (20.10) and the log content minimization requirement of Clause 12. |
| Identifier | /req/artifact-format/chain-availability |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A signature wrapper shall carry or reference the full chain from the signer to a root anchor, in accordance with at least one chain discovery strategy. |
| Guidance | Chain discovery strategies are specified in /req/architecture/chain-discovery. |
| Identifier | /req/artifact-format/self-description |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A signature wrapper shall be self-describing, such that a verifier can determine all inputs needed for validation from the wrapper and the trust anchor bundle alone, without external convention. |
| Identifier | /req/artifact-format/canonical-determinism |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | The canonicalization of the payload shall be deterministic, such that two artifacts with the same logical content always produce the same canonical bytes. |
| Guidance | Per-domain payload schemas shall be deterministic under canonicalization. |
| Identifier | /req/artifact-format/format-profile-satisfaction |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | An implementation claiming a format profile shall satisfy the five binding requirements in addition to the profile-specific format requirements for that profile. |
| Guidance | Recognized profiles are format-xmldsig, format-jws, and format-cose. Format profiles may define payload schemas using JSON Schema (JSON Schema Specification (Draft 7)). Format profiles may define payload schemas using JSON Schema (JSON Schema Specification (Draft 7)). |
| Identifier | /req/artifact-format/version-compatibility |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | Artifact format versioning shall follow semantic compatibility rules, where major version changes are breaking and shall be rejected by verifiers whose supported maximum is exceeded; minor version changes are backward and forward compatible, with unknown fields ignored. |
| Guidance | The version is carried explicitly in the wrapper. |
| Identifier | /req/artifact-format/cosignature-block |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | Each co-signature block shall contain the signer identity, chain reference, algorithm and parameters, dimension tag, and signature over the canonical payload. |
| Guidance | The dimension tag identifies the trust dimension this co-signature attests. Schemes whose attesting subjects are individuals should use rotating or purpose-bound operator keys, or privacy-preserving credentials, to limit cross-artifact linkability. |
| Identifier | /req/artifact-format/cosignature-independent-verification |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | Each co-signature shall be verifiable independently, with its own chain to its own root, and no co-signature shall depend on another for its cryptographic validity. |
| Guidance | Policy dependencies (e.g., minimum number of co-signatures for a classification label) are separate from cryptographic dependency. |
| Identifier | /req/artifact-format/cosignature-canonical-binding |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | All co-signatures on an artifact shall attest the same canonical payload. Partial attestation of the artifact is not conforming. |
| Guidance | A co-signer cannot selectively attest part of the artifact. |
| Identifier | /req/artifact-format/format-profile-cosignature-encoding |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | Each format profile registered in the scheme’s format profile registry shall specify how co-signature blocks, dimension tags, and chain references are encoded in that format. A format profile that does not define a co-signature encoding shall not claim conformance to the multi-dimensional attestation requirements. |
| Guidance | This ensures interoperability within a format profile for multi-dimensional artifacts. |
| Identifier | /req/artifact-format/cross-domain-no-cross-recognition |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | Cross-domain co-signatures shall not require participating roots to cross-certify each other; the co-signatures themselves shall provide cross-domain trust at the artifact level. |
| Guidance | The verifier holds anchors for multiple roots in the trust anchor bundle. |
| Identifier | /req/artifact-format/trust-cement |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | Once co-signatures are applied to an artifact, it shall not be possible to strip a co-signature without breaking the artifact’s self-description, and each co-signer’s commitment to the canonical payload shall be undeniable. |
| Guidance | The transparency log records the artifact with all co-signatures and cannot be rewritten. |
| Identifier | /req/artifact-format/dimensional-convergence |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | All dimension attestations on an artifact shall sign the same canonical payload, making the artifact the convergence point of orthogonal trust dimensions. |
| Guidance | Each dimension has its own trust tree and root; no cross-recognition between dimension roots is required. |
| Identifier | /req/artifact-format/time-dimension |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | The time dimension shall be attested by a time key — a co-signature from a time authority that records the existence of the artifact hash at a stated time and anchors that record to an external time source. |
| Guidance | The time dimension is objective, tamper-evident, and cross-domain. Timestamps use ISO 8601-1 representation (ISO 8601-1:2019). Timestamps use ISO 8601-1 representation (ISO 8601-1:2019). |
| Identifier | /req/artifact-format/dimension-extensibility |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A scheme may define trust dimensions beyond the initially registered set; each such dimension shall be attested by a co-signature carrying its registered dimension tag over the same canonical payload, shall be verified by the same pipeline as the initially registered dimensions, and shall be claimed through a dimension profile registered per Annex C. |
| Guidance | The set of trust dimensions is open for extension and closed for modification: registered dimensions and their semantics are not redefined by later profiles. |
| Identifier | /req/artifact-format/living-artifact |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A trusted artifact shall support accumulation of dimension attestations over time, provided that each added attestation signs the original canonical payload without modification. |
| Guidance | As additional dimensions converge, the coverage report gains fields and the classification label may improve. |
| Identifier | /req/artifact-format/wrapping-prevention |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | A conforming signature wrapper shall ensure that the byte range covered by the cryptographic signature is exactly the byte range processed by the verifier for all downstream checks, and the verifier shall reject any artifact where signed content and processed content are not provably identical. |
| Guidance | For XML-based profiles, the signed and verified node sets shall be identical. For JSON-based and CBOR-based profiles, the signed payload shall be the sole input to downstream processing. |
| Identifier | /req/artifact-format/replay-protection |
|---|---|
| Included in | Requirements class 2: Artifact format and signature binding (/req/artifact-format) |
| Statement | Each co-signature shall bind to a unique artifact identifier in addition to the canonical payload hash, and the verifier shall reject any co-signature whose artifact identifier does not match the artifact being verified. |
| Guidance | The artifact identifier may be a transparency log sequence number or a nonce embedded in the canonical payload. |
8 Cryptographic algorithms
8.1 General
This clause specifies the cryptographic algorithms recognized in the SIGNATIF framework, the composite signature model for post-quantum readiness, and the algorithm agility framework that governs algorithm identifier assignment, negotiation, and deprecation.
The SIGNATIF framework recognizes classical signature algorithms, post-quantum signature algorithms, and composite signatures that combine both; stateful hash-based schemes such as XMSS and HSS serve long-validity artifacts (IETF RFC 8391, IETF RFC 8554), and classical mechanisms follow established digital-signature standards (ISO/IEC 14888). An implementation may support any subset, subject to the requirements of its claimed conformance classes.
8.2 Classical signature algorithms
Classical signature algorithms registered in the algorithm identifier registry (Annex C) are recognized. The initial registry contents are listed in Table 48.
| Algorithm | Parameters | Reference |
|---|---|---|
| ECDSA | P-256 (secp256r1) | NIST FIPS 186-4 |
| EdDSA (Ed25519) | Ed25519 | IETF RFC 8032 |
Additional classical algorithms, including national or regional standards such as SM2, may be registered per the scheme’s registration policy.
Classical algorithms are vulnerable to cryptanalytic attacks by sufficiently large quantum computers. Deployments with long-term security requirements should migrate to post-quantum or composite algorithms.
8.3 Post-quantum signature algorithms
Post-quantum signature algorithms registered in the algorithm identifier registry maintained by the scheme (see Annex C) are recognized. The initial registry contents are listed in Table 49.
| Algorithm | Standard | Notes |
|---|---|---|
| ML-DSA | NIST FIPS 204 | Module-lattice-based; recommended parameter sets ML-DSA-44, ML-DSA-65, ML-DSA-87 |
| SLH-DSA | NIST FIPS 205 | Hash-based; conservative but larger signatures |
8.4 Composite signatures
A composite signature is a single signature produced by the AND-composition of two or more signature algorithms over the same canonical payload. All component signatures shall verify for the composite to be valid.
The primary use case for composite signatures is combining a classical algorithm with a post-quantum algorithm for transition security during post-quantum migration. Compositions of two post-quantum algorithms or other multi-algorithm combinations are also permitted.
EXAMPLE A composite signature might combine Ed25519 (classical) with ML-DSA-65 (post-quantum). The verifier validates both components; the composite is valid only if both succeed.
8.5 Post-quantum migration path
The framework supports migration from classical to post-quantum algorithms. The migration is governed by the algorithm agility framework (see Clause 19).
NOTE A typical migration follows three phases: (1) classical-only, where the deployment uses classical signatures exclusively; (2) composite, where the deployment uses composite signatures for new artifacts while classical-only artifacts remain verifiable; (3) post-quantum-only, where classical-only signatures are deprecated and eventually rejected. The specific timing and phase boundaries are deployment decisions.
8.6 Algorithm agility
Algorithm agility ensures that new algorithms can be introduced and old algorithms deprecated without breaking existing verifiers.
Identifiers. Each algorithm shall carry an explicit identifier in the signature wrapper. Verifiers shall use this identifier to select the validation method.
Negotiation. An issuer shall use algorithms recognized by its target verifiers. Algorithm identifiers carry sufficient metadata for verifiers to determine support.
Deprecation. Deprecated algorithms shall be announced in advance. Verifiers may downgrade or reject artifacts using deprecated algorithms according to their policy.
8.7 Requirements
Cryptographic algorithms has its formalized requirements class described in Table 50, Requirements class 3, with its requirements listed from Table 51, Requirement 32 to Table 57, Requirement 38.
| Identifier | /req/algorithms/classical-algorithms |
|---|---|
| Included in | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Statement | The framework shall recognize classical signature algorithms registered in the algorithm identifier registry (Annex C). |
| Guidance | Additional classical algorithms may be registered per the registration policy. EXAMPLE 1 ECDSA with P-256 and Ed25519 are examples of initially registered classical algorithms. EXAMPLE 2 SM2 is an example of a national standard algorithm registrable under the same policy. |
| Identifier | /req/algorithms/post-quantum-algorithms |
|---|---|
| Included in | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Statement | The framework shall recognize post-quantum signature algorithms registered in the algorithm identifier registry (Annex C). |
| Guidance | Additional post-quantum algorithms may be registered per the registration policy. EXAMPLE ML-DSA per FIPS 204 and SLH-DSA per FIPS 205 are examples of initially registered post-quantum algorithms. |
| Identifier | /req/algorithms/composite-and-semantics |
|---|---|
| Included in | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Statement | A composite signature shall be the AND-composition of two or more signature algorithms over the same canonical payload under a composite algorithm identifier that binds the component public keys and domain-separates the composite from its components; all component signatures shall verify for the composite to be valid, and a component signature shall not be valid as a standalone signature on the artifact. |
| Guidance | The primary use case for composite signatures is combining a classical algorithm with a post-quantum algorithm for transition security during post-quantum migration. Compositions of two post-quantum algorithms or other multi-algorithm combinations are also permitted. |
| Identifier | /req/algorithms/migration-phases |
|---|---|
| Included in | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Statement | The framework shall support a migration path from classical-only through composite to post-quantum-only signatures, governed by the algorithm agility framework. |
| Guidance | Each phase is a deployment policy decision; the framework supports all three. |
| Identifier | /req/algorithms/algorithm-agility-identifiers |
|---|---|
| Included in | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Statement | Each algorithm shall carry an explicit identifier in the signature wrapper, and verifiers shall use this identifier to select the validation method and determine support. |
| Guidance | Deprecated algorithms shall be announced in advance. |
| Identifier | /req/algorithms/encryption-at-rest |
|---|---|
| Included in | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Statement | Private keys and sensitive data at rest shall be encrypted using an authenticated encryption algorithm meeting the minimum security parameters in Table 156, with the encryption key derived using a password-based key derivation function resistant to brute-force attacks. |
| Guidance | The choice of specific encryption and key derivation algorithms is an implementation decision. AES-256-GCM and PBKDF2 are examples of suitable algorithms; ChaCha20-Poly1305, Argon2, scrypt, and other algorithms with equivalent or greater security strength are also acceptable. |
| Identifier | /req/algorithms/minimum-security-parameters |
|---|---|
| Included in | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Statement | Conforming implementations shall use algorithms and parameters providing a minimum security strength of 128 bits, and shall not generate or accept keys, signatures, or hashes below this minimum. |
| Guidance | For long-term security (artifact validity exceeding 10 years), a minimum of 192 bits is recommended. SHA-1 and MD5 are prohibited. Random number generators shall conform to a recognized standard. |
9 Threshold signing
9.1 General
In the SIGNATIF framework, threshold signing is not a property of the root alone. Any trust authority at any level of the trust graph may operate under a threshold scheme, ensuring that no single key compromises any level of the delegation hierarchy.
A threshold authority requires at least T of N designated key holders to cooperate to produce a valid signature under the authority’s aggregate key. No individual holder possesses the full signing capability; the aggregate key is composed from member-contributed shares. Schnorr-based signature schemes (BIP 340) admit compact threshold aggregation under this model.
9.2 Threshold at every level
A delegated trust authority whose members are threshold key holders produces signatures under a threshold scheme. The threshold parameters propagate through the delegation hierarchy. Example threshold parameters by authority level are given in Table 58.
| Authority | Quorum | Delegates to |
|---|---|---|
| root trust authority | 5-of-7 (example) | Delegated trust authority A’s aggregate key |
| Delegated trust authority A | 3-of-5 (example) | Delegated trust authority B’s aggregate key |
| Delegated trust authority B | 2-of-3 (example) | End certificate (1-of-1) |
Each delegation certificate shall carry the child’s aggregate public key, the quorum definition (T, N), and the member identity references. A single-key authority (1-of-1) omits the quorum parameters.
9.3 Aggregate key continuity
When a threshold authority rotates a member — adding, removing, or replacing a key holder — the aggregate key shall remain unchanged. The parent’s delegation shall remain valid without re-issuance.
This is achieved through threshold re-share protocols that preserve the aggregate public key while redistributing the secret shares among the new member set. Member rotation is transparent to all verifiers and to all parent authorities.
9.4 Nested threshold
A threshold delegated trust authority whose members are themselves threshold authorities forms a nested threshold structure. Signing by the outer authority may require the inner authority to first reach its own quorum, then contribute a share to the outer authority’s threshold.
Nested threshold structures enable arbitrarily deep trust arrangements that span multiple organizational layers, each with its own quorum policy.
9.5 Federated trust authorities
9.5.1 Definition
A federated trust authority (FTA) is a threshold delegated trust authority whose members are independent organizations, each potentially a threshold authority itself. An FTA has:
its own aggregate key, composed from member-contributed shares;
its own quorum (M-of-K member organizations);
its own scope, which may span member hierarchies;
its own ceremony protocol for cross-organization coordination.
No single member organization controls an FTA. The threshold ensures that a specified number of independent organizations must cooperate to exercise the FTA’s signing power.
9.5.2 Recursive composition
FTAs may be composed recursively. An FTA may itself be a member of another FTA, creating arbitrarily deep trust structures.
EXAMPLE FTA F₁ (3-of-5: {DTA_A, DTA_B, DTA_C, DTA_D, DTA_E}) is a member of FTA F₂ (2-of-4: {DTA_F, DTA_G, DTA_H, FTA_F₁}). Signing by F₂ may require F₁ to internally reach 3-of-5 among its members, then contribute one share to F₂’s 2-of-4 threshold.
9.5.3 Hierarchy-spanning
An FTA may include members from independent root trust authorities. Artifacts signed by such an FTA are verifiable against the FTA’s aggregate key, which is recognized by all member hierarchies. This creates trust bridges between otherwise independent roots.
9.5.4 Lifecycle
An FTA lifecycle consists of:
Formation. Member organizations contribute shares; the aggregate key is computed and published.
Delegation. The FTA delegates to subordinate delegated trust authorities using its aggregate key.
Re-share. Member organizations join or leave without changing the aggregate key (see 9.3).
Dissolution. The aggregate key is retired. Historical artifacts signed before dissolution remain valid if their chains and scope remain valid.
9.6 Ceremony protocol
A ceremony is the protocol by which a quorum of key holders cooperates to produce a threshold signing signature. The SIGNATIF framework is ceremony-protocol-neutral: any protocol that produces a verifiable threshold signature under the authority’s aggregate key may be used.
A ceremony protocol shall:
produce a signature verifiable against the authority’s published aggregate key;
ensure that fewer than T members cannot produce a valid signature;
produce a ceremony record (see Clause 16) that is independently verifiable.
9.7 Requirements
Threshold signing and federated trust authorities has its formalized requirements class described in Table 59, Requirements class 4, with its requirements listed from Table 60, Requirement 39 to Table 71, Requirement 50.
| Identifier | /req/threshold-signing/threshold-every-level |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | Any trust authority at any level of the trust graph shall be able to operate under a threshold scheme, such that no single key compromises any level of the delegation hierarchy. |
| Guidance | A single-key authority (1-of-1) is permitted but does not provide threshold protection. The quorum parameters (T, N) are carried in the authority’s delegation certificate. |
| Identifier | /req/threshold-signing/quorum-in-delegation |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A delegation certificate for a threshold child authority shall carry the child’s aggregate public key, the quorum definition (T, N), and references to the member identities. |
| Guidance | Member identity references should be transparency-log sequence numbers or equivalent verifiable identifiers. |
| Identifier | /req/threshold-signing/aggregate-key-continuity |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | When a threshold authority rotates a member, the aggregate key shall remain unchanged, and all existing delegations from parent authorities shall remain valid without re-issuance. |
| Guidance | This is achieved through threshold re-share protocols that preserve the aggregate public key while redistributing secret shares. Re-share and dissolution ceremonies shall be transparency-logged and epoch-stamped; dissolution shall revoke the aggregate key state. |
| Identifier | /req/threshold-signing/nested-threshold |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A threshold delegated trust authority whose members are themselves threshold authorities shall be supported, such that signing by the outer authority requires inner authorities to reach their own quorum before contributing shares. |
| Guidance | Nested threshold structures may span multiple organizational layers. |
| Identifier | /req/threshold-signing/fta-formation |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A federated trust authority shall be formed by independent organizations contributing shares to produce a single aggregate key, such that no single member organization controls the authority. |
| Guidance | The FTA carries its own quorum (M-of-K member organizations), scope, and ceremony protocol. |
| Identifier | /req/threshold-signing/fta-recursive-composition |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A federated trust authority shall be permitted to be a member of another federated trust authority, enabling recursively composed trust structures. |
| Guidance | Signing by a composite FTA may require inner FTAs to reach their own quorum before contributing shares to the outer FTA. |
| Identifier | /req/threshold-signing/fta-hierarchy-spanning |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A federated trust authority shall be permitted to include members from independent root trust authorities, producing artifacts verifiable against the FTA’s aggregate key and recognized by all member hierarchies. |
| Guidance | This creates trust bridges between otherwise independent roots. |
| Identifier | /req/threshold-signing/fta-reshare |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A federated trust authority shall support member join and leave operations that preserve the aggregate key, such that historical artifacts remain valid. |
| Guidance | Dissolution of an FTA retires the aggregate key but does not invalidate artifacts signed before dissolution whose chains and scope remain valid. |
| Identifier | /req/threshold-signing/ceremony-threshold-property |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A ceremony protocol shall produce a signature verifiable against the authority’s published aggregate key and shall ensure that fewer than T members cannot produce a valid signature. |
| Guidance | The SIGNATIF framework is ceremony-protocol-neutral; any protocol satisfying these properties may be used. |
| Identifier | /req/threshold-signing/rogue-key-prevention |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | Each member of a threshold authority shall demonstrate possession of the private key corresponding to their contributed public share during key generation, and the aggregate key computation shall incorporate all member public keys in a manner secure against rogue-key attacks. |
| Guidance | Proof-of-possession prevents a malicious member from registering a crafted key that makes the aggregate key equal to their solo key. |
| Identifier | /req/threshold-signing/ceremony-robustness |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A conforming ceremony protocol shall provide identifiable abort (identifying the member causing failure), nonce commitment to prevent nonce bias, and a documented policy for handling member non-participation. |
| Identifier | /req/threshold-signing/ceremony-record-production |
|---|---|
| Included in | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Statement | A ceremony shall produce a verifiable ceremony record that documents the participating members, the threshold parameters, and the signature produced. |
| Guidance | Detailed ceremony record requirements are specified in /req/ceremony/. |
10 Trust chain and authorization scope governance
10.1 General
The scope is a first-class concept in the SIGNATIF framework. Unlike traditional PKI, in which a CA’s authorization boundary is defined by external policy and is not verifiable from the certificate itself, the authorization scope in this document is a signed field carried in every delegation certificate and end certificate, cryptographically enforced at every chain link.
This clause specifies the authorization scope data model, the monotonic narrowing invariant, scope conditions as executable predicates, and the multi-layer enforcement model.
10.2 Authorization scope structure
An authorization scope is a multi-dimensional constraint set. Each scope dimension constrains one axis of the authorization boundary independently. The initially defined scope dimensions are listed in Table 72; geographic values may use the country codes of ISO 3166-1:2020.
| Dimension | Constrains | Example values |
|---|---|---|
| domain | The field of application | pharma, supply-chain, credentials, or wildcard |
| subdomain | The area within the domain | manufacturing, cold-chain, or wildcard |
| class | The type of object | {"vaccine", "tablet"}, or wildcard |
| instance | The specific model | LOT-2026-001, or wildcard |
| identity | The specific unit | BATCH-A, or wildcard |
| conditions | Executable predicates on artifact content | See 10.4 (uses inverted narrowing: child shall be a superset of parent) |
Each dimension may carry the wildcard value (denoting no constraint on that axis), a set of values, or a single value. Narrowing a dimension means replacing a wider constraint with a narrower one: wildcard narrows to set or single; set narrows to subset or single; single narrows to the same single only.
10.3 Monotonic narrowing invariant
At every delegation link, the child scope shall be a subset of (or equal to) the parent scope on every dimension. This is the monotonic narrowing invariant (Figure 4).
The narrowing relation is defined by the following algorithm. Given a parent scope S_p and a child scope S_c, narrowed(S_p, S_c) holds if and only if the following procedure returns true:
Normalize both scopes: singleton sets {x} are equivalent to the single value x and shall be normalized before comparison.
For each scope dimension d in the union of dimensions present in S_p and S_c:
Let v_p be the value of dimension d in S_p (wildcard if absent).
Let v_c be the value of dimension d in S_c (wildcard if absent).
If v_p is wildcard, the dimension is narrowed regardless of v_c. Continue to the next dimension.
If v_c is wildcard and v_p is not wildcard, the dimension is widened. Return false.
If both v_p and v_c are single values: the dimension is narrowed if and only if v_c = v_p. If v_c is not equal to v_p, return false.
If v_p is a single value and v_c is a set: the dimension is widened. A set cannot be narrower than a single value. Return false.
If v_p is a set and v_c is a single value: the dimension is narrowed if and only if v_c is a member of v_p. If not, return false.
If v_p is a set and v_c is a set: the dimension is narrowed if and only if v_c is a subset of v_p (set inclusion). If not, return false.
Let C_p be the set of scope conditions in S_p and C_c the set in S_c. The conditions dimension is narrowed if and only if C_c is a superset of C_p (every condition in the parent is also present in the child, and the child may add additional conditions). If any parent condition is absent from the child, return false.
Return true.
An artifact signed under S_c satisfies the scope if narrowed(S_p, S_c) holds at every delegation link from the root to the end certificate, and all conditions in the effective scope (the narrowest along the chain) evaluate to true against the artifact content.
Widening any dimension at any delegation link constitutes a hard verification failure. The verifier shall reject any chain in which narrowed(S_p, S_c) returns false at any link.
10.4 Authorization scope conditions
A scope condition is an executable predicate included in a scope, evaluated at verification time against the content and context of the trusted artifact. Scope conditions bind signing authority to live state, not merely to static identity.
A scope condition may assert, for example:
that a measured value falls within a specified tolerance;
that a certification is valid at the signature time;
that a compliance status holds;
that an environmental reading is within an acceptable range.
An artifact signed by a key whose scope conditions are not met fails verification, regardless of the cryptographic validity of the signature.
Scope conditions shall be expressed in a machine-checkable, deterministic format. The condition language shall be non-Turing-complete. The evaluation of any condition shall terminate in time bounded by a polynomial function of the input size. The evaluation context (the artifact content and any external state references) shall be fully determined by the artifact and its chain, such that two independent verifiers evaluating the same condition reach the same result.
10.5 Authorization scope encoding
Scope shall be encoded in a format that is:
Machine-checkable. The narrowing relation and condition evaluation shall be verifiable without human interpretation of free text.
Compact. The encoding shall be wire-efficient, as scope is carried in every certificate.
Extensible. New scope dimensions and condition types shall be addable without breaking existing verifiers that do not recognize them.
The scope is carried in a certificate extension (the authorizedScopes extension or equivalent in the applicable format profile). Format profiles specified in Clause 7 define the concrete encoding for each supported serialization.
10.6 Multi-layer enforcement
Scope is enforced at multiple independent layers:
Certificate extension. The scope is carried in the certificate, signed by the parent authority. Tampering with the scope invalidates the signature.
Chain verification. The monotonic narrowing invariant is checked at every delegation link. Widening on any dimension causes rejection.
Verification pipeline. The verification pipeline includes a scope check that confirms the artifact’s content falls within the scope of the signing key, including evaluation of all scope conditions.
Transparency log. The scope is recorded in the public transparency log for every certificate, enabling audit and detection of scope violations by third parties.
10.7 Requirements
Trust chain and authorization scope governance has its formalized requirements class described in Table 73, Requirements class 5, with its requirements listed from Table 74, Requirement 51 to Table 81, Requirement 58.
| Identifier | /req/scope/scope-structure |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | The scope of a trust authority shall be expressed as a multi-dimensional constraint set in which each scope dimension constrains one axis of the authorization boundary independently. |
| Guidance | Scope dimensions include, non-exhaustively, domain, subdomain, class, instance, and identity. Each dimension may carry the wildcard value, a set of values, or a single value. |
| Identifier | /req/scope/monotonic-narrowing |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | At every delegation link, the child scope shall be a subset of (or equal to) the parent scope on every scope dimension. |
| Guidance | The narrowing relation is, wildcard encompasses any value; set encompasses subset or single; single encompasses the same single only. |
| Identifier | /req/scope/widening-rejection |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | A verifier shall reject any verification path on which scope widening is detected on any scope dimension at any delegation link. |
| Guidance | Widening constitutes a hard verification failure, not a warning or downgrade. |
| Identifier | /req/scope/scope-conditions |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | A scope may include scope conditions, which shall be executable predicates evaluated at verification time against the content and context of the trusted artifact. |
| Guidance | An artifact signed by a key whose scope conditions are not met shall fail verification, regardless of cryptographic signature validity. The condition language and its version are registered per Annex C; the registered subset shall avoid operators whose coercion or evaluation order is implementation-defined. Condition sets are compared for narrowing by byte-equality of their canonically serialized form. |
| Identifier | /req/scope/condition-determinism |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | The evaluation context for a scope condition shall be fully determined by the artifact and its chain, such that two independent verifiers evaluating the same condition reach the same result. |
| Guidance | External state references in conditions shall be resolved to deterministic, verifiable inputs (e.g., transparency log entries, timestamp anchors). Offline evaluation uses verifier-cached external state pinned to the verification time; the coverage report records the cache age of each condition input. |
| Identifier | /req/scope/scope-encoding |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | The scope encoding shall be machine-checkable, compact, and extensible, carried in a certificate extension identifiable by conforming verifiers. |
| Guidance | Machine-checkable means the narrowing relation and condition evaluation are verifiable without human interpretation of free text. Extensible means new dimensions and condition types can be added without breaking verifiers that do not recognize them. |
| Identifier | /req/scope/four-layer-enforcement |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | Scope shall be enforced at four layers, in the signed certificate extension, at every chain verification link, in the verification pipeline including condition evaluation, and in the transparency log recording. |
| Guidance | This defence-in-depth model ensures that scope violations are caught at multiple independent checkpoints. |
| Identifier | /req/scope/scope-in-transparency |
|---|---|
| Included in | Requirements class 5: Trust chain and authorization scope governance (/req/scope) |
| Statement | The scope of every delegation certificate and end certificate shall be recorded in a recognized transparency log, enabling third-party audit of scope assignments. |
| Guidance | This enables detection of scope violations by parties other than the verifier. |
11 Revocation and artifact binding
11.1 General
PKI provides robust certificate-level revocation through CRLs and OCSP (IETF RFC 6960). In the SIGNATIF framework, revocation additionally propagates to artifacts: revoking a trust authority state flags every trusted artifact transitively bound to that state, across all trust dimensions and all trust chains.
This clause specifies the certificate revocation list (CRL) profile, the hash-binding model that links artifacts to authority states, the propagation algorithm, and the query interface for discovering bound artifacts.
11.2 Certificate revocation list
A certificate revocation list (CRL) is a signed, time-stamped list of revoked end certificates and delegated trust authority credentials. A CRL shall:
identify the issuing trust authority whose revoked credentials it lists;
carry each revoked credential’s fingerprint, the revocation time, and the revocation reason;
carry a validity period during which it is authoritative — after expiry, verifiers shall fetch a current CRL or apply a grace period policy (see 11.9);
be itself recorded in a transparency log to enable audit of revocation decisions.
The specific CRL format is a deployment decision.
NOTE X.509 CRLs as profiled in IETF RFC 5280 are an example of a recognized CRL format.
11.3 Status lists
A scheme may operate revocation as a status list: a signed, compactly encoded bitstring in which each issued credential occupies an indexed slot, published by the revoking authority and fetchable by any verifier without per-credential queries. A status list used for SIGNATIF revocation shall:
be a signed document issued by the authority that issued the credentials it statuses;
encode a per-credential status of at least unset, revoked, and suspended;
carry a validity period and an update policy sufficient for verifiers to detect staleness (see 11.9);
define the semantic meaning of each status value in the scheme’s profile — the encoding carries the value, the profile assigns the consequence.
A status list and a CRL are alternative surfaces for the same revocation decision; a scheme shall state which surface (or both) it operates, and a verifier configured for the scheme shall consult every declared surface. Revocation propagation (11.5) applies to status-list revocations exactly as to CRL revocations.
NOTE W3C Bitstring Status List entries attached to verifiable credentials (see Annex G) are an example of a recognized status list format. Where a scheme composes with verifiable credentials, the status list is the native surface; where a scheme operates X.509 chains, the CRL is native. A scheme may operate both and reconcile them through the transparency log.
11.4 Hash-binding to authority states
A trusted artifact carries a cryptographic hash-binding to the authority states under which it was produced. These states include:
the certification state of the issuing device (if applicable);
the evaluative state of the testing or inspection authority;
the compliance state of the regulatory framework;
any other state whose validity is a precondition for the artifact’s trustworthiness.
The hash-binding is a digest of the relevant state, embedded in the artifact or referenced via the transparency log. The binding is signed as part of the canonical payload.
11.5 Propagation algorithm
When an authority state is revoked, the propagation algorithm shall flag every artifact transitively bound to that state. The propagation query is performed by the transparency log operator (or a mirror) to discover the set of affected artifacts; an offline verifier checks individual artifact bindings against cached revocation data.
Identify the revoked state by its hash or identifier.
Query the set of artifacts whose hash-binding includes the revoked state. This query uses the transparency log index.
Mark each affected artifact as bound to a revoked state. Marking does not delete or alter the artifact; it flags its revocation status.
Propagate through co-signatures: if a co-signature on an artifact originates from a revoked authority, the artifact is flagged.
An artifact flagged as bound to a revoked state shall receive the scheme’s rejected classification label, regardless of other dimensional coverage.
11.6 Scope condition withdrawal
A scope condition may reference an external state (e.g., a calibration certificate, a compliance status, an accreditation). When that external state is revoked, all artifacts whose scope conditions depend on it shall be flagged.
The withdrawal propagation algorithm:
Identify the revoked external state by its hash or identifier.
Query the set of artifacts whose scope includes a condition referencing the revoked state. This query uses the scope encoding in the artifact’s chain certificates and the transparency log index.
For each affected artifact, re-evaluate the scope conditions. If a condition now evaluates to false, the artifact is flagged with a scope_condition_failed failure reason (see 13.9).
An artifact flagged through condition withdrawal shall receive the scheme’s rejected classification label, consistent with the scope condition hard check in the verification pipeline (see Clause 13).
NOTE Scope condition withdrawal is a form of trust repudiation: trust granted under a condition that is later invalidated is formally withdrawn. This completes the trust lifecycle — conditions are not permanent assumptions but live predicates that can fail retroactively.
11.7 Flag semantics
Revocation propagation uses flag semantics, not deletion:
The artifact is marked as bound to a revoked state, not removed.
The marking is queryable: a verifier can determine whether an artifact is affected by querying the revocation status of its bound states.
The marking is reversible if the revocation is itself revoked (e.g., a false positive is corrected).
This approach preserves the audit trail while preventing acceptance of artifacts whose trust foundation has been revoked.
11.8 Query interface
A verifier shall be able to query the revocation status of an artifact through the following interface:
Given an artifact, return its bound authority states and their revocation status.
Given a revoked state, return the set of artifacts transitively bound to it.
The query interface shall be usable offline against cached CRLs and transparency log indices.
11.9 Offline verification and grace period
For offline verification, a verifier shall apply a CRL grace period policy:
If the verifier holds a CRL within its validity period, revocation status is determined from the CRL directly.
If the verifier’s CRL is expired but within a configurable grace period, the verifier may accept the stale CRL with a classification downgrade.
If the CRL is expired beyond the grace period, the verifier shall reject artifacts whose chain includes authorities subject to that CRL.
11.10 Requirements
Revocation and artifact binding has its formalized requirements class described in Table 82, Requirements class 6, with its requirements listed from Table 83, Requirement 59 to Table 90, Requirement 66.
| Identifier | /req/revocation/crl-profile |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | A certificate revocation list shall be a signed, time-stamped list of revoked credentials that identifies the issuing trust authority, carries revoked credential fingerprints with revocation time and reason, carries a validity period, and is recorded in a transparency log. |
| Guidance | The CRL is authoritative only within its validity period. Alternative revocation list formats may be registered for non-X.509 certificate profiles. EXAMPLE When X.509 certificates are used, the CRL profile follows RFC 5280. |
| Identifier | /req/revocation/status-list-surface |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | A scheme operating revocation as a status list shall publish it as a signed document of the issuing authority, encoding at least unset, revoked, and suspended per credential, and shall define the semantic consequence of each status value in the scheme profile; revocation propagation shall apply to status-list revocations as it does to CRL revocations. |
| Guidance | W3C Bitstring Status List is an example of a recognized encoding. A scheme shall state whether it operates a CRL, a status list, or both; a verifier shall consult every declared surface. |
| Identifier | /req/revocation/hash-binding |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | A trusted artifact shall carry a cryptographic hash-binding to the authority states under which it was produced, embedded in the canonical payload or referenced via the transparency log. |
| Guidance | Authority states include calibration, evaluation, compliance, and other states whose validity is a precondition for the artifact’s trustworthiness. |
| Identifier | /req/revocation/propagation |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | When an authority state is revoked, the revocation shall propagate to every artifact transitively bound to that state across all trust dimensions and trust chains, marking each affected artifact. |
| Guidance | Propagation uses the transparency log index to discover bound artifacts. An artifact flagged as bound to a revoked state shall receive the scheme’s rejected classification label. Propagation shall be verifiable from signed CRLs and inclusion proofs alone, without depending on the log operator’s active behaviour. |
| Identifier | /req/revocation/flag-semantics |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | Revocation propagation shall mark affected artifacts as bound to a revoked state without deleting or altering them, and the marking shall be queryable and reversible if the revocation is corrected. |
| Guidance | This preserves the audit trail while preventing acceptance of affected artifacts. |
| Identifier | /req/revocation/query-interface |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | A verifier shall be able to query the revocation status of an artifact by returning its bound authority states and their revocation status, and to query the set of artifacts bound to a given revoked state. |
| Guidance | The query interface shall be usable offline against cached CRLs and transparency log indices. |
| Identifier | /req/revocation/offline-grace-period |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | A verifier shall apply a CRL grace period policy for offline verification, accepting a stale CRL within a configurable grace period with a classification downgrade, and rejecting artifacts whose CRL is expired beyond the grace period. The grace period shall not exceed the scheme’s published maximum, and acceptance within the grace period shall carry a label that identifies the revocation state as stale. |
| Identifier | /req/revocation/scope-condition-withdrawal |
|---|---|
| Included in | Requirements class 6: Revocation and artifact binding (/req/revocation) |
| Statement | When an external state referenced by a scope condition is revoked, the revocation shall propagate to every artifact whose scope includes a condition referencing that state, re-evaluating the condition and flagging affected artifacts. |
| Guidance | Artifacts flagged through condition withdrawal shall receive the scheme’s rejected classification label. This is a form of trust repudiation — trust granted under an invalidated condition is formally withdrawn. If the CRL is within its validity period, revocation status is determined directly. |
12 Transparency and multi-log attestation
12.1 General
Every end certificate and every trusted artifact shall be recorded in a recognized transparency log by the issuing authority. This is a normative requirement on issuance, not on verification.
At verification time, transparency log inclusion is a soft check: artifacts not provably included in a recognized log are downgraded (see Clause 13). A verifier whose policy sets requires_transparency to true (the default) rejects artifacts without inclusion proofs; a verifier whose policy sets it to false accepts them at a downgraded classification label.
This clause specifies the transparency log structure, inclusion proofs, external time anchoring, gossip between mirrors, and the multi-log attestation model.
12.2 Transparency log structure
A transparency log shall be implemented as an append-only data structure with the following properties:
Inclusion proofs. The log shall support cryptographic proofs that a specific entry is included at a specific log state, without requiring the verifier to download the entire log.
Append-only. Entries may be added but never modified or removed. The log head (a cryptographic commitment to the entire log contents) shall be published at each update.
Log head signatures. Each log head shall be signed by the log operator, enabling verifiers to confirm they are viewing an authentic log state.
Domain separation. The log shall prevent second-preimage attacks through domain separation between leaf and internal node data.
Consistency proofs. The log shall support cryptographic proofs that a new tree head extends a previously published tree head — i.e., the log is append-only between any two published states. A consistency proof enables a verifier to confirm that no entries were removed or modified between two log states.
NOTE Merkle trees as specified in IETF RFC 6962, continued by the version 2 design (IETF RFC 9162), are an example of a log structure; the IETF SCITT work applies comparable signed transparency to supply-chain artifacts satisfying these properties. Other append-only log constructions with equivalent inclusion proof and consistency proof guarantees may be used.
12.3 Consistency proof
A consistency proof demonstrates that a new tree head is a valid extension of a previously known tree head — that no entries were removed or modified between the two states.
A consistency proof shall consist of:
the old tree head (root hash and tree size);
the new tree head (root hash, tree size, and timestamp);
the audit path of intermediate hashes connecting the two states.
The verifier shall validate the consistency proof by recomputing the root hashes from the audit path and confirming that the new tree head contains all entries of the old tree head as a prefix.
Mirrors and verifiers shall use consistency proofs to verify the append-only property of the log over time (see 12.6). A log that cannot produce a consistency proof between two claimed sequential tree heads is evidence of misbehaviour.
12.4 Inclusion proof
An inclusion proof demonstrates that a specific entry (an end certificate or a trusted artifact) is included in a transparency log at a specific tree head.
An inclusion proof shall consist of:
the leaf hash of the entry;
the audit path (the set of sibling hashes from the leaf to the root);
the tree head (root hash, tree size, and timestamp) against which the proof is validated;
the log operator’s signature over the tree head.
The verifier shall validate the inclusion proof by recomputing the root hash from the leaf and audit path, comparing it to the tree head, and validating the tree head signature.
12.5 External time anchoring
Each tree head shall be anchored to an external, irrefutable time source to prove that the log state existed at a specific time. The anchoring shall produce a verifiable proof that the tree head hash was committed to the external source within the tree head’s timestamp window. Decentralized anchoring infrastructures such as OpenTimestamps satisfy this requirement.
12.6 Mirrors and gossip
12.6.1 Mirrors
A mirror is an independent operator that replicates a transparency log and serves inclusion proofs and log entries to verifiers. Mirrors provide:
Availability. If the primary log operator is unavailable, mirrors continue to serve the log.
Integrity. Mirrors independently verify the log’s append-only property by checking that each new tree head extends the previous one.
Detection. Mirrors detect log misbehaviour (e.g., a split view where the log operator presents different tree heads to different verifiers).
12.6.2 Gossip
gossip is the protocol by which mirrors and verifiers cross-check their views of a transparency log by comparing tree head fingerprints. A gossip quorum of at least 2-of-3 independent sources agreeing on a tree head provides corroboration that the log state is consistent.
A verifier shall confirm that the tree head it relies on is observed by at least the gossip quorum before accepting inclusion proofs against that tree head.
12.7 Multi-log attestation
For artifacts issued by a federated trust authority, the issuing authority may require inclusion in at least M of K independent transparency logs, where M and K are specified by the authority’s policy.
Multi-log attestation ensures that no single log operator controls the record. An artifact meeting a multi-log quorum requirement shall carry inclusion proofs from at least M independent logs.
The verifier shall validate each inclusion proof independently and confirm that at least M of the K recognized logs include the artifact.
12.8 Requirements
Transparency and multi-log attestation has its formalized requirements class described in Table 91, Requirements class 7, with its requirements listed from Table 92, Requirement 67 to Table 101, Requirement 76.
| Identifier | /req/transparency/merkle-append-only |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | A transparency log shall be implemented as an append-only log with inclusion proofs, with domain-separated hashing for leaf and internal nodes, and each tree head shall be signed by the log operator. |
| Guidance | Domain separation prevents second-preimage attacks. RFC 6962 uses 0x00 prefix for leaves and 0x01 prefix for internal nodes. The Merkle tree semantics follow RFC 6962. Append-only history records that attestations were issued, not that their content remains accurate; rectification flows through supersession and the revocation propagation of clause 11. |
| Identifier | /req/transparency/inclusion-proof |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | An inclusion proof shall consist of the leaf hash, the audit path, the tree head (root hash, tree size, timestamp), and the log operator signature over the tree head. |
| Guidance | The verifier validates the proof by recomputing the root from the leaf and audit path. |
| Identifier | /req/transparency/tree-head-anchoring |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | Each tree head shall be anchored to an external irrefutable time source, producing a verifiable proof that the tree head hash was committed to the external source at or near the tree head timestamp. |
| Guidance | The anchoring proves that the log state existed at a specific time, independently of the log operator’s own assertion. Log policy should bound the maximum interval between signed tree heads so that a stale head is detectable within the freshness window; witness cosigning over tree heads or out-of-band fingerprint exchange strengthens the bound. |
| Identifier | /req/transparency/mirror-integrity |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | A mirror shall independently verify the log’s append-only property by checking that each new tree head extends the previous one, and shall serve inclusion proofs and log entries to verifiers. |
| Guidance | Mirrors detect log misbehaviour including split views. |
| Identifier | /req/transparency/gossip-quorum |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | A verifier shall confirm that the tree head it relies on is observed by at least a gossip quorum of independent sources before accepting inclusion proofs against that tree head. |
| Guidance | A gossip quorum of at least 2-of-3 independent sources provides strong assurance. The gossip quorum’s independence and source discovery are scheme-declared; witness cosignatures over tree heads satisfy the intent. |
| Identifier | /req/transparency/mandatory-inclusion |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | Every end certificate and trusted artifact shall be included in a recognized transparency log, and artifacts not provably included shall be downgraded or rejected. |
| Guidance | Transparency is a verification requirement, not an optional overlay. |
| Identifier | /req/transparency/multi-log-quorum |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | For artifacts issued by a federated trust authority whose policy requires multi-log attestation, the artifact shall carry inclusion proofs from at least M of K independent transparency logs, where M and K are specified by the policy. |
| Guidance | Each inclusion proof is validated independently. No single log operator controls the record. |
| Identifier | /req/transparency/log-content-minimization |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | Log leaves, inclusion proofs, and tree heads shall contain no directly identifying personal data; personal data referenced by an artifact shall be held in access-controlled registers by the responsible authority, with revocation and key rotation serving as the mechanism for withdrawal of validity. |
| Guidance | The log records issuance, not truth: corrections are made by superseding attestations and re-issuance, never by editing history. |
| Identifier | /req/transparency/log-retention |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | A recognized transparency log shall retain its append-only history, and its mirrors shall retain replicated history, for the maximum artifact validity period plus grace periods that the deployment serves. |
| Guidance | Retention obligations transfer with log succession per the scheme’s governance. Retention is bounded by purpose: the scheme’s retention policy defines deletion and suppression criteria once the served validity period ends. |
| Identifier | /req/transparency/consistency-proofs |
|---|---|
| Included in | Requirements class 7: Transparency and multi-log attestation (/req/transparency) |
| Statement | A transparency log shall support consistency proofs demonstrating that one signed tree head is a prefix of a later signed tree head, consisting of the minimal set of intermediate hashes that allows a verifier to confirm the prefix relationship without downloading the entire log. |
| Guidance | Mirrors shall validate consistency proofs between consecutive tree heads. Verifiers may request consistency proofs between any two observed tree heads. |
13 Verification pipeline
13.1 General
A verifier in the SIGNATIF framework applies an ordered sequence of checks to a trusted artifact, resolves the trust graph to find one or more verification paths to root anchors, produces an objective coverage report, applies the scheme’s classification policy to derive a grade label, and applies its acceptance policy to determine whether to accept the artifact.
This clause specifies the pipeline architecture, the hard and soft checks, the coverage report, the classification policy, the acceptance policy, and the time freshness window.
13.2 Pipeline architecture
The verification pipeline is an ordered sequence of checks applied to an artifact (Figure 5). Checks are classified as hard or soft:
Hard checks determine pass or fail of the pipeline. If any hard check fails, the pipeline short-circuits; the coverage report hard_checks field is set to fail.
Soft checks populate the coverage report but do not cause outright failure. Each soft check that passes contributes a positive coverage field; each that does not pass leaves that field unpopulated. The classification policy determines how these fields map to the classification label.
Table 102 classifies each check and states its purpose.
| Check | Classification | Purpose |
|---|---|---|
| Format validity | Hard | The artifact wrapper is well-formed and self-describing. |
| Signature validity | Hard | The primary signature and all co-signatures are cryptographically valid. |
| Chain integrity | Hard | Every delegation link is signed and the chain resolves to a root anchor. |
| Scope narrowing | Hard | The monotonic narrowing invariant holds on every dimension at every link. |
| Scope conditions | Hard | All scope conditions evaluate to true at verification time. |
| Revocation status | Hard | No authority on the path is revoked; no bound state is revoked. |
| Transparency inclusion | Soft | The artifact and all certificates are included in recognized transparency logs. |
| Time anchor | Soft | The artifact is anchored to an external time source via a time dimension attestation. |
| Cross-domain co-signatures | Soft | The artifact carries co-signatures from independent root hierarchies. |
| Multi-log attestation | Soft | The artifact is included in M-of-K independent transparency logs. |
13.3 Trust graph path-finding
13.3.1 General
The verifier enumerates all valid verification paths from the artifact to root anchors in the trust anchor bundle. The coverage report is computed as a pure function of the set of all valid paths, not of any single path. This ensures that two conforming verifiers that find the same set of valid paths produce identical coverage reports, regardless of path enumeration order.
13.3.2 Path enumeration algorithm
The path enumeration algorithm proceeds as follows:
Let P be the empty set of valid paths.
For each signature s on the artifact (primary and co-signatures):
Let path be the singleton path containing s.
Call extend(path, P).
Return P.
13.3.3 Path extension procedure
The extend(path, P) procedure:
Let node be the tail of path.
If node is a root anchor in the trust anchor bundle, add path to P and return.
For each delegation link from node to a parent parent:
Validate the signature on the delegation link. If invalid, skip this link.
Validate that narrowed(scope(parent), scope(node)) holds (see 10.3). If not, skip this link.
If the verifier’s policy requires chain-link transparency, validate log inclusion for the delegation certificate; if not included, skip this link.
Validate revocation status for parent. If revoked, skip this link.
Let extended be path with parent appended.
If extended does not contain a cycle (no repeated node), call extend(extended, P).
The set P contains all valid verification paths. The cross-domain diversity of the artifact is the number of distinct root anchors reached across all paths in P.
13.3.4 Independence of roots and logs
Two root anchors r1 and r2 are independent if neither is reachable from the other via delegation links in the trust graph and they do not share a common delegating ancestor other than themselves. Cross-domain co-signature counting for higher classification labels uses the number of distinct independent roots in P, not the number of paths.
Two transparency logs are independent if they are operated by different organizations and neither organization operates a log that the other recognizes. Multi-log attestation quorum (higher classification labels) uses the count of independent logs, not total logs.
13.4 Coverage report
The verification pipeline produces an objective coverage report containing the verification facts. The coverage report is a deterministic function of the artifact, the set of valid verification paths, and the verifier’s verification state (trust anchor bundle, cached CRLs, cached transparency log tree heads). Two conforming verifiers with the same verification state produce identical coverage reports.
The coverage report contains the following fields. The fields are listed in Table 103.
| Field | Description |
|---|---|
| hard_checks | pass if all hard checks (format, signature, chain, scope narrowing, scope conditions, revocation) pass; otherwise fail with typed failure reasons. |
| transparency_included | true if the artifact and all certificates on all paths are included in a recognized transparency log with valid inclusion proofs. |
| time_anchored | true if at least one time dimension attestation anchors the artifact to an external time source. |
| dimensions_verified | List of trust dimension tags with verified attestations on the artifact (e.g., ["data", "person", "location", "environment"]). |
| dimension_count | Count of verified non-data, non-time dimensions (person, location, environment, authorization, identity, oracle, and others registered by the scheme). |
| independent_roots | Count of distinct independent root anchors reached via co-signatures, excluding the primary signer’s root. |
| multi_log_quorum | true if the artifact meets the multi-log attestation quorum (at least M-of-K independent transparency logs include the artifact). |
| paths_found | Number of valid verification paths from the artifact to root anchors. |
These fields are the objective primitives from which classification and acceptance decisions are derived.
13.5 Classification policy
The scheme defines a classification policy that maps coverage report fields to grade labels. The classification policy is a deterministic, programmatic function — not a subjective judgment. The scheme publishes its classification policy in the deployment manifest.
The classification policy shall be expressed as deterministic rules over the coverage report fields. Example classification policies:
// Example: pharmaceutical supply chain scheme
classify(coverage) {
if (coverage.hard_checks != "pass") return "rejected";
if (!coverage.transparency_included) return "unverified";
if (!coverage.time_anchored) return "basic";
if (coverage.multi_log_quorum && coverage.dimension_count >= 2
&& coverage.independent_roots >= 1)
return "certified";
if (coverage.dimension_count >= 2 && coverage.independent_roots >= 1)
return "attested";
if (coverage.dimension_count >= 1 || coverage.independent_roots >= 1)
return "verified";
return "basic";
}
// Example: financial compliance scheme
classify(coverage) {
if (coverage.hard_checks != "pass") return "invalid";
if (coverage.dimensions_verified.length >= 4
&& coverage.independent_roots >= 2
&& coverage.multi_log_quorum)
return "tier-1";
if (coverage.dimensions_verified.length >= 2)
return "tier-2";
return "tier-3";
}
Each scheme defines its own labels, thresholds, and rules. The standard does not prescribe grade labels or classification thresholds. The classification policy shall be a pure function of the coverage report — for a given coverage report, the classification produces the same label for any verifier using the same scheme’s policy.
13.6 Acceptance policy
Each verifier defines an acceptance policy that maps the classification label to an accept or reject decision for a given context:
// Example acceptance policy
accept(grade, context) {
if (grade == "rejected" || grade == "invalid") return false;
if (context == "controlled_substance" && grade != "certified") return false;
if (context == "standard_import" && grade == "unverified") return false;
return true;
}
The acceptance policy is the verifier’s risk decision. The standard does not prescribe acceptance thresholds.
13.7 Time freshness window
A verifier shall apply a configurable time freshness window to time dimension attestations. The freshness window defines the maximum acceptable age of a time attestation relative to the verifier’s current time.
The verifier shall reject any time attestation whose timestamp falls outside the configured freshness window. Artifacts whose time attestations are stale but within a secondary grace period may be accepted at a downgraded classification label, as determined by the acceptance policy.
The freshness window parameter shall be declared in the verifier’s acceptance policy. The default freshness window is scheme-defined.
13.8 Offline verification
A verifier shall be able to verify artifacts offline using:
the trust anchor bundle;
cached CRLs within their validity or grace period (see 11.9);
cached transparency log tree heads and inclusion proofs;
embedded or hybrid chains carried with the artifact.
Offline verification produces the same classification label as online verification, except where freshness-dependent checks (e.g., time freshness window, CRL currency) cannot be satisfied.
13.9 Verification result structure
The verification pipeline produces a structured result containing the classification label, the set of valid verification paths, and — if hard_checks is fail — the specific failure reason(s). Typed failure reasons enable the verifier to distinguish operational conditions that require different responses.
The verification result shall contain:
classified_grade: the scheme-defined classification label.
paths: the set of valid verification paths found.
dimensional_coverage: the set of trust dimensions with verified attestations.
failures: if hard_checks is fail, a list of failure entries, each containing:
check: the name of the hard check that failed.
reason: one of the typed failure reasons listed below.
detail: implementation-specific diagnostic text.
downgrades: a list of soft-check non-passes (e.g., transparency missing, time anchor absent, cross-domain count below threshold), each containing the check name and the current value. This field is populated regardless of the assigned classification label.
The following typed failure reasons are defined. The defined failure reasons are listed in Table 104.
| Failure reason | Meaning |
|---|---|
| format_invalid | The artifact wrapper is malformed or cannot be parsed. |
| signature_invalid | A signature (primary or co-signature) failed cryptographic validation. |
| chain_broken | No valid path exists from the artifact to any root anchor in the trust anchor bundle. |
| scope_widened | The monotonic narrowing invariant was violated at a delegation link. |
| scope_condition_failed | A scope condition evaluated to false against the artifact content. |
| revoked | An authority on the verification path, or a state bound to the artifact, is revoked. |
| transparency_missing | A certificate or artifact is not provably included in a recognized transparency log (soft check failure; may downgrade rather than fail unless policy requires transparency). |
An implementation may define additional failure reasons. Extensions shall use the x- prefix to avoid collision with future standardized reasons.
13.10 Requirements
Verification pipeline has its formalized requirements class described in Table 105, Requirements class 8, with its requirements listed from Table 106, Requirement 77 to Table 113, Requirement 84.
| Identifier | /req/verification/pipeline-architecture |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | The verification pipeline shall apply an ordered sequence of checks classified as hard or soft, short-circuiting to the scheme’s rejected label on any hard check failure and accumulating soft check results into the coverage report. |
| Guidance | Hard checks are format validity, signature validity, chain integrity, scope narrowing, scope conditions, and revocation status. Soft checks are transparency inclusion, time anchor, cross-domain co-signatures, and multi-log attestation. |
| Identifier | /req/verification/hard-checks |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | The following checks shall be hard checks whose failure causes the pipeline to short-circuit to the scheme’s rejected label, covering format validity, signature validity, chain integrity, scope narrowing invariant, scope condition evaluation, and revocation status. |
| Guidance | Hard checks determine pass or fail of the pipeline. |
| Identifier | /req/verification/pathfinding |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | The verifier shall find one or more paths in the trust graph from each signature on the artifact to root anchors in the trust anchor bundle, validating signature and scope narrowing at every link, and shall collect all valid paths and their distinct roots for cross-domain diversity scoring. |
| Guidance | Multiple valid paths may exist. The coverage report may reflect the best path or require paths through multiple independent roots. |
| Identifier | /req/verification/coverage-report |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | The verification pipeline shall produce a coverage report containing objective verification facts including hard check status, transparency inclusion status, time anchor status, verified dimension list, dimension count, independent root count, and multi-log quorum status. |
| Guidance | The coverage report is a deterministic function of the artifact and the verifier’s verification state. Two conforming verifiers with the same state produce identical coverage reports. |
| Identifier | /req/verification/classification-policy |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | The scheme shall define a deterministic classification policy that maps coverage report fields to grade labels. The classification policy shall be a pure function of the coverage report, published in the deployment manifest. |
| Guidance | The standard does not prescribe grade labels or classification thresholds. Each scheme defines its own labels, thresholds, and rules appropriate to its domain. |
| Identifier | /req/verification/acceptance-policy |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | The verifier shall define an acceptance policy that maps the classification label to an accept or reject decision for a given decision context. |
| Guidance | The acceptance policy is the verifier’s risk decision. The standard does not prescribe acceptance thresholds. |
| Identifier | /req/verification/time-freshness-window |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | A verifier shall apply a configurable time freshness window to time dimension attestations and shall reject any time attestation whose timestamp falls outside the configured window. Artifacts whose time attestations are within a secondary grace period may be accepted at a downgraded classification label as determined by the acceptance policy. Timestamps shall be UTC representations per ISO 8601-1:2019; the verifier shall apply a clock-skew tolerance, and the default freshness window shall be declared in the deployment manifest. |
| Guidance | The freshness window parameter is declared in the verifier’s acceptance policy. The default freshness window is scheme-defined. |
| Identifier | /req/verification/offline-verification |
|---|---|
| Included in | Requirements class 8: Verification pipeline (/req/verification) |
| Statement | A verifier shall be able to verify artifacts offline using the trust anchor bundle, cached CRLs within validity or grace period, cached transparency tree heads and inclusion proofs, and embedded or hybrid chains. |
| Guidance | Offline verification produces the same classification label as online verification except where freshness-dependent checks cannot be satisfied. |
14 Key lifecycle
14.1 General
This clause specifies the lifecycle of cryptographic keys in the SIGNATIF framework: generation, encrypted storage, import and export, hardware security module interfaces, and certificate signing requests.
Key lifecycle requirements apply to all signing keys: root aggregate keys, threshold member shares, end certificate keys, and time keys. Key management follows established practice (ISO/IEC 11770, NIST SP 800-57pt1r5); this clause specifies the SIGNATIF-specific lifecycle duties and does not restate general key-management practice.
14.2 Key generation
Keys shall be generated using a cryptographically secure random number generator. The generation parameters shall conform to the specification of the chosen algorithm as registered in the scheme’s algorithm identifier registry.
Threshold key shares shall be generated using a threshold key generation protocol that ensures no individual member possesses the full signing key.
14.3 Encrypted storage
Private keys shall be stored encrypted at rest using an authenticated encryption algorithm with adequate security strength. The encryption key shall be derived from a passphrase using a password-based key derivation function resistant to brute-force attacks. The choice of specific algorithms is an implementation decision.
Private keys shall not be stored in plaintext under any circumstances. Export of private keys shall require explicit user action and shall produce encrypted output.
14.4 Import and export
Key import and export shall use a recognized, interoperable key encoding format. PKCS#8 for private keys, SubjectPublicKeyInfo for public keys, and X.509 for certificates are recognized encodings; additional encodings may be registered.
Imported keys shall be validated for format correctness and algorithm consistency before use.
14.5 Hardware security module interface
Keys may be stored and used within a hardware security module (HSM) accessed via PKCS#11 or an equivalent interface. When an HSM is used:
The private key shall never leave the HSM in plaintext.
Signing operations shall be performed within the HSM.
Session management shall use authenticated sessions with PIN or equivalent access control.
The HSM shall enforce access policies that prevent unauthorized key use.
14.6 Certificate signing requests
A certificate signing request (CSR) shall follow a recognized CSR format and shall include a proof-of-possession (PoP) signature demonstrating that the requester holds the private key corresponding to the public key in the request. PKCS#10 is a recognized format; additional formats may be registered.
The issuing trust authority shall verify the PoP before issuing an end certificate or delegation certificate.
14.7 Key rotation
Keys shall be rotated according to the authority’s key rotation policy. Rotation of threshold member shares shall preserve the aggregate key (see 9.3). Rotation of end certificate keys shall produce a new certificate under the same or narrower scope.
14.8 Requirements
Key lifecycle has its formalized requirements class described in Table 114, Requirements class 9, with its requirements listed from Table 115, Requirement 85 to Table 120, Requirement 90.
| Identifier | /req/key-lifecycle/key-generation |
|---|---|
| Included in | Requirements class 9: Key lifecycle (/req/key-lifecycle) |
| Statement | Keys shall be generated using a cryptographically secure random number generator with parameters conforming to the chosen algorithm specification. |
| Guidance | Threshold key shares shall be generated using a threshold key generation protocol ensuring no individual member possesses the full signing key. Random bit generation should follow ISO/IEC 18031:2025. |
| Identifier | /req/key-lifecycle/encrypted-storage |
|---|---|
| Included in | Requirements class 9: Key lifecycle (/req/key-lifecycle) |
| Statement | Private keys shall be stored encrypted at rest using an authenticated encryption algorithm meeting the minimum security parameters in Table 156, with the encryption key derived from a passphrase using a password-based key derivation function resistant to brute-force attacks. |
| Guidance | The choice of specific encryption and derivation algorithms is an implementation decision. Private keys shall not be stored in plaintext under any circumstances. EXAMPLE 1 AES-256-GCM is an example of a suitable authenticated encryption algorithm. EXAMPLE 2 PBKDF2, Argon2, and scrypt are examples of suitable key derivation functions. |
| Identifier | /req/key-lifecycle/import-export |
|---|---|
| Included in | Requirements class 9: Key lifecycle (/req/key-lifecycle) |
| Statement | Key import and export shall use a recognized, interoperable key encoding format. |
| Guidance | Imported keys shall be validated for format correctness and algorithm consistency before use. Additional encodings may be registered per Annex C. EXAMPLE 1 PKCS#8 for private keys, SubjectPublicKeyInfo for public keys, and X.509 for certificates are examples of recognized encodings. EXAMPLE 2 JOSE JWK and COSE key format are examples of alternative interoperable encodings. |
| Identifier | /req/key-lifecycle/hsm-interface |
|---|---|
| Included in | Requirements class 9: Key lifecycle (/req/key-lifecycle) |
| Statement | When an HSM is used, the private key shall never leave the HSM in plaintext, signing shall be performed within the HSM, and session management shall use authenticated sessions with PIN or equivalent access control. |
| Guidance | The HSM shall enforce access policies preventing unauthorized key use. An HSM evaluated under ISO/IEC 19790:2025 (methodology ISO/IEC 18045:2026) satisfies these requirements structurally; the OASIS PKCS #11 interface (PKCS #11 v3.0) is an example device interface. |
| Identifier | /req/key-lifecycle/csr-pop |
|---|---|
| Included in | Requirements class 9: Key lifecycle (/req/key-lifecycle) |
| Statement | A certificate signing request shall follow a recognized CSR format and shall include a proof-of-possession signature demonstrating the requester holds the corresponding private key. |
| Guidance | The issuing trust authority shall verify the proof-of-possession before issuing a certificate. Additional CSR formats may be registered per Annex C. EXAMPLE 1 PKCS#10 is an example of a recognized CSR format. EXAMPLE 2 The PKCS #10 certificate request syntax (PKCS #10 v1.7) is the reference format. The PKCS #10 certificate request syntax (PKCS #10 v1.7) is the reference format. |
| Identifier | /req/key-lifecycle/key-rotation |
|---|---|
| Included in | Requirements class 9: Key lifecycle (/req/key-lifecycle) |
| Statement | Keys shall be rotated according to the authority’s key rotation policy, with threshold member rotation preserving the aggregate key and end certificate key rotation producing a new certificate under the same or narrower scope. |
15 Delivery and discovery
15.1 General
This clause specifies how trusted artifacts and certificates are delivered to verifiers, and how delegation chains are discovered and resolved. Delivery mechanisms include compact encodings for non-connected devices, machine-readable public projections, and chain discovery strategies.
Delivery and discovery are distinct from verification: a verifier first obtains the artifact (delivery), then resolves its chain (discovery), then applies the verification pipeline (Clause 13).
15.2 Compact encoding (two-dimensional barcode)
For delivery to devices without network connectivity, a trusted artifact or its passport may be encoded as a two-dimensional barcode (e.g., QR code). The encoding shall:
be self-contained, carrying the artifact or passport data plus the minimum chain necessary for offline verification;
include error correction sufficient for the expected scanning environment;
carry a version identifier for encoding evolution.
The maximum data capacity of the barcode format constrains the artifact size. For larger artifacts, the barcode may carry a compact reference (e.g., a transparency log sequence number) that a connected verifier resolves.
15.3 Passport
A passport is the machine-readable public projection of an end certificate or trusted artifact, optimized for compact storage and rapid presentation. A passport shall:
carry the certificate or artifact identifier, key fingerprint, scope summary, and validity period;
be expressible in a deterministic, machine-readable format (e.g., JSON-LD or CBOR);
be verifiable against the same trust anchor bundle and transparency log as the underlying certificate or artifact.
A passport is a presentation format, not a separate trust object. The underlying certificate or artifact remains the authoritative source.
15.4 Chain discovery mechanisms
Chain discovery mechanisms are specified in 6.4. This clause specifies the delivery aspects:
Embedded chain delivery. The artifact carries the full chain inline. No additional network access is required for discovery.
Transparency-log reference delivery. The artifact carries references (transparency-log sequence numbers). The verifier fetches the referenced certificates from a transparency log or mirror on first encounter.
Hybrid delivery. The artifact carries the end certificate and immediate chain, with transparency-log references for the remaining chain.
15.5 Connected device delivery
For connected devices, artifacts and certificates may be delivered via network protocols. The delivery protocol shall:
authenticate the source (e.g., via TLS or equivalent);
provide integrity protection for the delivered data;
support caching of certificates and transparency log entries to minimize repeated network access.
NOTE The specific transport protocol is out of scope of this document (see Clause 1). Implementations may use any protocol that satisfies the above requirements.
15.6 Challenge-response
A verifier may challenge a device signer to produce a fresh trusted artifact bound to a nonce, proving that the signing key is live and the artifact was produced on demand.
A challenge-response exchange shall satisfy the following:
Nonce entropy. The nonce shall have at least 128 bits of entropy and shall be generated using a cryptographically secure random source.
Freshness window. The verifier shall apply a time freshness window (see 13.7) to the challenge-response. A response received outside the window shall be rejected.
Nonce binding. The device shall bind the nonce into the canonical payload of the response artifact, such that the signature covers the nonce.
Replay rejection. The verifier shall reject any response whose nonce does not match the challenge nonce, or whose timestamp falls outside the freshness window.
Single-use nonce. The verifier shall not accept two responses for the same challenge nonce.
15.7 Credential exchange
Delivery to a verifier is only half the movement of a credential: a credential must also reach its subject, and a verifier must be able to ask for one that is not yet in hand. A credential exchange is a two-turn protocol between a holder and a coordinator (an issuer about to issue, or a verifier requesting presentation) in which the holder asks and the coordinator responds. A credential exchange shall:
be initiated by the party that wants the credential — an issuer cannot push a credential to a subject that has not asked, and a verifier cannot obtain one the holder has not presented;
authenticate the holder by an identifier-control challenge: before issuing to, or accepting a presentation from, an identifier, the coordinator challenges the holder to sign a fresh nonce with the key behind that identifier, proving the credential lands on (or comes from) the party that controls it;
satisfy the nonce requirements of 15.6 for the identifier-control challenge (entropy, binding, single use).
NOTE The identifier-control challenge is the same construction as the device-signer challenge-response of 15.6, generalized from proving a device key is live to proving a holder controls an identifier. The two-turn shape (ask, then challenge, then deliver) applies to issuance (the subject collects its own credential) and to presentation (the holder answers a verifier’s request). Exchange state is a service concern: a conversation has state, and a coordinator that runs exchanges operates a stateful endpoint, which the deployment manifest shall declare.
15.8 Requirements
Delivery and discovery has its formalized requirements class described in Table 121, Requirements class 10, with its requirements listed from Table 122, Requirement 91 to Table 128, Requirement 97.
| Identifier | /req/delivery/barcode-encoding |
|---|---|
| Included in | Requirements class 10: Delivery and discovery (/req/delivery) |
| Statement | A trusted artifact or passport delivered as a two-dimensional barcode shall be self-contained, carry a version identifier, and include error correction sufficient for the expected scanning environment; artifacts exceeding the capacity of the barcode format shall fall back to the compact transparency-log reference encoding. |
| Guidance | The maximum data capacity of the barcode format constrains artifact size. For larger artifacts, the barcode may carry a compact reference resolvable by a connected verifier. |
| Identifier | /req/delivery/passport-format |
|---|---|
| Included in | Requirements class 10: Delivery and discovery (/req/delivery) |
| Statement | A passport shall carry the certificate or artifact identifier, key fingerprint, scope summary, and validity period, shall be expressible in a deterministic machine-readable format, shall be verifiable against the same trust anchor bundle and transparency log as the underlying object, and shall present a human-readable summary of the classification label and unresolved failures for non-specialist inspectors. |
| Guidance | A passport is a presentation format, not a separate trust object. Check characters per ISO/IEC 7064:2003 may protect the compact encoding. Check characters per ISO/IEC 7064:2003 may protect the compact encoding. |
| Identifier | /req/delivery/embedded-delivery |
|---|---|
| Included in | Requirements class 10: Delivery and discovery (/req/delivery) |
| Statement | An artifact delivered with an embedded chain shall carry the full delegation chain inline, requiring no additional network access for chain discovery. |
| Identifier | /req/delivery/log-reference-delivery |
|---|---|
| Included in | Requirements class 10: Delivery and discovery (/req/delivery) |
| Statement | An artifact delivered with transparency-log references shall carry sequence number pointers enabling the verifier to fetch referenced certificates from a transparency log or mirror on first encounter. |
| Identifier | /req/delivery/connected-delivery |
|---|---|
| Included in | Requirements class 10: Delivery and discovery (/req/delivery) |
| Statement | Delivery via network protocols shall authenticate the source, provide integrity protection, and support caching of certificates and transparency log entries. |
| Guidance | The specific transport protocol is out of scope of this document. |
| Identifier | /req/delivery/credential-exchange |
|---|---|
| Included in | Requirements class 10: Delivery and discovery (/req/delivery) |
| Statement | A credential exchange between a holder and a coordinator shall be holder-initiated, and shall authenticate the holder through an identifier-control challenge in which the holder signs a fresh nonce with the key behind the identifier the credential names, before the credential is issued to or accepted from that identifier. |
| Guidance | The nonce satisfies the challenge-response requirements (entropy, binding, single use). Applies to issuance (subject collects its credential) and to presentation (holder answers a verifier’s request). |
| Identifier | /req/delivery/challenge-response |
|---|---|
| Included in | Requirements class 10: Delivery and discovery (/req/delivery) |
| Statement | A challenge-response exchange shall use a nonce with at least 128 bits of entropy, bind the nonce into the canonical payload of the response artifact, and shall be subject to the time freshness window. The verifier shall reject any response whose nonce does not match the challenge or whose timestamp falls outside the freshness window, and shall not accept two responses for the same challenge nonce. |
| Guidance | Challenge-response proves that the signing key is live and the artifact was produced on demand. |
16 Ceremony records and transcripts
16.1 General
A ceremony record is a verifiable transcript of a threshold signing ceremony. It documents who participated, what was signed, the quorum parameters, and the signature produced. Ceremony records provide signing accountability and auditability for threshold signing operations.
This clause specifies the transcript format, signing requirements, persistence, and the audit algorithm.
16.2 Transcript format
A ceremony transcript shall be expressed in a deterministic, machine-readable format and shall contain:
Ceremony type. The type of ceremony (e.g., root creation, DTA issuance, member rotation, re-share, artifact signing).
Participants. The identities of the participating key holders, with their contribution proofs.
Quorum parameters. The (T, N) threshold parameters and the number of participants who contributed.
Payload. The canonical payload hash that was signed.
Signature. The resulting threshold signature under the authority’s aggregate key.
Timestamp. The time of the ceremony, anchored to a time key or external time source where possible.
16.3 Transcript signing
The ceremony transcript shall be signed by each participating member, attesting to their participation. The transcript shall also carry the aggregate threshold signature produced by the ceremony.
A transcript without all member signatures or without the aggregate signature is incomplete and shall not be accepted as evidence of a valid ceremony.
16.4 Persistence and retention
Ceremony transcripts shall be persisted to durable storage and retained for the validity period of the artifacts they produced. Retention shall exceed the maximum possible artifact lifetime, including any grace periods.
Transcripts shall be cross-referenced with the transparency log: the artifact or certificate produced by the ceremony shall appear in the log, and the transcript shall reference the corresponding log entry.
16.5 Audit algorithm
The ceremony audit algorithm verifies that a ceremony transcript is consistent and valid:
Verify each member’s participation signature.
Verify the aggregate threshold signature against the authority’s published aggregate key.
Confirm that at least T of N members participated.
Cross-reference the transcript’s payload with the transparency log entry for the produced artifact or certificate.
Confirm the timestamp is consistent with the transparency log entry.
16.6 Requirements
Ceremony records has its formalized requirements class described in Table 129, Requirements class 11, with its requirements listed from Table 130, Requirement 98 to Table 134, Requirement 102.
| Identifier | /req/ceremony |
|---|---|
| Target type | ceremony records |
| Conformance class | Conformance class A.11: Ceremony records conformance (/conf/ceremony) |
| Prerequisite | Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Description | Requirements on ceremony transcript format, signing, persistence, retention, and the audit algorithm. |
| Provisions | Requirement 98: Transcript contents (/req/ceremony/transcript-contents) Requirement 99: Transcript signing by participants (/req/ceremony/transcript-signing) Requirement 100: Transcript persistence and retention (/req/ceremony/transcript-persistence) Requirement 101: Transcript transparency log cross-reference (/req/ceremony/transcript-log-cross-reference) Requirement 102: Transcript audit algorithm (/req/ceremony/audit-algorithm) |
| Identifier | /req/ceremony/transcript-contents |
|---|---|
| Included in | Requirements class 11: Ceremony records (/req/ceremony) |
| Statement | A ceremony transcript shall contain the ceremony type, participant identities with contribution proofs, quorum parameters, the canonical payload hash signed, the resulting aggregate threshold signature, and a timestamp. |
| Identifier | /req/ceremony/transcript-signing |
|---|---|
| Included in | Requirements class 11: Ceremony records (/req/ceremony) |
| Statement | A ceremony transcript shall be signed by each participating member attesting their participation, and shall carry the aggregate threshold signature produced by the ceremony. |
| Guidance | A transcript without all member signatures or the aggregate signature is incomplete and shall not be accepted. |
| Identifier | /req/ceremony/transcript-persistence |
|---|---|
| Included in | Requirements class 11: Ceremony records (/req/ceremony) |
| Statement | Ceremony transcripts shall be persisted to durable storage and retained for the validity period of the artifacts they produced, exceeding the maximum possible artifact lifetime including grace periods. On dissolution of a trust authority, transcript custody shall transfer to a successor or escrow designated by the scheme’s governance. |
| Guidance | Transcript retention follows the scheme’s retention policy, which defines deletion and suppression criteria for personal data of key holders once the served period ends. |
| Identifier | /req/ceremony/transcript-log-cross-reference |
|---|---|
| Included in | Requirements class 11: Ceremony records (/req/ceremony) |
| Statement | A ceremony transcript shall be cross-referenced with the transparency log entry for the artifact or certificate produced by the ceremony. |
| Identifier | /req/ceremony/audit-algorithm |
|---|---|
| Included in | Requirements class 11: Ceremony records (/req/ceremony) |
| Statement | The ceremony audit algorithm shall verify each member participation signature, verify the aggregate threshold signature, confirm at least T of N members participated, cross-reference the payload with the transparency log entry, and confirm timestamp consistency. |
17 Deployment manifest
17.1 General
A deployment manifest is a declarative description of a SIGNATIF deployment’s topology, authorities, algorithms, and transparency endpoints. It enables a deployer to declare the structure of their trust infrastructure in a machine-checkable format, and enables verifiers to understand the deployment’s configuration. It is also the assembly point for scheme instantiation: a scheme maintains the registries of Annex C, defines its scope dimensions and classification policy (see Clause 5), and publishes the manifest specified in this clause.
This clause specifies the manifest format, required fields, validation rules, and versioning.
17.2 Manifest format
A deployment manifest shall be expressed in a declarative format (e.g., TOML, YAML, or JSON) and shall carry a manifest version identifier for evolution.
The manifest shall be signed by the root trust authority whose deployment it describes.
17.3 Manifest contents
A deployment manifest shall declare the following:
Topology type. The trust topology profile (hierarchical, federated, cross-recognized, or mesh) per Clause 5.
Authorities. The trust authorities in the deployment, each with its identifier, aggregate key or fingerprint, quorum parameters (if threshold), and parent reference.
Scope. The root scope and any delegation narrowing rules.
Algorithms. The signature algorithms recognized by the deployment (classical, post-quantum, or composite).
Transparency endpoints. The transparency logs and mirrors recognized by the deployment, with their endpoints and public keys.
Multi-log policy. If applicable, the M-of-K multi-log attestation parameters.
Classification policy. The scheme’s classification policy that maps coverage report fields to grade labels (see 13.5). The classification policy shall be a pure function of the coverage report fields.
Trust anchor references. References to the trust anchor bundle version(s) recognized by the deployment.
17.4 Validation rules
A deployment manifest shall satisfy the following validation rules:
All declared authorities shall form a valid trust graph — a DAG with no cycles.
Every delegation link shall satisfy the monotonic narrowing invariant on scope.
Quorum parameters shall be consistent: T shall not exceed N for any threshold authority.
Declared algorithms shall be recognized by this document’s algorithm registry.
Transparency endpoints shall be reachable and their public keys shall match their declared fingerprints.
The classification policy shall be deterministic — given the same coverage report fields, it shall produce the same grade label.
17.5 Manifest versioning
Manifest versions follow semantic compatibility rules. Major version changes indicate breaking structural changes. Minor version changes add fields without breaking existing parsers.
A deployment may carry multiple manifest versions simultaneously during migration. The most recent signed manifest is authoritative.
17.6 Requirements
Deployment manifest has its formalized requirements class described in Table 135, Requirements class 12, with its requirements listed from Table 136, Requirement 103 to Table 142, Requirement 109.
| Identifier | /req/manifest/manifest-format |
|---|---|
| Included in | Requirements class 12: Deployment manifest (/req/manifest) |
| Statement | A deployment manifest shall be expressed in a declarative format, carry a manifest version identifier, and be signed by the root trust authority whose deployment it describes. |
| Identifier | /req/manifest/manifest-topology |
|---|---|
| Included in | Requirements class 12: Deployment manifest (/req/manifest) |
| Statement | A deployment manifest shall declare the trust topology profile, the trust authorities with their identifiers, aggregate keys or fingerprints, quorum parameters, and parent references. |
| Guidance | Topology profiles are hierarchical, federated, cross-recognized, and mesh. |
| Identifier | /req/manifest/manifest-algorithms |
|---|---|
| Included in | Requirements class 12: Deployment manifest (/req/manifest) |
| Statement | A deployment manifest shall declare the signature algorithms recognized by the deployment from the framework’s algorithm registry. |
| Identifier | /req/manifest/manifest-transparency |
|---|---|
| Included in | Requirements class 12: Deployment manifest (/req/manifest) |
| Statement | A deployment manifest shall declare the recognized transparency logs and mirrors with their endpoints and public keys, and the multi-log attestation policy parameters if applicable. |
| Guidance | The manifest documents the jurisdictional scope of log operators and mirrors and the basis for any cross-border transfer of personal data. |
| Identifier | /req/manifest/manifest-validation-acyclic |
|---|---|
| Included in | Requirements class 12: Deployment manifest (/req/manifest) |
| Statement | A deployment manifest shall be validated to ensure all declared authorities form a valid trust graph with no cycles, and every delegation link satisfies the monotonic narrowing invariant. |
| Identifier | /req/manifest/manifest-validation-quorum |
|---|---|
| Included in | Requirements class 12: Deployment manifest (/req/manifest) |
| Statement | A deployment manifest shall be validated to ensure quorum parameters are consistent, with T not exceeding N for any threshold authority. |
| Identifier | /req/manifest/manifest-versioning |
|---|---|
| Included in | Requirements class 12: Deployment manifest (/req/manifest) |
| Statement | Manifest versions shall follow semantic compatibility rules, and the most recent signed manifest shall be authoritative for the deployment. |
18 Governance and mutual recognition
18.1 General
This clause specifies the governance requirements for root trust authorities and the trust topology profiles that a SIGNATIF deployment may adopt. Topology is declared in the deployment manifest (see Clause 17) and determines the structure of the trust graph (Figure 9).
18.2 Trust topology profiles
18.2.1 Hierarchical
A hierarchical topology is a strict tree with a single root trust authority. Every delegation chain is linear from root to end certificate. This is the simplest topology and is suitable for single-organization deployments.
The trust anchor bundle for a hierarchical deployment carries a single root anchor.
18.2.2 Federated
A federated topology has multiple independent root trust authorities. No single root controls all paths. federated trust authorities may span roots, creating cross-hierarchy edges.
The trust anchor bundle for a federated deployment carries multiple root anchors.
18.2.3 Cross-recognized
A cross-recognized topology consists of hierarchical deployments with explicit cross-recognition links between roots. Two or more roots mutually recognize each other’s authority, enabling artifacts from one hierarchy to be verified against another’s anchors.
Cross-recognition is established by mutual signing: each root signs the other’s root anchor, creating a cross-recognition edge in the trust graph.
18.2.4 Mesh
A mesh topology is a general directed acyclic graph with hierarchy-spanning federated trust authorities and arbitrary cross-domain co-signatures. This is the most general topology and supports the highest verification complexity.
Mesh topologies arise naturally when multiple independent organizations form federations and when artifacts carry cross-domain co-signatures.
18.3 Root trust authority governance
A root trust authority shall satisfy the following governance requirements:
Defined scope. The root shall publish its initial scope and delegation policy.
Transparency. All root-level operations (delegation, scope changes, key rotation) shall be recorded in a recognized transparency log.
Threshold or federation. The root shall operate under a threshold scheme or as a federated trust authority to prevent single-point compromise.
Information security management. The root shall maintain an information security management system (ISMS) or equivalent organizational assurance framework. ISO/IEC 27001, WebTrust for CAs, and ETSI EN 319 411 are recognized frameworks. The root shall undergo periodic independent security audits covering key management, ceremony procedures, personnel controls, and incident response. Audit attestations shall be published.
Auditability. The root shall maintain verifiable records of all governance decisions.
Anchor publication. The root’s aggregate key shall be published in a trust anchor bundle with a version and validity period.
A delegated trust authority that issues end certificates shall maintain an ISMS or equivalent organizational assurance framework and shall undergo periodic security audits. The depth and frequency of audits may be determined by the scheme’s governance policy, proportionate to the authority’s scope and risk profile.
18.4 Mutual recognition
Mutual recognition between two root trust authorities shall be expressed as a signed cross-recognition credential in which each root attests the other’s aggregate key and scope. The cross-recognition credential shall be recorded in both roots’ transparency logs.
Mutual recognition does not merge the hierarchies. Each root retains its own governance. The recognition enables verifiers holding both roots’ anchors to accept artifacts from either hierarchy.
18.5 Requirements
Governance and mutual recognition has its formalized requirements class described in Table 143, Requirements class 13, with its requirements listed from Table 144, Requirement 110 to Table 148, Requirement 114.
| Identifier | /req/governance |
|---|---|
| Target type | governance |
| Conformance class | Conformance class A.13: Governance conformance (/conf/governance) |
| Prerequisites | Requirements class 1: Architecture and trust model (/req/architecture) Requirements class 4: Threshold signing and federated trust authorities (/req/threshold-signing) |
| Description | Requirements on trust topology profiles, root trust authority governance, and mutual recognition. |
| Provisions | Requirement 110: Topology declaration in manifest (/req/governance/topology-declaration) Requirement 111: Root trust authority governance requirements (/req/governance/root-governance) Requirement 112: Issuing authority organizational assurance (/req/governance/issuing-authority-assurance) Requirement 113: Mutual recognition via signed credentials (/req/governance/mutual-recognition) Requirement 114: Topology conformance (/req/governance/topology-conformance) |
| Identifier | /req/governance/topology-declaration |
|---|---|
| Included in | Requirements class 13: Governance and mutual recognition (/req/governance) |
| Statement | A deployment shall declare its trust topology profile — hierarchical, federated, cross-recognized, or mesh — in the deployment manifest. |
| Guidance | The topology determines the structure of the trust graph. |
| Identifier | /req/governance/root-governance |
|---|---|
| Included in | Requirements class 13: Governance and mutual recognition (/req/governance) |
| Statement | A root trust authority shall publish its initial scope and delegation policy, record all root-level operations in a recognized transparency log, operate under threshold or federation, maintain verifiable governance records, publish its aggregate key in a versioned trust anchor bundle, and maintain an information security management system with periodic independent security audits. |
| Guidance | ISO/IEC 27001, WebTrust for CAs, and ETSI EN 319 411 are recognized ISMS frameworks. Audit attestations shall be published. Schemes processing personal data define a privacy policy covering lawful basis, information duties to attesting subjects, and the retention schedule. |
| Identifier | /req/governance/issuing-authority-assurance |
|---|---|
| Included in | Requirements class 13: Governance and mutual recognition (/req/governance) |
| Statement | A delegated trust authority that issues end certificates shall maintain an information security management system or equivalent organizational assurance framework and shall undergo periodic security audits proportionate to its scope and risk profile. |
| Guidance | The depth and frequency of audits may be determined by the scheme’s governance policy. |
| Identifier | /req/governance/mutual-recognition |
|---|---|
| Included in | Requirements class 13: Governance and mutual recognition (/req/governance) |
| Statement | Mutual recognition between two root trust authorities shall be expressed as signed cross-recognition credentials in which each root attests the other’s aggregate key and scope, recorded in both roots’ transparency logs. Recognition agreements shall state the mapping between the parties’ classification labels. |
| Guidance | Mutual recognition does not merge hierarchies; each root retains its own governance. |
| Identifier | /req/governance/topology-conformance |
|---|---|
| Included in | Requirements class 13: Governance and mutual recognition (/req/governance) |
| Statement | A deployment claiming a topology conformance profile shall satisfy the structural requirements of that topology as specified in the conformance class. |
| Guidance | Hierarchical requires a single root and linear chains. Federated requires multiple independent roots and a multi-root anchor bundle. Cross-recognized requires explicit cross-recognition links. Mesh requires a general DAG with hierarchy-spanning FTAs. |
19 Algorithm agility
19.1 General
Algorithm agility ensures that the SIGNATIF framework can adopt new cryptographic algorithms and deprecate old ones without breaking existing verifiers. This clause specifies the algorithm identifier registry, the deprecation process, and the migration governance model. Comparable algorithm transitions in existing infrastructures are treated in NIST SP 800-131Ar2.
19.2 Algorithm identifier registry
The algorithm identifier registry is maintained by the scheme (see Annex C). Each entry in the registry carries the algorithm identifier, the algorithm family (classical, post-quantum, or composite), the standard reference, and the status (active, deprecated, or retired).
The status field is governed by the deprecation process in 19.3. An implementation shall use algorithm identifiers from the registry. Unregistered identifiers shall not be accepted by conforming verifiers.
19.3 Deprecation process
When an algorithm is identified as weak or obsolete, it shall be deprecated through the following process:
Announcement. The deprecation shall be announced with a deprecation date and a retirement date.
Deprecation period. During the deprecation period, the algorithm remains usable but verifiers shall downgrade artifacts using the deprecated algorithm.
Retirement. After the retirement date, verifiers shall reject artifacts using the retired algorithm.
The deprecation and retirement dates shall allow sufficient time for migration to replacement algorithms.
19.4 Migration governance
Algorithm migration shall be governed by the deployment’s policy. The deployment manifest (see Clause 17) shall declare the active algorithms and the migration phase (classical-only, composite, or post-quantum-only).
Migration between phases shall follow a published schedule. During composite phase, new artifacts shall use composite signatures while existing classical-only artifacts remain verifiable. After migration to post-quantum-only, classical-only signatures shall be rejected.
19.5 Requirements
Algorithm agility has its formalized requirements class described in Table 149, Requirements class 14, with its requirements listed from Table 150, Requirement 115 to Table 155, Requirement 120.
| Identifier | /req/algorithm-agility |
|---|---|
| Target type | algorithm agility |
| Conformance class | Conformance class A.14: Algorithm agility conformance (/conf/algorithm-agility) |
| Prerequisite | Requirements class 3: Cryptographic algorithms (/req/algorithms) |
| Description | Requirements on the algorithm identifier registry, deprecation process, and migration governance. |
| Provisions | Requirement 115: Algorithm identifier registry (/req/algorithm-agility/algorithm-registry) Requirement 116: Algorithm deprecation process (/req/algorithm-agility/deprecation-process) Requirement 117: Migration phase declaration (/req/algorithm-agility/migration-declaration) Requirement 118: Archive validation (/req/algorithm-agility/archive-validation) Requirement 119: Circulation migration path (/req/algorithm-agility/reissuance-path) Requirement 120: Composite phase backward compatibility (/req/algorithm-agility/composite-backward-compatibility) |
| Identifier | /req/algorithm-agility/algorithm-registry |
|---|---|
| Included in | Requirements class 14: Algorithm agility (/req/algorithm-agility) |
| Statement | The framework shall maintain an algorithm identifier registry listing recognized algorithms with their names, standard references, parameter sets, and status (active, deprecated, or retired). |
| Guidance | Unregistered identifiers shall not be accepted by conforming verifiers. |
| Identifier | /req/algorithm-agility/deprecation-process |
|---|---|
| Included in | Requirements class 14: Algorithm agility (/req/algorithm-agility) |
| Statement | Algorithm deprecation shall follow a published process with announcement, deprecation period with classification downgrade, and retirement with rejection, allowing sufficient time for migration. |
| Guidance | Deprecated algorithms produce a coverage report downgrade during the deprecation period. Retired algorithms are rejected after the retirement date. |
| Identifier | /req/algorithm-agility/migration-declaration |
|---|---|
| Included in | Requirements class 14: Algorithm agility (/req/algorithm-agility) |
| Statement | A deployment shall declare its active algorithms and migration phase — classical-only, composite, or post-quantum-only — in the deployment manifest. |
| Guidance | Migration between phases shall follow a published schedule. |
| Identifier | /req/algorithm-agility/archive-validation |
|---|---|
| Included in | Requirements class 14: Algorithm agility (/req/algorithm-agility) |
| Statement | An artifact whose signatures were valid under an algorithm retired after issuance, evidenced by contemporaneous timestamps and transparency inclusion proofs, shall remain verifiable as a historical record under an archive classification label defined by the scheme. |
| Guidance | Archive validation does not restore acceptance for current transactions; it preserves evidential value for retention and audit regimes. |
| Identifier | /req/algorithm-agility/reissuance-path |
|---|---|
| Included in | Requirements class 14: Algorithm agility (/req/algorithm-agility) |
| Statement | The deprecation process shall provide a migration path for artifacts still in circulation — re-issuance, re-signing, or archival classification — before retirement takes effect. |
| Guidance | The path taken is a scheme policy published with the deprecation schedule. |
| Identifier | /req/algorithm-agility/composite-backward-compatibility |
|---|---|
| Included in | Requirements class 14: Algorithm agility (/req/algorithm-agility) |
| Statement | During the composite migration phase, new artifacts shall use composite signatures while existing classical-only artifacts remain verifiable. |
| Guidance | After migration to post-quantum-only, classical-only signatures shall be rejected. |
20 Security considerations
20.1 General
This clause describes security threats relevant to the SIGNATIF framework and the mitigations specified in the normative clauses. The threats are organized by attack surface. For each threat, the relevant normative requirements are identified.
The security of the SIGNATIF framework depends on the correctness of the underlying cryptographic algorithms, the integrity of the trust anchor bundle, the append-only property of transparency logs, and the threshold properties of ceremony protocols. Compromise of any of these foundations undermines the guarantees of the framework.
20.2 Threat model
The threat model assumes the following attacker capabilities:
Network control. The attacker controls the network between the verifier and all transparency logs, mirrors, and issuing authorities, and may delay, replay, or inject messages.
Single-key compromise. The attacker may compromise any single signing key that is not protected by threshold.
Single-authority compromise. The attacker may compromise a single trust authority that operates under a threshold scheme, provided the compromise does not reach the quorum threshold T.
Log operator coercion. The attacker may coerce a single transparency log operator to present inconsistent views to different verifiers (split-view attack).
The threat model excludes the following:
compromise of a quorum of threshold members (T or more);
compromise of two or more independent transparency log operators;
break of the underlying cryptographic primitives (hash collisions, signature forgery);
compromise of the verifier’s local trust anchor bundle storage.
20.3 Transparency log attacks
20.3.1 Split-view attack
A transparency log operator may attempt to present different tree heads to different verifiers, enabling the issuance of artifacts visible to some verifiers but not others.
The mitigation is gossip (see 12.6): verifiers and mirrors cross-check tree head fingerprints. A verifier that detects a tree head not observed by the gossip quorum rejects inclusion proofs against that tree head.
20.3.2 Log omission attack
A log operator may attempt to omit an artifact from the log while claiming it was included.
The mitigation is the inclusion proof (see 12.4): the verifier recomputes the Merkle root from the leaf and audit path and compares it to the signed tree head. A log operator cannot forge an inclusion proof without producing a hash collision.
20.3.3 Stale tree head attack
An attacker may present an old tree head that predates the inclusion of a revoked certificate, causing the verifier to accept an artifact as logged when it is not in the current log.
The mitigation is the gossip quorum and the external time anchoring of tree heads (see 12.5). The verifier confirms that the tree head is current (observed by the gossip quorum) and that its external time anchor is within the freshness window.
20.3.4 Log operator key compromise
An attacker who obtains the log operator’s signing key can sign fraudulent tree heads with valid signatures, potentially enabling split-view attacks or the injection of forged entries.
The mitigation is layered:
Multi-log attestation. Requiring inclusion in M-of-K independent logs (see 12.7) ensures that compromise of a single log operator key does not undermine artifact trustworthiness.
Gossip-based detection. A fraudulent tree head signed with a compromised key is detected when mirrors and verifiers compare their views via gossip (see 12.6).
Operator key protection. The log operator’s signing key shall be protected using threshold signing or hardware-backed storage, reducing the risk of single-party compromise.
Key rotation transparency. Log operator key rotations shall be recorded in the log itself, enabling verifiers to audit the history of key changes.
20.4 Threshold signing attacks
20.4.1 Sub-quorum compromise
An attacker may compromise fewer than T threshold members and attempt to produce a valid signature.
The mitigation is the ceremony protocol threshold property (see Clause 9): fewer than T members cannot produce a valid signature under the aggregate key. This property shall hold for every conforming ceremony protocol.
20.4.2 Aggregate key continuity attack
An attacker may attempt to exploit a member rotation event to change the aggregate key and invalidate existing delegations.
The mitigation is the aggregate key continuity requirement (see 9.3): member rotation preserves the aggregate key. The attacker cannot force an aggregate key change through member rotation.
20.4.3 Ceremony record forgery
An attacker may forge a ceremony record to claim a signing event occurred with different participants or parameters.
The mitigation is the ceremony record signing requirement (see 16.3): each participant signs the transcript, and the aggregate threshold signature is recorded. Forgery requires compromising the quorum.
20.5 Scope attacks
20.5.1 Scope widening attack
An attacker may modify a delegation certificate to widen the scope beyond what the parent authorized, enabling the issuance of artifacts outside the authorized boundary.
The mitigation is the monotonic narrowing invariant (see 10.3): the verifier checks at every chain link that the child scope is a subset of the parent scope on every dimension. Widening causes hard rejection. The scope is carried in the signed certificate extension, so modification invalidates the signature.
20.5.2 Scope condition bypass
An attacker may produce an artifact whose content does not satisfy the signing key’s scope conditions but claim it does.
The mitigation is the scope condition evaluation requirement (see 10.4): the verifier evaluates all scope conditions at verification time. An artifact failing any condition is rejected regardless of signature validity. The evaluation context is fully determined by the artifact and its chain, ensuring deterministic verification.
20.6 Time anchoring attacks
20.6.1 Backdating attack
An attacker may attempt to backdate an artifact by manipulating the time dimension attestation.
The mitigation is the external time anchoring requirement (see 12.5 and 7.9.3): the time dimension attestation is anchored to an external, irrefutable time source. Backdating requires compromising the external time source or re-mining the anchor (e.g., re-computing proof-of-work).
20.6.2 Timestamp freshness attack
An attacker may present an old timestamp as current.
The mitigation is the verifier’s time freshness window policy (see 13.7): the verifier rejects time anchors outside the freshness window specified by its policy.
20.7 Trust anchor bundle attacks
20.7.1 Bundle poisoning
An attacker may substitute a malicious root anchor in the verifier’s trust anchor bundle.
The mitigation is the trust anchor bundle self-containment and distributability requirements (see 6.5): the bundle is deterministic and distributable via out-of-band channels with published fingerprints. The verifier confirms the bundle fingerprint against multiple independent sources before use.
20.7.2 Stale bundle attack
An attacker may cause the verifier to use an outdated bundle that does not include a recently added root or includes a revoked root.
The mitigation is the bundle versioning requirement (see 6.5): the bundle carries a version identifier and validity period, and bundle updates are transparency-logged. The verifier checks the bundle version against the transparency log.
20.8 Algorithm migration attacks
20.8.1 Downgrade attack
During post-quantum migration, an attacker may attempt to force the use of a weaker algorithm (classical-only when composite or post-quantum is available).
The mitigation is the algorithm agility framework (see Clause 19): algorithm identifiers are explicit in the signature wrapper, and the deployment manifest declares the active migration phase. The verifier rejects algorithms below the deployment’s declared phase.
20.8.2 Algorithm deprecation exploitation
An attacker may exploit the deprecation period to use a known-weak algorithm.
The mitigation is the deprecation process (see 19.3): deprecated algorithms produce a classification downgrade during the deprecation period and are rejected after retirement. The deprecation schedule is published in advance.
20.9 Denial of service
20.9.1 CRL flood
An attacker may flood the verifier with CRL update requests, causing cache exhaustion or processing delays.
The mitigation is the offline grace period policy (see 11.9): the verifier applies a configurable CRL grace period and does not require real-time CRL updates. Stale CRLs within the grace period are accepted with a classification downgrade.
20.9.2 Transparency log flood
An attacker may submit a large number of spurious entries to a transparency log, inflating the log size and slowing inclusion proof verification.
The mitigation is implementation-specific (rate limiting, proof size optimization) and is out of scope of this document. However, the framework does not require the verifier to process the entire log; the verifier needs only the specific inclusion proofs for the artifacts it verifies.
20.10 Privacy considerations
SIGNATIF artifacts may carry dimension attestations that reveal information about the signer, the location, the environmental conditions, and the device identity. Implementers should consider the privacy implications of including these attestations:
Location attestations reveal the geographic position of the signing event. Implementers should assess whether location precision is necessary or whether coarser granularity suffices.
Person attestations reveal the identity of the human operator. Implementers should consider whether operator pseudonyms suffice.
Device identity attestations reveal the specific device serial number. Implementers should assess the correlation risk across multiple artifacts from the same device.
Transparency log entries are publicly visible. Artifacts logged in a transparency log are discoverable by any party with access to the log. Implementers should assess whether the artifact content itself is sensitive.
NOTE Transparency logs record artifact existence, not artifact content. To minimize personal data exposure, deployments should log only the artifact hash and metadata (dimensions present, classification label at issuance time), not the full payload. Full artifact content distribution is a separate concern from transparency logging. The framework does not mandate any particular privacy-preserving technique; the normative anchors are the pseudonymous signer identification of the artifact format clause and the log content minimization of the transparency clause. Profiles of this document may specify privacy enhancements (e.g., zero-knowledge attestations, selective disclosure) appropriate to their domain.
20.11 Rogue-key attack mitigation
In threshold signature schemes, a malicious member may register a public key crafted as a function of honest members’ keys such that the aggregate key equals the attacker’s own solo key. This rogue-key attack defeats the threshold property.
Each member of a threshold authority shall demonstrate possession of the private key corresponding to their contributed public share during the threshold key generation ceremony. The aggregate key computation shall incorporate all member public keys in a manner that is secure against rogue-key attacks (e.g., coefficient-based key aggregation or PoP-verified aggregation).
A threshold authority that does not enforce member proof-of-possession is non-conforming.
20.12 Transparency log consistency proofs
Inclusion proofs demonstrate that a specific entry is in a tree at a given size. Consistency proofs demonstrate that one tree head is a prefix of a later tree head — i.e., that the log has not removed or rewritten history.
A transparency log shall support consistency proofs. A consistency proof shall consist of the minimal set of intermediate hashes allowing a verifier to confirm that tree size m is a prefix of tree size n (where m < n) without downloading the entire log.
A mirror shall validate the consistency proof between each consecutive pair of tree heads and shall reject any tree head that fails the consistency check. A verifier may request a consistency proof between any two tree heads it has observed to confirm append-only behaviour.
20.13 Co-signature replay protection
Each co-signature shall bind not only to the canonical payload hash but also to a unique artifact identifier. The artifact identifier may be a transparency log sequence number, a deployment-assigned nonce embedded in the canonical payload, or a freshly generated random value included in the signed content.
The verifier shall reject any co-signature whose artifact identifier does not match the artifact being verified. Reuse of a co-signature across artifacts constitutes a hard verification failure.
For living artifacts (artifacts that accumulate dimension attestations over time), each revision of the co-signature set shall produce a new transparency log entry binding the current full co-signature set to the canonical payload. The accumulation window shall be bounded by the artifact’s validity period.
20.14 Canonicalization and signature wrapping attacks
A conforming signature wrapper shall ensure that the byte range covered by the cryptographic signature is exactly the byte range processed by the verifier for all downstream checks, including scope evaluation, classification, and revocation binding.
The verifier shall reject any artifact in which the signed content and the processed content are not provably identical. Unsigned fields shall not influence verification outcomes.
For format profiles using XML-based serialization, the signed and verified node sets shall be identical (defending against XML Signature Wrapping attacks). For JSON-based and CBOR-based profiles, the signed and decoded payload shall be the sole input to downstream processing.
20.15 Forward and backward security
Upon member removal or re-share, the departing member’s share shall be cryptographically destroyed in a verifiable manner. The ceremony record shall attest to share destruction.
A threshold authority shall maintain an epoch counter. Each signature shall carry its epoch. Verifiers shall reject signatures from epochs known to be compromised.
Threshold authorities with long-term security requirements (artifact validity exceeding 10 years) should employ a forward-secure threshold signature scheme, in which compromise of current shares does not enable forgery of signatures from prior epochs.
20.16 Minimum security parameters
Conforming implementations shall use algorithms and parameters providing a minimum security strength of 128 bits. For artifacts with long-term security requirements (validity exceeding 10 years), a minimum of 192 bits is recommended.
The following minimum parameters apply. The parameters are given in Table 156.
| Algorithm type | Minimum parameters |
|---|---|
| Elliptic curve signatures | Minimum 256-bit curve (e.g., P-256, Ed25519) |
| Post-quantum signatures | Minimum NIST PQ Level 2 (e.g., ML-DSA-44) |
| Hash functions | Minimum SHA-256 or equivalent; SHA-1 and MD5 are prohibited |
| Symmetric encryption (at rest) | Minimum 128-bit key (e.g., AES-128); 256-bit recommended |
| Password-based key derivation | Minimum 600,000 iterations (PBKDF2-HMAC-SHA256) or equivalent work factor; memory-hard KDFs (e.g., Argon2id) preferred |
Implementations shall not generate or accept keys, signatures, or hashes below these minimums. Random number generators used for key generation and nonce production shall conform to a recognized standard (e.g., NIST SP 800-90A or ISO/IEC 18031).
20.17 Side-channel resistance
Implementations of threshold signing ceremonies shall employ constant-time arithmetic for all operations involving secret shares or partial signatures. Implementations shall document their side-channel countermeasures.
Device signers subject to physical access shall employ hardware-level protections (e.g., secure elements conforming to ISO/IEC 19790 at Security Level 3 or higher) for key storage and signing operations.
Ceremony protocols shall specify abort procedures that prevent a malicious member from extracting share material through malformed contribution attacks. Nonce commitment (commit-then-reveal) shall be used in partial signature protocols to prevent nonce bias attacks.
20.18 Sybil and eclipse attacks
The trust anchor bundle policy shall define criteria for root inclusion that prevent Sybil-based classification inflation. Roots shall demonstrate organizational independence (distinct legal entities, distinct governance, distinct operational infrastructure) before inclusion. The cross-domain diversity metric counts only roots whose independence is attested by the bundle policy.
Mirror discovery shall use diverse, independent channels. The verifier shall confirm that gossip sources span at least two distinct network paths. Deployments in high-risk environments should supplement gossip with out-of-band log verification (e.g., published fingerprint lists distributed via physical media).
The threat model explicitly acknowledges that a network-controlling attacker who eclipses the verifier from all honest mirrors can present a fabricated transparency view. This risk is mitigated by gossip diversity but cannot be fully eliminated without out-of-band verification channels.
20.19 Ceremony protocol robustness
A conforming ceremony protocol shall specify:
Identifiable abort. If the ceremony aborts, the protocol shall identify which member(s) caused the abort, enabling accountability.
Nonce commitment. Partial signature protocols shall use nonce commitment to prevent nonce bias attacks by malicious members.
Censorship resistance. The authority shall document its policy for handling member non-participation, including thresholds for member removal for sustained non-participation.
20.20 Disaster recovery
Root trust authorities shall document a disaster recovery plan addressing:
escrow of threshold shares under independent custodians;
procedures for root key reconstruction in the event of partial member loss;
transition procedures for migrating to a successor root authority, including re-anchoring of the trust anchor bundle;
procedures for post-dissolution revocation of artifacts discovered to be vulnerable.
20.21 Long-term security and algorithm degradation
Artifacts with validity periods exceeding 20 years face the risk that their signing algorithm may be cryptographically broken during the artifact’s lifetime. Conforming deployments shall specify a maximum artifact validity period per algorithm, after which re-signing with a current algorithm is required.
For artifacts with indeterminate validity, the deployment shall specify a re-attestation cadence. The algorithm agility framework’s deprecation process (see 19.3) shall include provision for mandatory re-signing of long-lived artifacts before algorithm retirement.
20.22 Key escrow and lawful intercept
The SIGNATIF framework does not provide a key escrow or lawful intercept capability. Threshold schemes are designed so that no single party can produce signatures, and the aggregate key is not reconstructable from individual shares. Deployments in jurisdictions requiring key escrow shall document how their SIGNATIF conformance interacts with applicable legal requirements.
The framework’s trust repudiation mechanisms (revocation, scope condition withdrawal) operate on artifact validity, not on key recovery, and do not provide a decryption or signature-forcing capability.
20.23 Alignment with ISO/IEC security standards
Organizations operating SIGNATIF trust authorities should maintain an information security management system conforming to ISO/IEC 27001:2022, with SIGNATIF-specific risks (key compromise, ceremony disruption, transparency log integrity, scope violation) documented in the risk assessment.
Threshold key shares and root aggregate key material should be stored and operated within cryptographic modules conforming to ISO/IEC 19790 at Security Level 3 or higher. Key establishment, transport, and agreement should conform to the applicable mechanisms in ISO/IEC 11770.
The composite signature model defined in this document is compatible with the digital signature framework of ISO/IEC 14888. A composite signature is equivalent to the joint verification of multiple digital signatures over the same message.
Annex A
(normative)
Conformance test suite
A.1 General
This annex provides the conformance classes intended to verify that an implementation conforms to the requirements specified in this document. Each conformance class targets a requirements class defined in the normative clauses.
Conformance classes are rendered from structured data using the conformance class template. Each conformance class lists its conformance tests, with each test targeting one or more requirements.
A.2 Architecture and trust model
Architecture and trust model conformance has its formalized conformance class described in Table A.1, Conformance class A.1, with its conformance tests listed from Table A.2, Conformance test A.1 to Table A.12, Conformance test A.11.
| Identifier | /conf/architecture/four-level-model |
|---|---|
| Requirement | Requirement 1: Four-level delegation model (/req/architecture/four-level-model) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Validation |
| Test purpose | Verify that the implementation implements the four-level delegation model. |
| Test method | Inspect the implementation to confirm that signing authority flows from a root trust authority through delegated trust authorities to end certificates that authorize keys to produce trusted artifacts. |
| Guidance |
|
| Identifier | /conf/architecture/delegation-certificate |
|---|---|
| Requirement | Requirement 2: Delegation certificate binding (/req/architecture/delegation-certificate) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Validation |
| Test purpose | Verify that delegations are expressed as signed credentials binding the required fields. |
| Test method | Inspect delegation certificate format and verify it carries the child’s aggregate key, quorum parameters (if threshold), narrowed scope, and ceremony protocol reference (if applicable). Verify the certificate is signed by the parent. |
| Guidance |
|
| Identifier | /conf/architecture/delegation-scope-narrowing |
|---|---|
| Requirement | Requirement 3: Scope narrowing in delegation (/req/architecture/delegation-scope-narrowing) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Conformance |
| Test purpose | Verify that scope narrowing is enforced at every delegation link. |
| Test method | Construct test delegations with valid (narrowing) and invalid (widening) scope changes. Verify the verifier accepts valid narrowing and rejects widening on any dimension. |
| Guidance |
|
| Identifier | /conf/architecture/end-certificate-contents |
|---|---|
| Requirement | Requirement 4: End certificate contents (/req/architecture/end-certificate-contents) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Validation |
| Test purpose | Verify that end certificates carry the required fields. |
| Test method | Inspect end certificate format and verify it carries the authorized key or fingerprint, scope, scope conditions, and issuing chain reference. Verify the certificate does not delegate authority further. |
| Guidance |
|
| Identifier | /conf/architecture/trust-graph-pathfinding |
|---|---|
| Requirement | Requirement 5: Trust graph path discoverability (/req/architecture/trust-graph-pathfinding) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Conformance |
| Test purpose | Verify the verifier can find paths from artifact to root anchor in the trust graph. |
| Test method | Construct a trust graph with multiple paths (threshold memberships, federated authorities, cross-domain co-signatures). Verify the verifier finds valid paths, validates signatures and scope narrowing at every link, and rejects paths with broken signatures or scope violations. |
| Guidance |
|
| Identifier | /conf/architecture/path-transparency-inclusion |
|---|---|
| Requirement | Requirement 6: Transparency inclusion on path (/req/architecture/path-transparency-inclusion) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Conformance |
| Test purpose | Verify transparency log inclusion is confirmed for every certificate on a verification path. |
| Test method | Construct an artifact whose chain includes certificates with and without transparency log inclusion proofs. Verify the verifier downgrades or rejects artifacts with un-logged certificates. |
| Identifier | /conf/architecture/path-revocation-checking |
|---|---|
| Requirement | Requirement 7: Revocation checking on path (/req/architecture/path-revocation-checking) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Conformance |
| Test purpose | Verify revocation status is checked for every authority on a path. |
| Test method | Construct an artifact whose chain includes a revoked authority. Verify the verifier detects the revocation and propagates it to the bound artifact. |
| Identifier | /conf/architecture/chain-discovery |
|---|---|
| Requirement | Requirement 8: Chain discovery support (/req/architecture/chain-discovery) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Conformance |
| Test purpose | Verify the verifier supports at least one chain discovery strategy. |
| Test method | Test the verifier with artifacts using embedded chains, transparency-log references, and hybrid strategies. Verify the verifier can reconstruct the full chain for at least one strategy. |
| Guidance |
|
| Identifier | /conf/architecture/anchor-bundle-self-contained |
|---|---|
| Requirement | Requirement 9: Trust anchor bundle self-containment (/req/architecture/anchor-bundle-self-contained) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Validation |
| Test purpose | Verify the trust anchor bundle is self-contained for offline verification. |
| Test method | Inspect the bundle format and verify it contains root aggregate keys or fingerprints plus validation metadata. Test offline verification with an embedded-chain artifact and confirm no network access is required. |
| Identifier | /conf/architecture/anchor-bundle-versioning |
|---|---|
| Requirement | Requirement 10: Trust anchor bundle versioning (/req/architecture/anchor-bundle-versioning) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Validation |
| Test purpose | Verify the trust anchor bundle is versioned and updates are logged. |
| Test method | Inspect the bundle to confirm it carries a version identifier and validity period. Verify bundle updates are recorded in a transparency log. |
| Identifier | /conf/architecture/anchor-bundle-distributable |
|---|---|
| Requirement | Requirement 11: Trust anchor bundle distributability (/req/architecture/anchor-bundle-distributable) |
| Included in | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) |
| Test type | Validation |
| Test purpose | Verify the trust anchor bundle is expressible in a deterministic distributable format. |
| Test method | Serialize the bundle and verify the output is deterministic (same input produces identical bytes). Verify the format is suitable for out-of-band distribution. |
A.3 Artifact format and signature binding
Artifact format conformance has its formalized conformance class described in Table A.13, Conformance class A.2, with its conformance tests listed from Table A.14, Conformance test A.12 to Table A.33, Conformance test A.31.
| Identifier | /conf/artifact-format/canonical-binding |
|---|---|
| Requirement | Requirement 12: Canonical representation binding (/req/artifact-format/canonical-binding) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify the signature binds to a deterministic canonical payload. |
| Test method | Produce multiple serializations of the same logical payload. Canonicalize each and verify the canonical bytes are identical. Verify the signature validates against the canonical bytes. |
| Identifier | /conf/artifact-format/algorithm-identification |
|---|---|
| Requirement | Requirement 13: Algorithm identification (/req/artifact-format/algorithm-identification) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Validation |
| Test purpose | Verify the wrapper explicitly identifies the signing algorithm and parameters. |
| Test method | Inspect signature wrappers and verify the algorithm and parameters are explicitly carried. Verify verifiers can unambiguously determine the validation method. |
| Identifier | /conf/artifact-format/signer-identification |
|---|---|
| Requirement | Requirement 14: Signer identification (/req/artifact-format/signer-identification) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Validation |
| Test purpose | Verify the wrapper references or embeds the signer’s key or end certificate. |
| Test method | Inspect signature wrappers and verify the signer identity is present. Verify the verifier can locate the key and delegation chain from the wrapper. |
| Identifier | /conf/artifact-format/chain-availability |
|---|---|
| Requirement | Requirement 15: Chain availability (/req/artifact-format/chain-availability) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify the wrapper carries or references the full chain to root. |
| Test method | Test artifacts with embedded, referenced, and hybrid chain strategies. Verify the verifier can reconstruct the full chain for each conforming strategy. |
| Identifier | /conf/artifact-format/self-description |
|---|---|
| Requirement | Requirement 16: Self-description (/req/artifact-format/self-description) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify the wrapper is self-describing. |
| Test method | Provide a verifier with only the wrapper and the trust anchor bundle. Verify all inputs needed for validation are derivable without external convention. |
| Identifier | /conf/artifact-format/canonical-determinism |
|---|---|
| Requirement | Requirement 17: Canonical payload determinism (/req/artifact-format/canonical-determinism) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify canonicalization is deterministic. |
| Test method | Canonicalize the same logical payload using two independent implementations. Verify the canonical bytes are identical. Repeat with different serializations of the same logical content. |
| Identifier | /conf/artifact-format/format-profile-satisfaction |
|---|---|
| Requirement | Requirement 18: Format profile satisfaction (/req/artifact-format/format-profile-satisfaction) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify implementations claiming a format profile satisfy the five binding requirements. |
| Test method | For each claimed format profile, verify the five binding requirements are met in addition to the profile-specific format requirements. Test with xmldsig, jws, and cose profiles. |
| Identifier | /conf/artifact-format/version-compatibility |
|---|---|
| Requirement | Requirement 19: Version compatibility rules (/req/artifact-format/version-compatibility) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify semantic versioning rules are followed. |
| Test method | Present artifacts with major version exceeding the verifier’s maximum. Verify rejection. Present artifacts with minor version containing unknown fields. Verify acceptance with unknown fields ignored. |
| Identifier | /conf/artifact-format/cosignature-block |
|---|---|
| Requirement | Requirement 20: Co-signature block contents (/req/artifact-format/cosignature-block) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Validation |
| Test purpose | Verify co-signature blocks carry the required fields. |
| Test method | Inspect co-signature blocks and verify each contains signer identity, chain reference, algorithm and parameters, dimension tag, and signature. |
| Identifier | /conf/artifact-format/cosignature-independent-verification |
|---|---|
| Requirement | Requirement 21: Co-signature independent verification (/req/artifact-format/cosignature-independent-verification) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify co-signatures are independently verifiable. |
| Test method | Construct an artifact with multiple co-signatures from different chains. Verify each co-signature validates independently against its own root. Verify removing one co-signature does not affect the cryptographic validity of others. |
| Identifier | /conf/artifact-format/cosignature-canonical-binding |
|---|---|
| Requirement | Requirement 22: Co-signature canonical payload binding (/req/artifact-format/cosignature-canonical-binding) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify all co-signatures attest the same canonical payload. |
| Test method | Construct an artifact with co-signatures. Verify each co-signature validates against the same canonical payload hash. Verify partial attestation is rejected. |
| Identifier | /conf/artifact-format/format-profile-cosignature-encoding |
|---|---|
| Requirement | Requirement 23: Format profile co-signature encoding obligation (/req/artifact-format/format-profile-cosignature-encoding) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify format profiles define co-signature block encoding. |
| Test method | For each registered format profile, inspect the profile specification. Verify it defines encoding of co-signature blocks, dimension tags, and chain references. Verify that a profile without co-signature encoding does not claim multi-dimensional conformance. |
| Identifier | /conf/artifact-format/cross-domain-no-cross-recognition |
|---|---|
| Requirement | Requirement 24: Cross-domain co-signature without root cross-recognition (/req/artifact-format/cross-domain-no-cross-recognition) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify cross-domain co-signatures work without root cross-certification. |
| Test method | Construct an artifact with co-signatures from two independent roots that have not cross-certified. Verify the verifier validates both co-signatures using anchors from both roots in the trust anchor bundle. |
| Identifier | /conf/artifact-format/trust-cement |
|---|---|
| Requirement | Requirement 25: Cross-domain trust cement (/req/artifact-format/trust-cement) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify co-signatures cannot be stripped and commitments are undeniable. |
| Test method | Attempt to remove a co-signature from an artifact and verify the artifact’s self-description is broken. Verify the transparency log entry includes all co-signatures and cannot be rewritten. |
| Identifier | /conf/artifact-format/dimensional-convergence |
|---|---|
| Requirement | Requirement 26: Multi-dimensional convergence on canonical payload (/req/artifact-format/dimensional-convergence) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify all dimension attestations sign the same canonical payload. |
| Test method | Construct an artifact with dimension attestations from data, person, time, location, and environment dimensions. Verify each attestation validates against the same canonical payload hash. |
| Identifier | /conf/artifact-format/time-dimension |
|---|---|
| Requirement | Requirement 27: Time as first-class dimension (/req/artifact-format/time-dimension) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify the time dimension is attested by a time key with external anchoring. |
| Test method | Produce a time dimension attestation. Verify it is a co-signature tagged dimension time. Verify it records the artifact hash existence at a stated time. Verify the external time anchor is present and verifiable. |
| Identifier | /conf/artifact-format/dimension-extensibility |
|---|---|
| Requirement | Requirement 28: Dimension extensibility (/req/artifact-format/dimension-extensibility) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify a scheme-defined dimension attests and verifies through the standard machinery. |
| Test method | Register a test dimension profile with a tag, issuer, and attestation source. Produce an artifact carrying a co-signature under that tag over the canonical payload. Verify the standard pipeline processes it identically to a built-in dimension and the coverage report lists it. |
| Identifier | /conf/artifact-format/living-artifact |
|---|---|
| Requirement | Requirement 29: Living artifact accumulation (/req/artifact-format/living-artifact) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify dimension attestations can accumulate over time. |
| Test method | Produce an artifact with one dimension attestation. Add additional dimension attestations at successive times. Verify each added attestation signs the original canonical payload. Verify the coverage report gains fields with each addition. |
| Identifier | /conf/artifact-format/wrapping-prevention |
|---|---|
| Requirement | Requirement 30: Signature wrapping prevention (/req/artifact-format/wrapping-prevention) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify the signature wrapper prevents wrapping attacks. |
| Test method | Construct an artifact with unsigned fields that could influence downstream processing. Verify the verifier rejects the artifact because signed and processed content are not identical. |
| Identifier | /conf/artifact-format/replay-protection |
|---|---|
| Requirement | Requirement 31: Co-signature replay protection (/req/artifact-format/replay-protection) |
| Included in | Conformance class A.2: Artifact format conformance (/conf/artifact-format) |
| Test type | Conformance |
| Test purpose | Verify co-signatures bind to unique artifact identifiers. |
| Test method | Construct two artifacts with the same canonical payload hash but different artifact identifiers. Attach a co-signature from artifact A to artifact B. Verify the verifier rejects the replayed co-signature. |
A.4 Cryptographic algorithms
Cryptographic algorithms conformance has its formalized conformance class described in Table A.34, Conformance class A.3, with its conformance tests listed from Table A.35, Conformance test A.32 to Table A.41, Conformance test A.38.
| Identifier | /conf/algorithms/classical-algorithms |
|---|---|
| Requirement | Requirement 32: Classical algorithm recognition (/req/algorithms/classical-algorithms) |
| Included in | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Test type | Conformance |
| Test purpose | Verify classical algorithms are recognized with explicit identifiers. |
| Test method | Produce signatures using at least one classical algorithm from the scheme’s registry. Verify the signature wrappers carry explicit algorithm identifiers. Verify the signatures validate correctly. |
| Identifier | /conf/algorithms/post-quantum-algorithms |
|---|---|
| Requirement | Requirement 33: Post-quantum algorithm recognition (/req/algorithms/post-quantum-algorithms) |
| Included in | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Test type | Conformance |
| Test purpose | Verify post-quantum algorithms are recognized. |
| Test method | Produce signatures using at least one post-quantum algorithm from the scheme’s registry. Verify the signatures validate correctly against the specified parameter sets. |
| Identifier | /conf/algorithms/composite-and-semantics |
|---|---|
| Requirement | Requirement 34: Composite signature AND semantics (/req/algorithms/composite-and-semantics) |
| Included in | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Test type | Conformance |
| Test purpose | Verify composite signatures require both components to validate. |
| Test method | Produce a composite signature (classical + post-quantum). Verify it validates when both components are valid. Tamper with one component and verify the composite fails. |
| Identifier | /conf/algorithms/migration-phases |
|---|---|
| Requirement | Requirement 35: Post-quantum migration phases (/req/algorithms/migration-phases) |
| Included in | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Test type | Conformance |
| Test purpose | Verify the framework supports all three migration phases. |
| Test method | Configure a deployment for classical-only, composite, and post-quantum-only phases. Verify artifacts are produced and verified in each phase. |
| Identifier | /conf/algorithms/algorithm-agility-identifiers |
|---|---|
| Requirement | Requirement 36: Algorithm agility identifiers (/req/algorithms/algorithm-agility-identifiers) |
| Included in | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Test type | Conformance |
| Test purpose | Verify algorithm identifiers enable correct validation method selection. |
| Test method | Produce artifacts with different algorithm identifiers. Verify the verifier selects the correct validation method for each. Verify unknown identifiers are handled gracefully. |
| Identifier | /conf/algorithms/encryption-at-rest |
|---|---|
| Requirement | Requirement 37: Encryption at rest (/req/algorithms/encryption-at-rest) |
| Included in | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Test type | Validation |
| Test purpose | Verify keys at rest are encrypted with an authenticated encryption algorithm and a password-based key derivation function. |
| Test method | Inspect the key storage implementation. Verify an authenticated encryption algorithm meeting the minimum security parameters in Table 156 is used. Verify the encryption key is derived using a password-based key derivation function resistant to brute-force attacks. Attempt to read stored keys and verify they are not in plaintext. |
| Identifier | /conf/algorithms/minimum-security-parameters |
|---|---|
| Requirement | Requirement 38: Minimum security parameters (/req/algorithms/minimum-security-parameters) |
| Included in | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Test type | Conformance |
| Test purpose | Verify implementations use algorithms meeting minimum security strength. |
| Test method | Attempt to generate or accept keys, signatures, or hashes below 128-bit security strength. Verify all such attempts are rejected. Verify SHA-1 and MD5 are rejected. |
A.5 Threshold signing
Threshold signing conformance has its formalized conformance class described in Table A.42, Conformance class A.4, with its conformance tests listed from Table A.43, Conformance test A.39 to Table A.54, Conformance test A.50.
| Identifier | /conf/threshold-signing/threshold-every-level |
|---|---|
| Requirement | Requirement 39: Threshold at every level (/req/threshold-signing/threshold-every-level) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify that threshold signing is supported at every trust authority level. |
| Test method | Construct a delegation hierarchy with threshold at root, intermediate DTA, and end-issuing levels. Verify that signatures from each level require the specified quorum and cannot be produced by fewer than T members. |
| Identifier | /conf/threshold-signing/quorum-in-delegation |
|---|---|
| Requirement | Requirement 40: Quorum parameters in delegation (/req/threshold-signing/quorum-in-delegation) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Validation |
| Test purpose | Verify delegation certificates for threshold children carry the required quorum parameters. |
| Test method | Inspect delegation certificates for threshold authorities and verify they carry the aggregate public key, quorum (T, N), and member identity references. |
| Identifier | /conf/threshold-signing/aggregate-key-continuity |
|---|---|
| Requirement | Requirement 41: Aggregate key continuity under member rotation (/req/threshold-signing/aggregate-key-continuity) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify member rotation preserves the aggregate key and existing delegations. |
| Test method | Perform a member rotation (add, remove, replace) on a threshold authority. Verify the aggregate public key is unchanged. Verify existing parent delegations remain valid. Verify artifacts signed before and after rotation verify against the same aggregate key. |
| Identifier | /conf/threshold-signing/nested-threshold |
|---|---|
| Requirement | Requirement 42: Nested threshold (/req/threshold-signing/nested-threshold) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify nested threshold structures are supported. |
| Test method | Construct a threshold DTA whose members are themselves threshold DTAs. Verify signing requires inner authorities to reach their quorum before contributing shares to the outer threshold. |
| Identifier | /conf/threshold-signing/fta-formation |
|---|---|
| Requirement | Requirement 43: Federated trust authority formation (/req/threshold-signing/fta-formation) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify FTA formation produces a single aggregate key from independent members. |
| Test method | Form an FTA with multiple independent member organizations contributing shares. Verify the resulting aggregate key is a single key. Verify no single member can produce a valid signature. |
| Identifier | /conf/threshold-signing/fta-recursive-composition |
|---|---|
| Requirement | Requirement 44: Federated trust authority recursive composition (/req/threshold-signing/fta-recursive-composition) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify recursively composed FTAs are supported. |
| Test method | Construct an FTA that is a member of another FTA. Verify signing by the outer FTA requires the inner FTA to reach its own quorum first. |
| Identifier | /conf/threshold-signing/fta-hierarchy-spanning |
|---|---|
| Requirement | Requirement 45: Federated trust authority hierarchy-spanning (/req/threshold-signing/fta-hierarchy-spanning) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify FTAs can span independent root hierarchies. |
| Test method | Construct an FTA with members from two independent roots. Verify artifacts signed by the FTA are verifiable and recognized by both hierarchies. |
| Identifier | /conf/threshold-signing/fta-reshare |
|---|---|
| Requirement | Requirement 46: Federated trust authority re-share (/req/threshold-signing/fta-reshare) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify FTA member join/leave preserves the aggregate key and historical validity. |
| Test method | Add and remove members from an FTA. Verify the aggregate key is unchanged. Verify artifacts signed before the operation remain valid. |
| Identifier | /conf/threshold-signing/ceremony-threshold-property |
|---|---|
| Requirement | Requirement 47: Ceremony protocol threshold property (/req/threshold-signing/ceremony-threshold-property) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify the ceremony protocol enforces the threshold property. |
| Test method | Attempt to produce a signature with fewer than T members. Verify the attempt fails. Produce a signature with T or more members and verify it validates against the aggregate key. |
| Identifier | /conf/threshold-signing/rogue-key-prevention |
|---|---|
| Requirement | Requirement 48: Rogue-key attack prevention (/req/threshold-signing/rogue-key-prevention) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify proof-of-possession prevents rogue-key attacks. |
| Test method | Attempt to register a threshold member without proof-of-possession. Verify rejection. Attempt to register a crafted rogue key. Verify the aggregate key computation does not collapse to the attacker’s solo key. |
| Identifier | /conf/threshold-signing/ceremony-robustness |
|---|---|
| Requirement | Requirement 49: Ceremony identifiable abort and nonce commitment (/req/threshold-signing/ceremony-robustness) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Conformance |
| Test purpose | Verify ceremony protocol provides identifiable abort and nonce commitment. |
| Test method | Execute a ceremony with a malicious member sending malformed contributions. Verify the abort is attributable. Verify nonce commitment prevents nonce bias. |
| Identifier | /conf/threshold-signing/ceremony-record-production |
|---|---|
| Requirement | Requirement 50: Ceremony record production (/req/threshold-signing/ceremony-record-production) |
| Included in | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Test type | Validation |
| Test purpose | Verify ceremonies produce verifiable ceremony records. |
| Test method | Execute a signing ceremony and inspect the resulting ceremony record. Verify it documents participating members, threshold parameters, and the signature produced. Verify the record is independently verifiable. |
A.6 Trust chain and authorization scope governance
Scope governance conformance has its formalized conformance class described in Table A.55, Conformance class A.5, with its conformance tests listed from Table A.56, Conformance test A.51 to Table A.63, Conformance test A.58.
| Identifier | /conf/scope/scope-structure |
|---|---|
| Requirement | Requirement 51: Scope as multi-dimensional constraint set (/req/scope/scope-structure) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Validation |
| Test purpose | Verify scopes are expressed as multi-dimensional constraint sets. |
| Test method | Inspect scope encoding in delegation and end certificates. Verify each scope carries multiple independently constraining dimensions. Verify each dimension accepts wildcard, set, or single values. |
| Identifier | /conf/scope/monotonic-narrowing |
|---|---|
| Requirement | Requirement 52: Monotonic narrowing invariant (/req/scope/monotonic-narrowing) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Conformance |
| Test purpose | Verify the monotonic narrowing invariant is enforced at every delegation link. |
| Test method | Construct delegations with valid narrowing (wildcard to set, set to subset, set to single) and invalid widening (single to set, set to wildcard, single to different single). Verify the verifier accepts narrowing and rejects widening on every dimension. |
| Guidance |
|
| Identifier | /conf/scope/widening-rejection |
|---|---|
| Requirement | Requirement 53: Scope widening rejection (/req/scope/widening-rejection) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Conformance |
| Test purpose | Verify widening causes hard rejection, not downgrade. |
| Test method | Construct a chain with scope widening on one dimension. Verify the verifier rejects the path outright, not downgrades the classification label. |
| Identifier | /conf/scope/scope-conditions |
|---|---|
| Requirement | Requirement 54: Scope conditions as executable predicates (/req/scope/scope-conditions) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Conformance |
| Test purpose | Verify scope conditions are evaluated at verification time and cause failure when not met. |
| Test method | Construct artifacts with scope conditions (e.g., value within tolerance, calibration valid at time). Verify the verifier evaluates conditions against artifact content. Verify artifacts failing a condition are rejected even with valid signatures. |
| Identifier | /conf/scope/condition-determinism |
|---|---|
| Requirement | Requirement 55: Scope condition determinism (/req/scope/condition-determinism) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Conformance |
| Test purpose | Verify condition evaluation is deterministic across independent verifiers. |
| Test method | Evaluate the same scope condition against the same artifact using two independent verifier implementations. Verify both reach the same result. |
| Identifier | /conf/scope/scope-encoding |
|---|---|
| Requirement | Requirement 56: Scope encoding properties (/req/scope/scope-encoding) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Validation |
| Test purpose | Verify the scope encoding is machine-checkable, compact, and extensible. |
| Test method | Inspect the scope encoding format. Verify it is parseable without human interpretation. Verify the encoding size is proportional to constraint complexity, not inflated. Verify unknown dimension types or condition types do not cause parsing failure in verifiers that do not recognize them. |
| Identifier | /conf/scope/four-layer-enforcement |
|---|---|
| Requirement | Requirement 57: Four-layer scope enforcement (/req/scope/four-layer-enforcement) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Conformance |
| Test purpose | Verify scope is enforced at all four layers. |
| Test method | Test scope tampering in the certificate (layer 1). Test widening at a chain link (layer 2). Test condition failure in the pipeline (layer 3). Verify scope is present in transparency log entries (layer 4). Verify each layer independently detects the violation. |
| Identifier | /conf/scope/scope-in-transparency |
|---|---|
| Requirement | Requirement 58: Scope recorded in transparency log (/req/scope/scope-in-transparency) |
| Included in | Conformance class A.5: Scope governance conformance (/conf/scope) |
| Test type | Validation |
| Test purpose | Verify scope is recorded in the transparency log for every certificate. |
| Test method | Inspect transparency log entries for delegation and end certificates. Verify each entry includes the full scope. Verify third parties can audit scope assignments from log entries alone. |
A.7 Revocation and artifact binding
Revocation conformance has its formalized conformance class described in Table A.64, Conformance class A.6, with its conformance tests listed from Table A.65, Conformance test A.59 to Table A.72, Conformance test A.66.
| Identifier | /conf/revocation/crl-profile |
|---|---|
| Requirement | Requirement 59: CRL profile (/req/revocation/crl-profile) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Validation |
| Test purpose | Verify CRLs contain the required fields and are recorded in a transparency log. |
| Test method | Inspect CRL format and verify it identifies the issuing authority, carries revoked credential fingerprints with time and reason, carries a validity period, and is recorded in a transparency log. |
| Identifier | /conf/revocation/status-list-surface |
|---|---|
| Requirement | Requirement 60: Status list revocation surface (/req/revocation/status-list-surface) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Validation |
| Test purpose | Verify a scheme’s status list carries the required statuses and semantics. |
| Test method | Inspect the status list document and the scheme profile. Verify it is signed by the credential-issuing authority, encodes at least unset, revoked, and suspended per credential, defines the consequence of each value, and that revocation propagation applies to status-list revocations. |
| Identifier | /conf/revocation/hash-binding |
|---|---|
| Requirement | Requirement 61: Hash-binding to authority states (/req/revocation/hash-binding) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Validation |
| Test purpose | Verify artifacts carry hash-bindings to authority states. |
| Test method | Inspect artifacts and verify each carries a cryptographic hash-binding to the authority states under which it was produced. Verify the binding is part of the canonical payload or referenced via the transparency log. |
| Identifier | /conf/revocation/propagation |
|---|---|
| Requirement | Requirement 62: Propagation to bound artifacts (/req/revocation/propagation) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Conformance |
| Test purpose | Verify revocation propagates to all transitively bound artifacts. |
| Test method | Revoke an authority state. Query the set of artifacts bound to that state. Verify each bound artifact is flagged. Verify flagged artifacts receive the scheme’s rejected label. Verify propagation crosses trust dimensions and trust chains. |
| Identifier | /conf/revocation/flag-semantics |
|---|---|
| Requirement | Requirement 63: Flag semantics (marked not deleted) (/req/revocation/flag-semantics) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Conformance |
| Test purpose | Verify revocation uses mark semantics, not deletion. |
| Test method | Revoke a state and verify affected artifacts are marked, not deleted. Verify the marking is queryable. Correct the revocation and verify the marking is reversed. |
| Identifier | /conf/revocation/query-interface |
|---|---|
| Requirement | Requirement 64: Query interface (/req/revocation/query-interface) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Conformance |
| Test purpose | Verify the revocation query interface works offline. |
| Test method | Query an artifact’s bound states and their revocation status. Query artifacts bound to a revoked state. Perform both queries offline using cached CRLs and log indices. |
| Identifier | /conf/revocation/offline-grace-period |
|---|---|
| Requirement | Requirement 65: Offline grace period policy (/req/revocation/offline-grace-period) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Conformance |
| Test purpose | Verify the CRL grace period policy is applied correctly. |
| Test method | Present an artifact with a CRL within validity, a stale CRL within grace period, and a CRL expired beyond grace period. Verify direct acceptance, acceptance with downgrade, and rejection respectively. |
| Identifier | /conf/revocation/scope-condition-withdrawal |
|---|---|
| Requirement | Requirement 66: Scope condition withdrawal propagation (/req/revocation/scope-condition-withdrawal) |
| Included in | Conformance class A.6: Revocation conformance (/conf/revocation) |
| Test type | Conformance |
| Test purpose | Verify scope condition withdrawal propagates to affected artifacts. |
| Test method | Create an artifact with a scope condition referencing an external state. Revoke the external state. Verify the artifact is flagged and receives the scheme’s rejected label. Verify artifacts without the condition are unaffected. |
A.8 Transparency and multi-log attestation
Transparency conformance has its formalized conformance class described in Table A.73, Conformance class A.7, with its conformance tests listed from Table A.74, Conformance test A.67 to Table A.83, Conformance test A.76.
| Identifier | /conf/transparency/merkle-append-only |
|---|---|
| Requirement | Requirement 67: Merkle tree append-only structure (/req/transparency/merkle-append-only) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Validation |
| Test purpose | Verify the transparency log is an append-only Merkle tree with domain separation. |
| Test method | Inspect the log structure. Verify domain-separated hashing for leaves and internal nodes. Verify entries cannot be modified or removed. Verify each tree head is signed by the log operator. |
| Identifier | /conf/transparency/inclusion-proof |
|---|---|
| Requirement | Requirement 68: Inclusion proof format (/req/transparency/inclusion-proof) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify inclusion proofs contain the required components and validate correctly. |
| Test method | Produce inclusion proofs for log entries. Verify each proof contains leaf hash, audit path, tree head, and operator signature. Verify the proof validates by recomputing the root and checking the signature. |
| Identifier | /conf/transparency/tree-head-anchoring |
|---|---|
| Requirement | Requirement 69: External time anchoring of tree heads (/req/transparency/tree-head-anchoring) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify tree heads are anchored to an external time source. |
| Test method | Inspect tree head anchors and verify each produces a verifiable proof of commitment to an external irrefutable time source. Verify the anchor timestamp is at or near the tree head timestamp. |
| Identifier | /conf/transparency/mirror-integrity |
|---|---|
| Requirement | Requirement 70: Mirror replication and integrity (/req/transparency/mirror-integrity) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify mirrors independently verify log append-only property and serve proofs. |
| Test method | Operate a mirror and verify it checks that each new tree head extends the previous one. Verify the mirror serves inclusion proofs and log entries. Simulate a split view and verify the mirror detects it. |
| Identifier | /conf/transparency/gossip-quorum |
|---|---|
| Requirement | Requirement 71: Gossip quorum for tree head consistency (/req/transparency/gossip-quorum) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify the verifier confirms gossip quorum before accepting tree heads. |
| Test method | Present a tree head observed by fewer than the quorum of independent sources. Verify rejection. Present a tree head observed by the quorum. Verify acceptance. |
| Identifier | /conf/transparency/mandatory-inclusion |
|---|---|
| Requirement | Requirement 72: Mandatory transparency inclusion (/req/transparency/mandatory-inclusion) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify un-logged artifacts are downgraded or rejected. |
| Test method | Present artifacts with and without transparency log inclusion proofs. Verify artifacts with proofs are accepted (subject to classification label). Verify artifacts without proofs are downgraded or rejected. |
| Identifier | /conf/transparency/multi-log-quorum |
|---|---|
| Requirement | Requirement 73: Multi-log attestation quorum (/req/transparency/multi-log-quorum) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify multi-log attestation quorum is enforced. |
| Test method | Construct an FTA artifact with inclusion proofs from fewer than M logs. Verify rejection. Construct with M or more log proofs. Verify acceptance. Verify each proof is validated independently. |
| Identifier | /conf/transparency/log-content-minimization |
|---|---|
| Requirement | Requirement 74: Log content minimization (/req/transparency/log-content-minimization) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify log structures carry no directly identifying personal data and that named-identity binding sits in access-controlled registers. |
| Test method | Inspect serialized log leaves, inclusion proofs, and tree heads for names, identifiers, or linkable personal data; verify only digests and tags appear. Attempt to resolve a signer from a public artifact without the authority register and confirm the register is access-controlled. |
| Identifier | /conf/transparency/log-retention |
|---|---|
| Requirement | Requirement 75: Log retention (/req/transparency/log-retention) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify the log and its mirrors retain append-only history for the served period. |
| Test method | Inspect the log’s retention policy against the deployment’s maximum artifact validity plus grace periods. Request historical tree heads and inclusion proofs from the log and from a mirror. Verify both serve entries from the required period. |
| Identifier | /conf/transparency/consistency-proofs |
|---|---|
| Requirement | Requirement 76: Consistency proofs (/req/transparency/consistency-proofs) |
| Included in | Conformance class A.7: Transparency conformance (/conf/transparency) |
| Test type | Conformance |
| Test purpose | Verify the transparency log supports consistency proofs between tree heads. |
| Test method | Request a consistency proof between two consecutive tree heads. Verify the proof confirms the earlier tree is a prefix of the later tree. Request a consistency proof between non-consecutive tree heads. Verify the proof validates. |
A.9 Verification pipeline
Verification pipeline conformance has its formalized conformance class described in Table A.84, Conformance class A.8, with its conformance tests listed from Table A.85, Conformance test A.77 to Table A.92, Conformance test A.84.
| Identifier | /conf/verification/pipeline-architecture |
|---|---|
| Requirement | Requirement 77: Ordered pipeline with hard and soft checks (/req/verification/pipeline-architecture) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify the pipeline applies ordered hard and soft checks correctly. |
| Test method | Construct artifacts that fail each hard check and verify the pipeline short-circuits to the scheme’s rejected label. Construct artifacts with varying soft check coverage and verify the classification label accumulates correctly. |
| Identifier | /conf/verification/hard-checks |
|---|---|
| Requirement | Requirement 78: Hard check classification (/req/verification/hard-checks) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify each hard check causes short-circuit to the scheme’s rejected label on failure. |
| Test method | For each hard check (format, signature, chain, scope narrowing, scope conditions, revocation), construct an artifact that fails only that check. Verify the pipeline returns the scheme’s rejected label in each case. |
| Identifier | /conf/verification/pathfinding |
|---|---|
| Requirement | Requirement 79: Trust graph path-finding (/req/verification/pathfinding) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify the verifier finds paths in the trust graph and collects distinct roots. |
| Test method | Construct an artifact with co-signatures from multiple independent roots. Verify the verifier finds valid paths to each root. Verify distinct roots are counted for cross-domain diversity scoring. |
| Identifier | /conf/verification/coverage-report |
|---|---|
| Requirement | Requirement 80: Coverage report production (/req/verification/coverage-report) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify the pipeline produces a complete coverage report. |
| Test method | Construct artifacts with varying dimensional coverage. Verify the coverage report contains all required fields with correct values for hard checks, transparency, time anchor, dimensions, independent roots, and multi-log status. |
| Identifier | /conf/verification/classification-policy |
|---|---|
| Requirement | Requirement 81: Scheme-defined classification policy (/req/verification/classification-policy) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify the scheme’s classification policy deterministically maps coverage reports to grade labels. |
| Test method | Apply the scheme’s classification policy to multiple coverage reports. Verify identical coverage reports produce identical grade labels. Verify the classification is a pure function with no side effects. |
| Identifier | /conf/verification/acceptance-policy |
|---|---|
| Requirement | Requirement 82: Verifier acceptance policy (/req/verification/acceptance-policy) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify the verifier’s acceptance policy maps classification labels to accept/reject decisions. |
| Test method | Configure acceptance policies for different decision contexts. Verify artifacts are accepted or rejected correctly based on their classification label and the context. |
| Identifier | /conf/verification/time-freshness-window |
|---|---|
| Requirement | Requirement 83: Time freshness window (/req/verification/time-freshness-window) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify the time freshness window rejects stale time attestations. |
| Test method | Construct artifacts with time attestations of varying ages. Verify that attestations within the freshness window are accepted, those outside are rejected, and those in the grace period are accepted at a downgraded classification label. |
| Identifier | /conf/verification/offline-verification |
|---|---|
| Requirement | Requirement 84: Offline verification capability (/req/verification/offline-verification) |
| Included in | Conformance class A.8: Verification pipeline conformance (/conf/verification) |
| Test type | Conformance |
| Test purpose | Verify offline verification produces correct results. |
| Test method | Verify artifacts using only the trust anchor bundle, cached CRLs, cached tree heads, and embedded chains. Verify the coverage report matches online verification except for freshness-dependent checks. |
A.10 Key lifecycle
Key lifecycle conformance has its formalized conformance class described in Table A.93, Conformance class A.9, with its conformance tests listed from Table A.94, Conformance test A.85 to Table A.99, Conformance test A.90.
| Identifier | /conf/key-lifecycle |
|---|---|
| Requirements class | Requirements class 9: Key lifecycle (/req/key-lifecycle) |
| Prerequisites | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Description | Conformance tests for key lifecycle requirements. |
| Conformance tests | Conformance test A.85: Secure key generation test (/conf/key-lifecycle/key-generation) Conformance test A.86: Encrypted key storage validation (/conf/key-lifecycle/encrypted-storage) Conformance test A.87: Key import and export test (/conf/key-lifecycle/import-export) Conformance test A.88: HSM interface test (/conf/key-lifecycle/hsm-interface) Conformance test A.89: CSR proof of possession test (/conf/key-lifecycle/csr-pop) Conformance test A.90: Key rotation test (/conf/key-lifecycle/key-rotation) |
| Identifier | /conf/key-lifecycle/key-generation |
|---|---|
| Requirement | Requirement 85: Secure key generation (/req/key-lifecycle/key-generation) |
| Included in | Conformance class A.9: Key lifecycle conformance (/conf/key-lifecycle) |
| Test type | Conformance |
| Test purpose | Verify keys are generated with secure randomness and correct parameters. |
| Test method | Generate keys for each supported algorithm. Verify the random source is cryptographically secure. Verify parameters conform to specifications. For threshold keys, verify no individual member possesses the full key. |
| Identifier | /conf/key-lifecycle/encrypted-storage |
|---|---|
| Requirement | Requirement 86: Encrypted key storage (/req/key-lifecycle/encrypted-storage) |
| Included in | Conformance class A.9: Key lifecycle conformance (/conf/key-lifecycle) |
| Test type | Validation |
| Test purpose | Verify private keys are encrypted at rest. |
| Test method | Inspect stored keys and verify they are encrypted with an authenticated encryption algorithm meeting the minimum security parameters in Table 156. Verify the encryption key is derived using a password-based key derivation function resistant to brute-force attacks. Attempt plaintext extraction and verify failure. |
| Identifier | /conf/key-lifecycle/import-export |
|---|---|
| Requirement | Requirement 87: Key import and export encodings (/req/key-lifecycle/import-export) |
| Included in | Conformance class A.9: Key lifecycle conformance (/conf/key-lifecycle) |
| Test type | Conformance |
| Test purpose | Verify key import and export use standard encodings. |
| Test method | Export keys in at least one recognized encoding format. Re-import and verify round-trip correctness. Verify imported keys are validated for format and algorithm consistency. |
| Identifier | /conf/key-lifecycle/hsm-interface |
|---|---|
| Requirement | Requirement 88: Hardware security module interface (/req/key-lifecycle/hsm-interface) |
| Included in | Conformance class A.9: Key lifecycle conformance (/conf/key-lifecycle) |
| Test type | Conformance |
| Test purpose | Verify HSM usage keeps private keys inside the HSM. |
| Test method | Configure an HSM-backed key. Verify signing occurs within the HSM. Verify the private key never leaves the HSM. Verify session authentication is enforced. |
| Identifier | /conf/key-lifecycle/csr-pop |
|---|---|
| Requirement | Requirement 89: Certificate signing request with proof of possession (/req/key-lifecycle/csr-pop) |
| Included in | Conformance class A.9: Key lifecycle conformance (/conf/key-lifecycle) |
| Test type | Conformance |
| Test purpose | Verify CSRs include valid proof of possession. |
| Test method | Generate a CSR with PoP. Verify the PoP signature validates against the request’s public key. Submit a CSR without PoP and verify rejection. |
| Identifier | /conf/key-lifecycle/key-rotation |
|---|---|
| Requirement | Requirement 90: Key rotation (/req/key-lifecycle/key-rotation) |
| Included in | Conformance class A.9: Key lifecycle conformance (/conf/key-lifecycle) |
| Test type | Conformance |
| Test purpose | Verify key rotation works correctly. |
| Test method | Rotate a threshold member and verify the aggregate key is unchanged. Rotate an end certificate key and verify the new certificate is under the same or narrower scope. |
A.11 Delivery and discovery
Delivery and discovery conformance has its formalized conformance class described in Table A.100, Conformance class A.10, with its conformance tests listed from Table A.101, Conformance test A.91 to Table A.107, Conformance test A.97.
| Identifier | /conf/delivery/barcode-encoding |
|---|---|
| Requirement | Requirement 91: Compact barcode encoding (/req/delivery/barcode-encoding) |
| Included in | Conformance class A.10: Delivery and discovery conformance (/conf/delivery) |
| Test type | Conformance |
| Test purpose | Verify barcode encoding is self-contained with error correction. |
| Test method | Encode an artifact or passport as a two-dimensional barcode. Verify the encoding is self-contained, carries a version identifier, and includes error correction. Decode and verify fidelity. |
| Identifier | /conf/delivery/passport-format |
|---|---|
| Requirement | Requirement 92: Passport format (/req/delivery/passport-format) |
| Included in | Conformance class A.10: Delivery and discovery conformance (/conf/delivery) |
| Test type | Conformance |
| Test purpose | Verify passports carry required fields and are verifiable. |
| Test method | Produce a passport from a certificate. Verify it carries identifier, key fingerprint, scope summary, and validity period. Verify it is deterministic and verifiable against the trust anchor bundle and transparency log. |
| Identifier | /conf/delivery/embedded-delivery |
|---|---|
| Requirement | Requirement 93: Embedded chain delivery (/req/delivery/embedded-delivery) |
| Included in | Conformance class A.10: Delivery and discovery conformance (/conf/delivery) |
| Test type | Conformance |
| Test purpose | Verify embedded chain delivery requires no network access. |
| Test method | Deliver an artifact with embedded chain. Verify the verifier can complete chain discovery with no network access. |
| Identifier | /conf/delivery/log-reference-delivery |
|---|---|
| Requirement | Requirement 94: Transparency-log reference delivery (/req/delivery/log-reference-delivery) |
| Included in | Conformance class A.10: Delivery and discovery conformance (/conf/delivery) |
| Test type | Conformance |
| Test purpose | Verify log-reference delivery enables chain reconstruction. |
| Test method | Deliver an artifact with transparency-log sequence references. Verify the verifier can fetch and cache referenced certificates from a log or mirror. |
| Identifier | /conf/delivery/connected-delivery |
|---|---|
| Requirement | Requirement 95: Connected device delivery integrity (/req/delivery/connected-delivery) |
| Included in | Conformance class A.10: Delivery and discovery conformance (/conf/delivery) |
| Test type | Conformance |
| Test purpose | Verify connected delivery authenticates source and provides integrity. |
| Test method | Deliver artifacts via a network protocol. Verify source authentication, integrity protection, and caching support. |
| Identifier | /conf/delivery/credential-exchange |
|---|---|
| Requirement | Requirement 96: Credential exchange (/req/delivery/credential-exchange) |
| Included in | Conformance class A.10: Delivery and discovery conformance (/conf/delivery) |
| Test type | Conformance |
| Test purpose | Verify credential exchanges are holder-initiated and authenticate the holder. |
| Test method | Run an issuance exchange and a presentation exchange. Verify the coordinator does not deliver without a holder request, and does not issue to or accept from an identifier until the holder has signed a fresh nonce with the key behind that identifier. Verify nonce reuse is rejected. |
| Identifier | /conf/delivery/challenge-response |
|---|---|
| Requirement | Requirement 97: Challenge-response protocol (/req/delivery/challenge-response) |
| Included in | Conformance class A.10: Delivery and discovery conformance (/conf/delivery) |
| Test type | Conformance |
| Test purpose | Verify challenge-response protocol produces fresh, nonce-bound artifacts. |
| Test method | Issue a challenge with a 128-bit nonce. Verify the device binds the nonce into the canonical payload. Verify the verifier rejects mismatched nonces, stale responses, and replayed nonce reuse. |
A.12 Ceremony records
Ceremony records conformance has its formalized conformance class described in Table A.108, Conformance class A.11, with its conformance tests listed from Table A.109, Conformance test A.98 to Table A.113, Conformance test A.102.
| Identifier | /conf/ceremony |
|---|---|
| Requirements class | Requirements class 11: Ceremony records (/req/ceremony) |
| Prerequisite | Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Description | Conformance tests for ceremony record requirements. |
| Conformance tests | Conformance test A.98: Transcript contents validation (/conf/ceremony/transcript-contents) Conformance test A.99: Transcript signing test (/conf/ceremony/transcript-signing) Conformance test A.100: Transcript persistence validation (/conf/ceremony/transcript-persistence) Conformance test A.101: Transcript log cross-reference test (/conf/ceremony/transcript-log-cross-reference) Conformance test A.102: Audit algorithm test (/conf/ceremony/audit-algorithm) |
| Identifier | /conf/ceremony/transcript-contents |
|---|---|
| Requirement | Requirement 98: Transcript contents (/req/ceremony/transcript-contents) |
| Included in | Conformance class A.11: Ceremony records conformance (/conf/ceremony) |
| Test type | Validation |
| Test purpose | Verify transcripts contain all required fields. |
| Test method | Execute a signing ceremony and inspect the transcript. Verify it contains ceremony type, participant identities with contribution proofs, quorum parameters, payload hash, aggregate signature, and timestamp. |
| Identifier | /conf/ceremony/transcript-signing |
|---|---|
| Requirement | Requirement 99: Transcript signing by participants (/req/ceremony/transcript-signing) |
| Included in | Conformance class A.11: Ceremony records conformance (/conf/ceremony) |
| Test type | Conformance |
| Test purpose | Verify transcripts are signed by all participants and carry the aggregate signature. |
| Test method | Execute a ceremony and verify each participant signed the transcript. Verify the aggregate threshold signature is present. Present an incomplete transcript and verify rejection. |
| Identifier | /conf/ceremony/transcript-persistence |
|---|---|
| Requirement | Requirement 100: Transcript persistence and retention (/req/ceremony/transcript-persistence) |
| Included in | Conformance class A.11: Ceremony records conformance (/conf/ceremony) |
| Test type | Validation |
| Test purpose | Verify transcripts are persisted with sufficient retention. |
| Test method | Execute a ceremony and verify the transcript is persisted to durable storage. Verify the retention period exceeds the maximum artifact lifetime including grace periods. |
| Identifier | /conf/ceremony/transcript-log-cross-reference |
|---|---|
| Requirement | Requirement 101: Transcript transparency log cross-reference (/req/ceremony/transcript-log-cross-reference) |
| Included in | Conformance class A.11: Ceremony records conformance (/conf/ceremony) |
| Test type | Conformance |
| Test purpose | Verify transcripts are cross-referenced with transparency log entries. |
| Test method | Execute a ceremony and verify the produced artifact appears in the transparency log. Verify the transcript references the log entry. |
| Identifier | /conf/ceremony/audit-algorithm |
|---|---|
| Requirement | Requirement 102: Transcript audit algorithm (/req/ceremony/audit-algorithm) |
| Included in | Conformance class A.11: Ceremony records conformance (/conf/ceremony) |
| Test type | Conformance |
| Test purpose | Verify the audit algorithm correctly validates ceremony transcripts. |
| Test method | Execute the audit algorithm on valid and invalid transcripts. Verify it accepts valid transcripts (correct member signatures, aggregate signature, quorum, log cross-reference, timestamp) and rejects invalid ones. |
A.13 Deployment manifest
Deployment manifest conformance has its formalized conformance class described in Table A.114, Conformance class A.12, with its conformance tests listed from Table A.115, Conformance test A.103 to Table A.121, Conformance test A.109.
| Identifier | /conf/manifest/manifest-format |
|---|---|
| Requirement | Requirement 103: Manifest format and signing (/req/manifest/manifest-format) |
| Included in | Conformance class A.12: Deployment manifest conformance (/conf/manifest) |
| Test type | Validation |
| Test purpose | Verify the manifest is in a declarative format, versioned, and signed. |
| Test method | Inspect the manifest format and verify it is declarative (TOML, YAML, or JSON). Verify it carries a version identifier. Verify it is signed by the root trust authority. |
| Identifier | /conf/manifest/manifest-topology |
|---|---|
| Requirement | Requirement 104: Manifest topology declaration (/req/manifest/manifest-topology) |
| Included in | Conformance class A.12: Deployment manifest conformance (/conf/manifest) |
| Test type | Validation |
| Test purpose | Verify the manifest declares topology and authorities correctly. |
| Test method | Inspect the manifest and verify it declares the topology profile, all trust authorities with identifiers, aggregate keys, quorum parameters, and parent references. |
| Identifier | /conf/manifest/manifest-algorithms |
|---|---|
| Requirement | Requirement 105: Manifest algorithm declaration (/req/manifest/manifest-algorithms) |
| Included in | Conformance class A.12: Deployment manifest conformance (/conf/manifest) |
| Test type | Validation |
| Test purpose | Verify the manifest declares recognized algorithms. |
| Test method | Inspect the manifest and verify declared algorithms are from the framework’s registry. |
| Identifier | /conf/manifest/manifest-transparency |
|---|---|
| Requirement | Requirement 106: Manifest transparency declaration (/req/manifest/manifest-transparency) |
| Included in | Conformance class A.12: Deployment manifest conformance (/conf/manifest) |
| Test type | Validation |
| Test purpose | Verify the manifest declares transparency logs, mirrors, and multi-log policy. |
| Test method | Inspect the manifest and verify it declares recognized transparency logs and mirrors with endpoints and public keys. Verify multi-log parameters are present if applicable. |
| Identifier | /conf/manifest/manifest-validation-acyclic |
|---|---|
| Requirement | Requirement 107: Manifest validation — acyclic graph (/req/manifest/manifest-validation-acyclic) |
| Included in | Conformance class A.12: Deployment manifest conformance (/conf/manifest) |
| Test type | Conformance |
| Test purpose | Verify the manifest validates as an acyclic trust graph with scope narrowing. |
| Test method | Submit manifests with valid and cyclic authority graphs. Verify acyclic manifests pass validation and cyclic ones fail. Verify scope narrowing is checked at every delegation link. |
| Identifier | /conf/manifest/manifest-validation-quorum |
|---|---|
| Requirement | Requirement 108: Manifest validation — quorum consistency (/req/manifest/manifest-validation-quorum) |
| Included in | Conformance class A.12: Deployment manifest conformance (/conf/manifest) |
| Test type | Conformance |
| Test purpose | Verify quorum parameters are validated for consistency. |
| Test method | Submit manifests with valid (T ⇐ N) and invalid (T > N) quorum parameters. Verify valid manifests pass and invalid ones fail validation. |
| Identifier | /conf/manifest/manifest-versioning |
|---|---|
| Requirement | Requirement 109: Manifest versioning (/req/manifest/manifest-versioning) |
| Included in | Conformance class A.12: Deployment manifest conformance (/conf/manifest) |
| Test type | Conformance |
| Test purpose | Verify manifest versioning follows semantic rules. |
| Test method | Submit manifests with major and minor version changes. Verify major changes are handled as breaking and minor changes as compatible. Verify the most recent signed manifest is authoritative. |
A.14 Governance and mutual recognition
Governance conformance has its formalized conformance class described in Table A.122, Conformance class A.13, with its conformance tests listed from Table A.123, Conformance test A.110 to Table A.127, Conformance test A.114.
| Identifier | /conf/governance |
|---|---|
| Requirements class | Requirements class 13: Governance and mutual recognition (/req/governance) |
| Prerequisites | Conformance class A.1: Architecture and trust model conformance (/conf/architecture) Conformance class A.4: Threshold signing conformance (/conf/threshold-signing) |
| Description | Conformance tests for governance and mutual recognition requirements. |
| Conformance tests | Conformance test A.110: Topology declaration validation (/conf/governance/topology-declaration) Conformance test A.111: Root governance requirements test (/conf/governance/root-governance) Conformance test A.112: Issuing authority ISMS test (/conf/governance/issuing-authority-assurance) Conformance test A.113: Mutual recognition test (/conf/governance/mutual-recognition) Conformance test A.114: Topology conformance test (/conf/governance/topology-conformance) |
| Identifier | /conf/governance/topology-declaration |
|---|---|
| Requirement | Requirement 110: Topology declaration in manifest (/req/governance/topology-declaration) |
| Included in | Conformance class A.13: Governance conformance (/conf/governance) |
| Test type | Validation |
| Test purpose | Verify the deployment declares its topology in the manifest. |
| Test method | Inspect the deployment manifest and verify it declares one of the four topology profiles. Verify the declared topology matches the actual trust graph structure. |
| Identifier | /conf/governance/root-governance |
|---|---|
| Requirement | Requirement 111: Root trust authority governance requirements (/req/governance/root-governance) |
| Included in | Conformance class A.13: Governance conformance (/conf/governance) |
| Test type | Conformance |
| Test purpose | Verify the root trust authority satisfies all governance requirements. |
| Test method | Inspect a root trust authority and verify it publishes scope and delegation policy, records operations in a transparency log, operates under threshold or federation, maintains governance records, publishes a versioned anchor bundle, and maintains an ISMS with published audit attestations. |
| Identifier | /conf/governance/issuing-authority-assurance |
|---|---|
| Requirement | Requirement 112: Issuing authority organizational assurance (/req/governance/issuing-authority-assurance) |
| Included in | Conformance class A.13: Governance conformance (/conf/governance) |
| Test type | Conformance |
| Test purpose | Verify issuing authorities maintain organizational assurance. |
| Test method | Inspect a delegated trust authority that issues end certificates. Verify it maintains an ISMS or equivalent framework and undergoes periodic security audits. |
| Identifier | /conf/governance/mutual-recognition |
|---|---|
| Requirement | Requirement 113: Mutual recognition via signed credentials (/req/governance/mutual-recognition) |
| Included in | Conformance class A.13: Governance conformance (/conf/governance) |
| Test type | Conformance |
| Test purpose | Verify mutual recognition is expressed via signed cross-recognition credentials. |
| Test method | Establish mutual recognition between two roots. Verify cross-recognition credentials are signed by both roots. Verify the credentials are recorded in both transparency logs. Verify verifiers with both anchors can accept artifacts from either hierarchy. |
| Identifier | /conf/governance/topology-conformance |
|---|---|
| Requirement | Requirement 114: Topology conformance (/req/governance/topology-conformance) |
| Included in | Conformance class A.13: Governance conformance (/conf/governance) |
| Test type | Conformance |
| Test purpose | Verify each topology profile’s structural requirements are satisfied. |
| Test method | For each topology profile (hierarchical, federated, cross-recognized, mesh), construct a conforming deployment and verify it satisfies the structural requirements. Construct a non-conforming deployment and verify rejection. |
A.15 Algorithm agility
Algorithm agility conformance has its formalized conformance class described in Table A.128, Conformance class A.14, with its conformance tests listed from Table A.129, Conformance test A.115 to Table A.134, Conformance test A.120.
| Identifier | /conf/algorithm-agility |
|---|---|
| Requirements class | Requirements class 14: Algorithm agility (/req/algorithm-agility) |
| Prerequisite | Conformance class A.3: Cryptographic algorithms conformance (/conf/algorithms) |
| Description | Conformance tests for algorithm agility requirements. |
| Conformance tests | Conformance test A.115: Algorithm registry validation (/conf/algorithm-agility/algorithm-registry) Conformance test A.116: Deprecation process test (/conf/algorithm-agility/deprecation-process) Conformance test A.117: Migration phase declaration validation (/conf/algorithm-agility/migration-declaration) Conformance test A.118: Archive validation test (/conf/algorithm-agility/archive-validation) Conformance test A.119: Circulation migration path test (/conf/algorithm-agility/reissuance-path) Conformance test A.120: Composite backward compatibility test (/conf/algorithm-agility/composite-backward-compatibility) |
| Identifier | /conf/algorithm-agility/algorithm-registry |
|---|---|
| Requirement | Requirement 115: Algorithm identifier registry (/req/algorithm-agility/algorithm-registry) |
| Included in | Conformance class A.14: Algorithm agility conformance (/conf/algorithm-agility) |
| Test type | Validation |
| Test purpose | Verify the algorithm registry is maintained and used. |
| Test method | Inspect the registry and verify it lists recognized algorithms with names, references, parameters, and status. Verify conforming verifiers accept registered identifiers and reject unregistered ones. |
| Identifier | /conf/algorithm-agility/deprecation-process |
|---|---|
| Requirement | Requirement 116: Algorithm deprecation process (/req/algorithm-agility/deprecation-process) |
| Included in | Conformance class A.14: Algorithm agility conformance (/conf/algorithm-agility) |
| Test type | Conformance |
| Test purpose | Verify the deprecation process is followed correctly. |
| Test method | Deprecate an algorithm following the published process. Verify artifacts using the deprecated algorithm are downgraded during the deprecation period. Verify they are rejected after retirement. |
| Identifier | /conf/algorithm-agility/migration-declaration |
|---|---|
| Requirement | Requirement 117: Migration phase declaration (/req/algorithm-agility/migration-declaration) |
| Included in | Conformance class A.14: Algorithm agility conformance (/conf/algorithm-agility) |
| Test type | Validation |
| Test purpose | Verify deployments declare their migration phase. |
| Test method | Inspect deployment manifests and verify they declare active algorithms and migration phase (classical-only, composite, or post-quantum-only). |
| Identifier | /conf/algorithm-agility/archive-validation |
|---|---|
| Requirement | Requirement 118: Archive validation (/req/algorithm-agility/archive-validation) |
| Included in | Conformance class A.14: Algorithm agility conformance (/conf/algorithm-agility) |
| Test type | Conformance |
| Test purpose | Verify retired-algorithm artifacts with contemporaneous evidence verify under the archive label. |
| Test method | Construct an artifact signed with a deprecated-then-retired algorithm carrying a contemporaneous time attestation and transparency inclusion proof. Verify it classifies under the scheme’s archive label rather than being rejected outright. |
| Identifier | /conf/algorithm-agility/reissuance-path |
|---|---|
| Requirement | Requirement 119: Circulation migration path (/req/algorithm-agility/reissuance-path) |
| Included in | Conformance class A.14: Algorithm agility conformance (/conf/algorithm-agility) |
| Test type | Conformance |
| Test purpose | Verify the deprecation process provides a migration path before retirement. |
| Test method | Inspect the published deprecation process. Verify it defines re-issuance, re-signing, or archival classification for artifacts still in circulation, and that the path is available throughout the deprecation window. |
| Identifier | /conf/algorithm-agility/composite-backward-compatibility |
|---|---|
| Requirement | Requirement 120: Composite phase backward compatibility (/req/algorithm-agility/composite-backward-compatibility) |
| Included in | Conformance class A.14: Algorithm agility conformance (/conf/algorithm-agility) |
| Test type | Conformance |
| Test purpose | Verify composite phase maintains backward compatibility. |
| Test method | Configure a deployment in composite phase. Verify new artifacts use composite signatures. Verify existing classical-only artifacts remain verifiable. Configure post-quantum-only phase and verify classical-only signatures are rejected. |
Annex B
(informative)
Comparison with traditional public key infrastructure
B.1 General
This annex describes how the trust infrastructure specified in this document differs from traditional public key infrastructure (PKI) as specified in ISO/IEC 9594-8 (X.509) ISO/IEC 9594-8:2020 and the IETF PKI certificate profile IETF RFC 5280. The comparison describes design intent, not deficiency: PKI is mature and appropriate for the server-identity and identity-binding problems it was designed for, and the differences below exist because those problems differ from the regulated-artifact problem this document addresses. It identifies the use cases for which each technology is appropriate and distinguishes decisions driven by hard technical requirements from those driven by deployment preference.
This annex is informative. It does not specify requirements.
B.2 Applicable standards
The following standards define traditional PKI:
ISO/IEC 9594-8:2020 (X.509) specifies the public-key and attribute certificate framework, including certificate formats, certification path validation, and attribute certificates.
IETF RFC 5280 profiles X.509 certificates and certificate revocation lists for use in the Internet PKI.
IETF RFC 8446 (TLS 1.3) specifies the Transport Layer Security protocol, which uses X.509 certificates for server and client authentication.
IETF RFC 6962 specifies Certificate Transparency, an optional overlay for monitoring certificate issuance in the web PKI.
This document specifies SIGNATIF, which addresses a different problem space: establishing the trustworthiness of persistent artifacts through multi-party, multi-dimensional attestation.
B.3 Structural differences
Table B.1 summarizes the structural differences.
| Property | Traditional PKI | SIGNATIF (this document) |
|---|---|---|
| Authorization boundary | Policy-defined (Baseline Requirements); not verifiable from the certificate | Cryptographic scope enforced at every chain link (Clause 10) |
| Signers per object | One signature per certificate | N co-signatures per artifact, each from an independent trust dimension (7.7) |
| Key compromise resilience | Single key per CA; single point of compromise | Threshold at every authority level (Clause 9) |
| Federation model | Bridge CAs are single entities | Federated trust authorities are threshold groups of independent organizations (9.5) |
| Transparency | Certificate Transparency is an optional monitoring overlay | Transparency log inclusion is a verification requirement (Clause 12) |
| Trust assessment | Binary: valid or revoked | Graduated: graduated trust classification reflecting coverage report (13.5) |
| Revocation scope | Invalidates the certificate; prior signatures remain valid | Propagates to all artifacts transitively bound to the revoked state (11.5) |
| Time evidence | notBefore/notAfter are self-asserted by the issuer | External time anchoring via independent time authority (7.9.3) |
| Topology | Strict hierarchy (cross-certification at CA level) | Hierarchical, federated, cross-recognized, and mesh as first-class profiles (18.2) |
| Authorization model | Static: “this key is authorized” | Dynamic: scope includes executable conditions evaluated at verification time (10.4) |
| Authenticity proof | Static certificate; authenticity proven by possession | Challenge-response: verifier challenges for fresh nonce-bound artifact |
| Log redundancy | Single CT log suffices for monitoring | Multi-log attestation quorum (M-of-K) for federated artifacts (12.7) |
| Cross-domain trust | CA-to-CA cross-certification | Artifact-level co-signatures from independent hierarchies (7.8) |
| Dimensional coverage | One dimension: authority/identity | Multi-dimensional: time, location, environment as cryptographic co-signature dimensions (7.9) |
B.4 Use case suitability
B.4.1 Use cases for which SIGNATIF is the appropriate technology
SIGNATIF is appropriate when one or more of the following properties are required:
Multi-party attestation. The artifact’s trustworthiness depends on independent attestations from multiple parties (e.g., operator, laboratory, regulator). PKI binds one signer per object and cannot express convergence.
Cryptographic scope enforcement. The signing key’s authority must be verifiable from the certificate itself, not from external policy. PKI defines scope externally; it cannot detect scope violations at verification time.
Threshold at every level. No single key compromise compromises any authority. PKI uses single-key CAs; threshold is typically root-only if at all.
Mandatory transparency. The artifact’s existence is publicly auditable, and un-logged artifacts are rejected. PKI treats transparency as optional.
Revocation propagation to artifacts. Revoking an authority state flags all artifacts bound to that state. PKI revokes certificates only; prior signatures remain valid.
Multi-dimensional reality attestation. Time, location, or environmental conditions are cryptographically attested, not carried as metadata. PKI has one dimension: authority.
Graduated trust assessment. The verifier needs to distinguish between levels of assurance for risk-based policy. PKI is binary.
EXAMPLE A regulatory compliance regime that requires a signed data record to be attested by the issuing device (data dimension), a certified operator (person dimension), an accredited time authority (time dimension), and an environmental sensor (environment dimension) cannot be satisfied by PKI. The multi-dimensional convergence model of SIGNATIF is a hard requirement.
B.4.2 Use cases for which traditional PKI is appropriate
Traditional PKI is appropriate when the following conditions hold:
Server identity authentication. The use case is authenticating a server to a client in a transport-layer session. TLS IETF RFC 8446 with X.509 certificates is the mature, interoperable solution.
Simple key-to-identity binding. The requirement is to bind a public key to an identity (person, organization, or device) for signature or encryption. X.509 certificates provide this directly.
Web PKI ecosystem. The use case requires interoperability with existing web browsers, operating systems, and trust stores. The web PKI ecosystem (CA/Browser Forum Baseline Requirements, CT monitoring) is specific to this domain.
Email security. S/MIME uses X.509 for email signing and encryption. The interoperability ecosystem is mature.
B.4.3 Use cases where either technology is viable
For the following use cases, both PKI and SIGNATIF are technically viable; the choice is a preference decision based on deployment constraints:
Code signing. Both can bind a signing key to a publisher. SIGNATIF adds multi-party attestation and graduated trust; PKI is simpler and more widely deployed.
Document signing. Both can sign documents. SIGNATIF adds scope enforcement and revocation propagation; PKI is interoperable with existing document formats.
Device identity. Both can issue device certificates. SIGNATIF adds threshold signing and challenge-response authenticity; PKI is simpler.
B.5 Hard requirements and preference decisions
The choice between SIGNATIF and PKI can be decomposed into hard requirements (structural properties that one technology provides and the other does not) and preference decisions (properties that both provide or that depend on deployment context).
B.5.1 Decisions driven by hard requirements
The following properties are hard requirements that determine technology choice. If any of these is required, a technology for which the property is outside the design scope does not serve the requirement. Table B.2 lists the hard requirements.
| Required property | SIGNATIF | PKI | Decision driver |
|---|---|---|---|
| Multi-party co-signed artifacts | Provides | Not specified — outside design intent | Hard requirement for SIGNATIF |
| Cryptographic scope enforcement | Provides | Not specified — outside design intent | Hard requirement for SIGNATIF |
| Threshold at every authority level | Provides | Partial — rare in CA practice | Hard requirement for SIGNATIF |
| Transparency as verification requirement | Provides | Partial — mandatory in web PKI only | Hard requirement for SIGNATIF |
| Revocation propagation to artifacts | Provides | Not specified — outside design intent | Hard requirement for SIGNATIF |
| Multi-dimensional attestation | Provides | Not specified — outside design intent | Hard requirement for SIGNATIF |
| Graduated classification labels | Provides | Partial — certificate policy classes | Hard requirement for SIGNATIF |
| Web browser interoperability | Not specified — outside design intent | Provides | Hard requirement for PKI |
| TLS session authentication | Not specified — outside design intent | Provides | Hard requirement for PKI |
B.5.2 Decisions driven by preference
The following properties do not constitute hard requirements; the choice depends on deployment context, ecosystem maturity, or operational preference. Table B.3 lists these properties.
| Property | SIGNATIF | PKI | Consideration |
|---|---|---|---|
| Single-signer document signing | Viable | Viable | PKI preferred for ecosystem interoperability; SIGNATIF preferred if scope enforcement or revocation propagation is desired. |
| Code signing | Viable | Viable | PKI preferred for platform compatibility; SIGNATIF preferred for multi-party attestation or threshold protection. |
| Device identity | Viable | Viable | PKI preferred for simplicity; SIGNATIF preferred for challenge-response authenticity or graduated trust. |
| Internal CA for an organization | Viable | Viable | PKI preferred for existing tooling; SIGNATIF preferred if threshold signing or mandatory transparency is desired. |
B.6 Coexistence
SIGNATIF and PKI are not mutually exclusive. A deployment may use both:
PKI for server authentication and transport-layer security (TLS).
SIGNATIF for artifact attestation, regulatory compliance records, and multi-party signing.
A SIGNATIF end certificate may reference a PKI certificate for the identity dimension, establishing the signer’s organizational identity via PKI while adding SIGNATIF’s scope enforcement and multi-dimensional attestation. This composition is permitted by the format-agnostic binding requirements in 7.2.
B.7 Migration considerations
An organization migrating from PKI to SIGNATIF should consider:
Key reuse. Existing PKI keys may be reused as SIGNATIF end certificate keys, provided the scope is narrowed appropriately.
Certificate mapping. Existing X.509 certificates map to SIGNATIF end certificates. The X.509 subject and extensions provide initial scope and identity information.
Transparency log bootstrapping. A new SIGNATIF deployment starts with an empty transparency log. Existing artifacts may be retroactively logged.
Graduated adoption. An organization may adopt SIGNATIF incrementally — for example, starting with the data dimension only (PKI-compatible) and adding person, time, location, and environment dimensions over time as the living artifact model permits.
Annex C
(normative)
Scheme-maintained registries
C.1 General
A scheme implementing this document (a “scheme”) shall maintain registries for the extensible value spaces used throughout the framework. This document does not prescribe the content of any registry. Each scheme owns and maintains its own registries, defining the specific values recognized within that scheme’s scope of recognition.
This annex specifies which registries a scheme shall maintain, the characteristics each registry shall have, and the registration policy requirements that apply.
C.2 Required registries
A scheme shall maintain at minimum the following registries. The required registries are listed in Table C.1.
| Registry | Purpose | Referenced by |
|---|---|---|
| Trust dimension tag registry | Identifies trust dimension types used in co-signature blocks and verification results | 7.9 |
| Algorithm identifier registry | Identifies signature algorithms recognized by the scheme, with their class (classical, post-quantum, composite), parameter sets, and status | Clause 8 |
| Ceremony type registry | Identifies ceremony types used in ceremony transcripts and deployment manifests | Clause 16 |
| Format profile registry | Identifies signature envelope format profiles recognized by the scheme, with their canonicalization characteristics | 7.4 |
| Scope dimension registry | Identifies scope dimension names used in scope encodings within the scheme | 10.2 |
A scheme may maintain additional registries as needed for its domain.
C.3 Registry characteristics
Each registry maintained by a scheme shall have:
Name. A human-readable name identifying the registry.
Description. A statement of the registry’s purpose and scope.
Entry schema. The fields that each entry shall contain, including any required fields and optional fields.
Registration policy. The criteria and process for adding, modifying, or retiring entries.
Maintainer. The organization or body responsible for maintaining the registry and performing registration decisions.
Publication. A publicly accessible location where the current registry contents are published.
C.4 Registration policy requirements
Each registry’s registration policy shall ensure that:
registrations are technically sound;
proposed entries do not duplicate existing entries;
specifications are sufficiently detailed for independent implementation;
security implications have been assessed;
registrations, modifications, and retirements are publicly recorded with dates and rationale.
The registration policy may designate expert reviewers. The scheme shall document the reviewer qualification criteria.
C.5 Inter-scheme recognition
Two schemes that wish to interoperate shall publish a mapping between their respective registry entries, or shall adopt a common registry. The mechanism for inter-scheme recognition is out of scope of this document; it is a governance decision of the participating schemes.
NOTE A scheme may adopt another scheme’s registry by reference, or may establish a joint registry with other schemes. The framework does not mandate a specific inter-scheme recognition mechanism.
C.6 No mandatory initial values
This document does not prescribe mandatory initial values for any registry. The initial content of each registry is determined by the scheme at establishment time, subject to the scheme’s own governance process. Profiles of this document (see Annex D) may recommend initial values as examples, but such recommendations are informative.
Annex D
(informative)
Sample domain profile: supply-chain provenance
D.1 General
This annex presents a sample profile of the SIGNATIF framework for a supply-chain provenance deployment. It demonstrates how a specific domain configures the SIGNATIF framework into a concrete, implementable system. The profile specifies the algorithm classes, format characteristics, scope dimensions, transparency configuration, threshold parameters, and dimensional attestations used.
This annex is informative. It does not specify requirements. It illustrates how the normative requirements of this document are instantiated for a real deployment.
D.2 Profile identifier
This profile is identified as /profile/supply-chain-provenance. It claims the following conformance classes:
/conf/basic-verifier
/conf/full-verifier
/conf/issuing-authority
/conf/root-authority
/conf/transparency-operator
/conf/mirror
/conf/device-signer
/conf/hierarchical (topology)
At least one format profile from the scheme’s registry
/conf/dimension-data
/conf/dimension-person
/conf/dimension-time
/conf/dimension-location
/conf/multi-dimensional
D.3 Hierarchy mapping
A pharmaceutical supply-chain deployment maps its organizational tiers to the SIGNATIF delegation model as follows. The mapping is given in Table D.1.
| Supply-chain tier | SIGNATIF level | Role | Threshold |
|---|---|---|---|
| Global regulatory body | Root trust authority | Defines the global supply-chain scope; delegates to national authorities | 3-of-5 |
| National drug agency | Delegated trust authority | National regulatory authority; delegates to manufacturers | 2-of-3 |
| Manufacturer QA authority | Delegated trust authority | Production facility quality-assurance signing authority | 1-of-1 or 2-of-3 |
| Batch signing key | End certificate | Per-production-batch key authorized to sign release records | 1-of-1 |
| Signed batch release record | Trusted artifact | The batch data with co-signatures — the deliverable | Primary + co-signatures |
D.4 Algorithms
The deployment uses algorithms from the scheme’s algorithm registry. The selection is a deployment decision; this profile does not mandate specific algorithms. The deployment may define a post-quantum migration trajectory following the three-phase path specified in 8.5.
D.5 Artifact format
The deployment selects a format profile from the scheme’s format profile registry. The selected profile satisfies the binding requirements in 7.2 and the canonicalization characteristics in 7.3. The payload schema is domain-specific, identified by a URI and versioned per 7.6.
D.6 Scope dimensions
The deployment uses the following scope dimensions (non-exhaustive; additional dimensions may be defined by the deployment). The scope dimensions used are listed in Table D.2.
| Dimension | Values | Example |
|---|---|---|
| domain | pharma, food, electronics | Fixed at root |
| subdomain | vaccines, raw-materials, finished-goods | National authority narrows |
| class | Product classes (e.g., {vaccine, tablet, device}) | Manufacturer narrows |
| batch | Batch identifier (e.g., LOT-2026-001) | End certificate narrows to a specific batch |
| conditions | Temperature compliance, chain-of-custody validity | Evaluated at verification time |
D.7 Transparency configuration
The deployment operates a transparency log with the following characteristics (examples; specific configuration is a deployment decision):
append-only Merkle tree with inclusion proofs;
external time anchoring to an independent time source;
gossip between independent mirror operators;
public mirror endpoints published in the deployment manifest.
D.8 Threshold configuration
The deployment uses threshold signing at the regulatory and national levels (examples; specific thresholds are deployment decisions). Example configurations are given in Table D.3.
| Authority | Quorum (example) | Ceremony |
|---|---|---|
| Global regulatory body (RTA) | 3-of-5 | Annual key ceremony; 5 regulatory representatives |
| National drug agency (DTA) | 2-of-3 | National ceremony; 3 authorized officers |
| Manufacturer QA (DTA) | 1-of-1 or 2-of-3 | Facility-dependent |
| Batch signing key (End Cert) | 1-of-1 | Per-batch key generation |
D.9 Dimensional attestation model
Artifacts in this deployment carry the following dimensional attestations (examples; the set of dimensions is extensible). The dimensional attestations are listed in Table D.4.
| Dimension | Attestation source |
|---|---|
| Data | Batch signing key signs the release record |
| Person | QA operator co-signs (“I authorize this batch release”) |
| Time | Time authority anchors the artifact hash to an external time source |
| Location | Location authority co-signs (“produced at facility F”) |
| Environment | Cold-chain sensor co-signs (“temperature was 2-8 C throughout transit”) |
A fully-attested batch release record achieves the highest classification label when all policy-required dimensions are present.
D.10 Sample deployment manifest
The following excerpt illustrates the deployment manifest per the schema in Clause 17:
[deployment]
name = "PharmaSupplyChain-Global"
operator = "GlobalPharmaRegulator"
manifestVersion = 1
mode = "production"
[[tiers]]
name = "global-regulator"
role = "RTA"
threshold = { t = 3, n = 5 }
[[tiers]]
name = "national-agency"
role = "DTA"
threshold = { t = 2, n = 3 }
delegatedBy = "global-regulator"
delegationScope = "subdomain"
[[tiers]]
name = "manufacturer-qa"
role = "DTA"
threshold = { t = 1, n = 1 }
delegatedBy = "national-agency"
delegationScope = "class"
[[tiers]]
name = "batch-key"
role = "EndCertificate"
delegatedBy = "manufacturer-qa"
delegationScope = "batch"
[transparency]
gossip = true
NOTE The algorithms, format profile, and transparency configuration in this manifest reference values from the scheme’s registries, not values prescribed by this document.
D.11 Verification example
A customs inspector verifying a pharmaceutical shipment proceeds as follows:
The shipment carries its provenance artifact (compact encoding per 15.2).
The inspector’s verifier loads the scheme’s trust anchor bundle (offline).
The pipeline runs hard checks: format validity, signature validity, chain integrity, scope narrowing, scope conditions (temperature compliance, chain-of-custody validity), revocation status.
The pipeline runs soft checks: transparency inclusion, time anchor, cross-domain co-signatures (person from QA operator, location from facility authority, environment from cold-chain sensor).
The assigned grade reflects the dimensional coverage. If the grade meets the inspector’s policy minimum, the shipment is accepted.
Annex E
(informative)
Reference technology instantiation
E.1 General
This annex demonstrates SIGNATIF instantiated with a concrete technology stack. It provides implementation-level detail — artifact structure, computation steps, verification examples, and test scenarios — sufficient for an implementer to build a conforming system against this stack. All technology choices are examples; this annex does not mandate them.
The reference stack. The mapping is given in Table E.1.
| SIGNATIF concept | Reference technology |
|---|---|
| Classical signature algorithm | Ed25519 (IETF RFC 8032) |
| Post-quantum algorithm (migration target) | ML-DSA-65 (NIST FIPS 204) |
| Composite signature (transition) | Ed25519 AND ML-DSA-65 (both components verified) |
| Hash function | SHA-256 |
| Signature envelope | JSON Web Signature, compact serialization, detached content (IETF RFC 7515) |
| Canonicalization | JSON Canonicalization Scheme (IETF RFC 8785) |
| Transparency log | Append-only Merkle tree with SHA-256, domain-separated hashing (RFC 6962 convention: 0x00 leaf, 0x01 node) |
| External time anchoring | OpenTimestamps commitment to an external proof-of-work chain |
| Threshold signing | 2-of-3 threshold (reference configuration; specific scheme is a deployment choice) |
| Key encoding | SubjectPublicKeyInfo (SPKI) for public keys |
| Scope condition expression | JSON Logic |
E.2 Canonical payload hash computation
All co-signatures attest the same canonical payload hash. For the reference stack, the computation is:
Take the logical payload as a JSON object.
Apply JSON Canonicalization Scheme (JCS, IETF RFC 8785) to produce a deterministic byte string. JCS sorts object keys lexicographically by UTF-16 code unit, removes insignificant whitespace, encodes numbers in shortest round-trippable representation, and outputs UTF-8.
Compute SHA-256 over the JCS output.
The resulting 32-byte digest is the canonical payload hash.
All co-signers — regardless of which trust dimension they attest — sign this same 32-byte digest. If the payload changes by even one byte after JCS canonicalization, all existing co-signatures break.
E.3 Artifact structure
The following structure illustrates a fully-attested artifact using the reference stack. Field names are shown for the reference stack; deployments using different format profiles may use different structures.
{
"version": "1.0",
"artifact_id": "art-2026-00001",
"payload": {
"batch_id": "LOT-2026-001",
"product": "vaccine-batch-A",
"quantity": 50000,
"release_date": "2026-08-09"
},
"scope": {
"domain": "pharma",
"subdomain": "vaccines",
"class": "vaccine",
"batch": "LOT-2026-001",
"conditions": [
{ ">=": [ { "var": "payload.quantity" }, 10000 ] }
]
},
"canonical_payload_hash": "<base64 SHA-256 of JCS(payload)>",
"co_signatures": [
{
"dimension": "data",
"algorithm": "Ed25519",
"signer_cert_ref": "<transparency-log-seq:12345>",
"signer_pubkey": "<base64 SPKI>",
"signature": "<base64 Ed25519 signature over canonical_payload_hash>"
},
{
"dimension": "person",
"algorithm": "Ed25519",
"signer_cert_ref": "<operator-key-fingerprint>",
"signer_pubkey": "<base64 SPKI>",
"signature": "<base64 Ed25519 signature>"
},
{
"dimension": "time",
"algorithm": "Ed25519",
"signer_cert_ref": "<time-authority-key-fingerprint>",
"external_anchor": "<OpenTimestamps proof bytes, base64>",
"signature": "<base64 Ed25519 signature>"
}
],
"transparency": {
"log_seq": 67890,
"inclusion_proof": {
"leaf_hash": "<base64 SHA-256 of log entry>",
"audit_path": ["<base64 sibling hashes>"],
"tree_head": {
"root_hash": "<base64 Merkle root>",
"tree_size": 100000,
"timestamp": "2026-08-09T12:00:00Z",
"operator_signature": "<base64 Ed25519 signature over tree head>"
}
}
}
}Key fields. The key fields are listed in Table E.2.
| Field | Purpose |
|---|---|
| artifact_id | Unique identifier binding co-signatures to this artifact (replay protection) |
| payload | The logical content all co-signers attest |
| scope | Multi-dimensional authorization boundary with executable conditions |
| canonical_payload_hash | SHA-256 of JCS-canonicalized payload; what all signatures cover |
| co_signatures[] | Array of independent signatures, each tagged with a dimension |
| co_signatures[].dimension | Trust dimension tag from the scheme’s registry |
| co_signatures[].signer_cert_ref | End certificate reference (transparency-log sequence or key fingerprint) |
| co_signatures[].signature | Ed25519 signature over the canonical payload hash |
| transparency | Inclusion proof binding the artifact to the transparency log |
E.4 Living artifact evolution
An artifact may accumulate co-signatures over time. Each revision produces a new transparency log entry:
T0: artifact created with data co-signature only
→ transparency log entry #67890
T1: person co-signature added
→ transparency log entry #67891
(binds: canonical_payload_hash + data + person co-signatures)
T2: time co-signature added
→ transparency log entry #67892
(binds: canonical_payload_hash + data + person + time co-signatures)
The verifier uses the co-signature set from the most recent transparency log entry. The artifact_id binds all co-signatures to the same artifact, preventing replay across different artifacts.
E.5 Verification result examples
The verification pipeline produces an objective coverage report, which the scheme’s classification policy maps to a grade label. The reference stack uses these example labels: unverified, basic, verified, attested, certified, rejected.
Minimal valid artifact (data dimension only, no transparency):
{
"coverage": {
"hard_checks": "pass",
"transparency_included": false,
"time_anchored": false,
"dimensions_verified": ["data"],
"dimension_count": 0,
"independent_roots": 0,
"multi_log_quorum": false,
"paths_found": 1
},
"classified_grade": "unverified",
"downgrades": ["transparency_missing", "time_anchor_absent"]
}With transparency log inclusion:
{
"coverage": {
"hard_checks": "pass",
"transparency_included": true,
"time_anchored": false,
"dimensions_verified": ["data"],
"dimension_count": 0,
"independent_roots": 0,
"multi_log_quorum": false,
"paths_found": 1
},
"classified_grade": "basic",
"downgrades": ["time_anchor_absent"]
}With external time anchor:
{
"coverage": {
"hard_checks": "pass",
"transparency_included": true,
"time_anchored": true,
"dimensions_verified": ["data", "time"],
"dimension_count": 0,
"independent_roots": 0,
"multi_log_quorum": false,
"paths_found": 2
},
"classified_grade": "basic",
"downgrades": []
}With dimensional breadth (person + environment):
{
"coverage": {
"hard_checks": "pass",
"transparency_included": true,
"time_anchored": true,
"dimensions_verified": ["data", "time", "person", "environment"],
"dimension_count": 2,
"independent_roots": 0,
"multi_log_quorum": false,
"paths_found": 4
},
"classified_grade": "verified",
"downgrades": []
}With dimensional breadth + cross-domain diversity:
{
"coverage": {
"hard_checks": "pass",
"transparency_included": true,
"time_anchored": true,
"dimensions_verified": ["data", "time", "person", "location", "environment"],
"dimension_count": 3,
"independent_roots": 1,
"multi_log_quorum": false,
"paths_found": 6
},
"classified_grade": "attested",
"downgrades": []
}With multi-log quorum:
{
"coverage": {
"hard_checks": "pass",
"transparency_included": true,
"time_anchored": true,
"dimensions_verified": ["data", "time", "person", "location", "environment"],
"dimension_count": 3,
"independent_roots": 1,
"multi_log_quorum": true,
"paths_found": 6
},
"classified_grade": "certified",
"downgrades": []
}Failed — revoked authority:
{
"coverage": {
"hard_checks": "fail",
"transparency_included": false,
"time_anchored": false,
"dimensions_verified": [],
"dimension_count": 0,
"independent_roots": 0,
"multi_log_quorum": false,
"paths_found": 0
},
"classified_grade": "rejected",
"failures": [
{
"check": "revocation_status",
"reason": "revoked",
"detail": "data dimension co-signer authority revoked at 2026-08-08T10:00:00Z"
}
],
"downgrades": []
}Failed — scope condition not met:
{
"coverage": {
"hard_checks": "fail",
"transparency_included": false,
"time_anchored": false,
"dimensions_verified": [],
"dimension_count": 0,
"independent_roots": 0,
"multi_log_quorum": false,
"paths_found": 1
},
"classified_grade": "rejected",
"failures": [
{
"check": "scope_conditions",
"reason": "scope_condition_failed",
"detail": "Condition {>=: [{var: payload.quantity}, 10000]} evaluated false (quantity=5000)"
}
],
"downgrades": []
}E.6 Test scenarios
The following scenarios provide implementable test cases. Each specifies the artifact configuration, the verification state, and the expected result. Grade labels shown are for the reference stack’s example classification policy; other schemes may use different labels. Table E.3 lists the scenarios and expected grades.
| Scenario | Configuration | Expected grade | Pass/fail |
|---|---|---|---|
| Minimal valid artifact | Data dimension only, valid chain, valid scope, no transparency, no time | unverified | Pass |
| With transparency | Data dimension, valid chain, transparency inclusion verified | basic | Pass |
| With time anchor | Data dimension, transparency verified, time dimension anchored | basic | Pass |
| With dimensional breadth | Data + person + environment, transparency verified, time anchored | verified | Pass |
| With cross-domain | Data + time + one co-signature from independent root | verified | Pass |
| Broad + cross-domain | Data + person + location + time + one cross-domain co-signature | attested | Pass |
| With multi-log | Attested artifact also included in M-of-K independent logs | certified | Pass |
| Scope widened | Chain has a delegation link where child scope exceeds parent | rejected | Fail (scope_widened) |
| Revoked authority | An authority on the verification path is revoked | rejected | Fail (revoked) |
| Scope condition failed | A scope condition evaluates to false at verification time | rejected | Fail (scope_condition_failed) |
| Invalid signature | A co-signature fails cryptographic validation | rejected | Fail (signature_invalid) |
E.7 Trust anchor bundle format
The reference trust anchor bundle is a signed JSON document:
{
"bundle_version": "2026.08",
"valid_from": "2026-08-01T00:00:00Z",
"valid_until": "2026-12-31T23:59:59Z",
"roots": [
{
"name": "PharmaRegulator-Global",
"aggregate_key": "<base64 Ed25519 public key>",
"fingerprint": "<hex SHA-256 of SPKI>",
"quorum": { "t": 3, "n": 5 }
}
],
"transparency_logs": [
{
"name": "PharmaLog-Primary",
"operator_key": "<base64 Ed25519 public key>",
"endpoint": "https://log.pharma-regulator.example"
}
],
"bundle_signature": "<base64 threshold signature over JCS(bundle)>"
}The verifier confirms the bundle_signature against the root aggregate key and checks the valid_until date.
E.8 Scope condition expressions
The reference stack uses JSON Logic for scope conditions. JSON Logic is deterministic, Turing-incomplete, and widely implemented. Table E.4 lists the scope condition expressions.
| Purpose | Expression |
|---|---|
| Value within range | {">=": [{"var": "payload.quantity"}, 10000]} |
| String equality | {"==": [{"var": "payload.product"}, "vaccine-batch-A"]} |
| Certification valid at time | {">=": [{"var": "calibration.expiry"}, {"var": "signature_time"}]} |
E.9 Challenge-response protocol
For device signers, the reference challenge-response protocol:
The verifier generates a random 256-bit nonce and sends it with a freshness window (e.g., 30 seconds).
The device produces a fresh artifact containing the nonce in its payload, signs it under its end certificate key, and returns it.
The verifier runs the normal pipeline, additionally checking that the nonce in the payload matches the challenge and the artifact was produced within the freshness window.
Annex F
(informative)
Cross-technology interoperability
F.1 General
Different SIGNATIF deployments may use different algorithms, formats, and transparency log implementations. This annex describes the mechanisms by which such heterogeneous deployments can verify each other’s artifacts.
The interoperability model is based on three principles:
Canonical payload hash agreement. Co-signatures from different deployments attest the same canonical payload hash, regardless of the serialization format each deployment uses internally.
Registry mapping. Deployments publish mappings between their respective registry entries, enabling cross-deployment interpretation of algorithm identifiers, dimension tags, and ceremony types.
Anchor exchange. Deployments exchange trust anchor bundles through bilateral or multilateral governance agreements, enabling cross-deployment chain verification.
F.2 Interoperability scenario
Deployment A uses SM2 signatures, XMLDSig format, and SM3 hashing. Deployment B uses Ed25519 signatures, JWS format, and SHA-256 hashing. The following describes how Deployment B’s verifier can verify an artifact from Deployment A.
F.3 Canonical payload hash bridge
The canonical payload hash is the point of convergence. Although Deployment A canonicalizes using Exclusive C14N (XML) and Deployment B canonicalizes using JCS (JSON), both deployments agree on a common canonical payload hash for the same logical content.
The bridge mechanism:
The artifact carries a canonical_payload_hash field — a hash of the logical content in a deployment-neutral form.
Each co-signature attests this hash, regardless of the signer’s internal format.
Cross-deployment co-signing requires the participating deployments to agree on the canonical payload hash before signing. This agreement is established out-of-band (e.g., through a shared payload schema and a neutral hash computation).
NOTE In practice, cross-format canonical payload agreement requires the deployments to share a common logical content model (e.g., a shared JSON schema or a shared data dictionary) from which each deployment computes its format-specific canonicalization. The deployments agree on the hash of the logical content model, not on the format-specific canonical bytes.
F.4 Registry mapping
Each deployment maintains its own scheme registry (see Annex C). To enable cross-deployment verification, deployments publish a registry mapping. The mapping is published as shown in Table F.1.
| Concept | Deployment A value | Deployment B value |
|---|---|---|
| Classical signature algorithm | SM2 (GM/T 0003-2012) | Ed25519 (RFC 8032) |
| Hash function | SM3 (GM/T 0005-2010) | SHA-256 |
| Format profile | /conf/format-xmldsig | /conf/format-jws |
| Data dimension tag | data | data |
| Person dimension tag | operator | person |
| Time dimension tag | timestamp | time |
The mapping is a governance document published by both deployments. A verifier from Deployment B encountering an artifact from Deployment A uses the mapping to:
translate dimension tags from A’s vocabulary to B’s;
identify which algorithm to use for signature validation;
determine which hash function was used for the canonical payload and transparency log entries.
F.5 Transparency log interoperability
Different deployments may use different transparency log constructions. To enable cross-deployment inclusion proof verification, the following interoperability profile is recommended:
Shared hash function. Both deployments’ transparency logs need to use the same hash function for Merkle tree construction (e.g., both use SHA-256). If different hash functions are used, cross-deployment inclusion proof verification is not possible without a hash-function bridge (which does not exist in general).
Shared domain separation. Both deployments need to use compatible domain separation (e.g., RFC 6962’s 0x00/0x01 prefix convention or equivalent).
Log head format. Both deployments need to publish log heads in a common format containing: root hash, tree size, timestamp, and operator signature. The signature algorithm may differ (verified via registry mapping).
Mirror access. Each deployment needs to operate at least one publicly accessible mirror that serves inclusion proofs in the common format.
F.6 Trust anchor exchange
Cross-deployment verification requires each deployment’s verifier to hold the other deployment’s root anchor. The exchange mechanism:
Deployment A publishes its trust anchor bundle (see Annex E for format example).
Deployment B’s governance body verifies the bundle (confirms root aggregate key, quorum parameters, and transparency log operator key through out-of-band channels).
Deployment B adds Deployment A’s root anchor to its verifier’s extended trust anchor bundle, with a cross-recognition annotation.
The cross-recognition annotation records: the mapping effective date, the registry mapping reference, and the governance agreement reference.
F.7 Cross-verification procedure
A verifier from Deployment B verifying an artifact from Deployment A:
Load mappings. Load the A-to-B registry mapping and the extended trust anchor bundle containing A’s root anchor.
Parse artifact. Parse the artifact using A’s format profile (XMLDSig). If the verifier does not support XMLDSig, it may request a format-translated representation from an A-operated gateway, or use the embedded canonical payload hash directly.
Verify signatures. For each signature, use the registry mapping to identify the algorithm (SM2). Validate the SM2 signature against the canonical payload hash using the verifier’s SM2 implementation. Validate the signer’s chain to A’s root anchor in the extended bundle.
Verify transparency. Fetch the inclusion proof from A’s transparency log or mirror. Validate it using the shared hash function and domain separation. Confirm the log head is observed by the gossip quorum.
Translate dimensions. Use the registry mapping to translate A’s dimension tags to B’s vocabulary. Compute dimensional coverage and grade using the translated tags.
Compute grade. Apply the scheme’s classification policy from 13.5 using the translated dimensional coverage and the cross-domain root count (A’s root is an independent root from B’s perspective).
F.8 Minimum interoperability baseline
For cross-deployment verification to be possible, the following minimum conditions need to be met by both deployments:
Both deployments need to support at least one common hash function for transparency log construction and canonical payload hashing.
Both deployments need to publish registry mappings for all concepts used in cross-deployment artifacts.
Both deployments need to operate publicly accessible transparency log mirrors.
Both deployments need to exchange trust anchor bundles through verified governance channels.
Both deployments need to use compatible dimension tag vocabularies (via registry mapping) for all dimensions present on cross-deployment artifacts.
NOTE If two deployments cannot agree on a common hash function, a hash-function bridge (computing the same logical content under both hash functions and carrying both hashes) may be used. This is a deployment-level decision, not a requirement of this document.
F.9 Limitations
Cross-technology interoperability has inherent limitations:
No zero-knowledge cross-verification. The verifier must implement (or have access to) every algorithm used in the artifact’s signatures. A verifier that does not implement SM2 cannot verify SM2 signatures, even with a registry mapping.
Format translation is lossy. Translating between XMLDSig and JWS representations may lose format-specific metadata (e.g., XML namespace information). Cross-deployment artifacts should carry format-neutral metadata whenever possible.
Different threshold schemes are not interoperable. A threshold signature produced under FROST cannot be verified by an implementation that only supports BLS threshold signatures. Cross-deployment threshold signatures require both deployments to use the same threshold scheme for the cross-domain co-signature.
These limitations mean that full cross-technology interoperability typically requires a bilateral or multilateral agreement that specifies the common technology subset both deployments support for cross-deployment artifacts.
Annex G
(informative)
Composition with W3C Verifiable Credentials
G.1 General
W3C Verifiable Credentials (VC) W3C Recommendation: Verifiable Credentials Data Model 1.1 provide an internationally standardized credential model; the claims here address the VC Data Model 1.1 cited above; VC 2.0 (W3C Recommendation: Verifiable Credentials Data Model 2.0) extends the model with multi-proof and status-list machinery that narrows but does not close these gaps. This annex describes how the two compose. It does not specify requirements. VC documents are JSON-LD documents (W3C Recommendation: JSON-LD 1.1).
G.2 Concept mapping
Table G.1 maps the W3C VC concepts to SIGNATIF mechanisms.
| W3C VC concept | SIGNATIF equivalent | Relationship |
|---|---|---|
| Verifiable Credential | trusted artifact | A VC is a payload; a SIGNATIF artifact wraps and attests it with multi-dimensional co-signatures. |
| Issuer | end certificate holder | The VC issuer’s signing key is authorized by a SIGNATIF delegation chain. |
| proof | Co-signature (data dimension) | The VC proof is the primary attestation; SIGNATIF co-signatures add independent dimension attestations on the same content. |
| credentialSubject | Payload content | The claims about the subject that all co-signers attest. |
| Verifiable Presentation | (no SIGNATIF equivalent) | A VP can wrap a SIGNATIF artifact, adding holder binding. |
| Credential revocation | Revocation propagation | VC revocation invalidates the credential; SIGNATIF revocation propagates to condition-dependent artifacts. |
| (no equivalent) | Cryptographic scope | SIGNATIF adds machine-checkable, multi-dimensional scope enforced at every delegation link. |
| (no equivalent) | Coverage report + classification | SIGNATIF adds objective dimensional coverage assessment and scheme-defined classification. |
| (no equivalent) | Transparency logging | SIGNATIF requires every artifact in a recognized transparency log; VC has no mandatory transparency. |
G.3 Composition pattern 1: VC as SIGNATIF payload
The VC JSON object is the logical payload. The SIGNATIF artifact wraps it, replacing the VC’s single proof with SIGNATIF multi-dimensional co-signatures:
{
"version": "1.0",
"artifact_id": "art-2026-00001",
"payload": {
"@context": ["https://www.w3.org/2018/credentials/v1"],
"id": "urn:uuid:batch-2026-001",
"type": ["VerifiableCredential", "BatchReleaseCredential"],
"issuer": "did:web:pharmaco.example",
"issuanceDate": "2026-08-09T12:00:00Z",
"credentialSubject": {
"batchId": "LOT-2026-001",
"product": "vaccine-batch-A",
"quantity": 50000
}
},
"canonical_payload_hash": "<SHA-256 of JCS(payload)>",
"co_signatures": [
{
"dimension": "data",
"algorithm": "Ed25519",
"signer_cert_ref": "<end certificate of the manufacturer key>",
"signature": "<signature over the canonical payload>"
},
{
"dimension": "person",
"algorithm": "Ed25519",
"signer_cert_ref": "<end certificate of the certified operator key>",
"signature": "<signature over the canonical payload>"
},
{
"dimension": "time",
"algorithm": "Ed25519",
"signer_cert_ref": "<end certificate of the time authority key>",
"signature": "<signature over the canonical payload>"
}
],
"transparency": {
"log_seq": 67890,
"inclusion_proof": {
"leaf_hash": "<base64 SHA-256 of log entry>",
"audit_path": ["<base64 sibling hashes>"],
"tree_head": {
"root_hash": "<base64 Merkle root>",
"tree_size": 100000,
"timestamp": "2026-08-09T12:00:00Z",
"operator_signature": "<base64 Ed25519 signature over tree head>"
}
}
}
}In this pattern, the VC proof field is omitted — SIGNATIF co-signatures serve as the proof. The VC data model is preserved (@context, type, issuer, credentialSubject); only the proof mechanism changes from single-signer to multi-dimensional convergence.
G.4 Composition pattern 2: SIGNATIF co-signatures as VC proofs
Each SIGNATIF dimension attestation is expressed as a VC proof entry. The artifact is a standard VC with multiple proofs:
{
"@context": ["https://www.w3.org/2018/credentials/v1",
"https://signatif.org/contexts/v1"],
"id": "urn:uuid:batch-2026-001",
"type": ["VerifiableCredential", "BatchReleaseCredential"],
"issuer": "did:web:pharmaco.example",
"issuanceDate": "2026-08-09T12:00:00Z",
"credentialSubject": {
"batchId": "LOT-2026-001",
"product": "vaccine-batch-A",
"quantity": 50000
},
"proof": [
{
"type": "SignatifDataSignature",
"verificationMethod": "did:web:pharmaco.example#device-key",
"proofPurpose": "assertionMethod",
"proofValue": "<Ed25519 signature>",
"signatif_dimension": "data"
},
{
"type": "SignatifPersonSignature",
"verificationMethod": "did:web:pharmaco.example#operator-key",
"proofPurpose": "assertionMethod",
"proofValue": "<Ed25519 signature>",
"signatif_dimension": "person"
},
{
"type": "SignatifTimeAttestation",
"verificationMethod": "did:web:time-authority.example#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "<Ed25519 signature>",
"signatif_dimension": "time"
}
]
}In this pattern, a standard VC verifier validates each proof independently. A SIGNATIF-aware verifier additionally computes the coverage report and applies the scheme’s classification policy. This is the most interoperable pattern — VC-only systems continue to work; SIGNATIF verifiers get the full convergence assessment.
NOTE The SIGNATIF proof types (SignatifDataSignature, etc.) and the signatif_dimension field are scheme-defined. The scheme registers them in its format profile registry. The W3C VC proof format extension mechanism supports custom proof types.
G.5 Composition pattern 3: Verifiable Presentation wrapping SIGNATIF artifact
A holder creates a Verifiable Presentation that wraps a SIGNATIF artifact:
{
"@context": ["https://www.w3.org/2018/credentials/v1"],
"type": ["VerifiablePresentation"],
"verifiableCredential": [
{
"type": ["VerifiableCredential", "SignatifArtifact"],
"credentialSubject": {
"batchId": "LOT-2026-001",
"product": "vaccine-batch-A",
"quantity": 50000
},
"proof": [
{
"type": "SignatifDataSignature",
"verificationMethod": "did:web:pharmaco.example#device-key",
"proofPurpose": "assertionMethod",
"proofValue": "<Ed25519 signature>",
"signatif_dimension": "data"
},
{
"type": "SignatifTimeAttestation",
"verificationMethod": "did:web:time-authority.example#key-1",
"proofPurpose": "assertionMethod",
"proofValue": "<Ed25519 signature>",
"signatif_dimension": "time"
}
]
}
],
"proof": {
"type": "Ed25519Signature2018",
"verificationMethod": "did:key:holder...",
"proofValue": "<holder signature>"
}
}The holder binds themselves to the presentation (standard VC holder binding). The SIGNATIF co-signatures inside the credential provide the trust convergence assessment. Selective disclosure mechanisms (e.g., BBS+ signatures) can be combined with SIGNATIF co-signatures for privacy-preserving presentations.
G.6 What SIGNATIF adds to the VC data model
VC provides tamper-evidence, issuer identification, and claims structure. SIGNATIF adds the trust infrastructure layer that VC does not specify:
Delegation hierarchy with scope enforcement. VC identifies the issuer but does not specify the chain of authority from root to issuer, nor machine-checkable scope constraints. SIGNATIF adds a delegation chain with monotonic scope narrowing enforced at every link.
Multi-dimensional convergence. VC supports one proof (or multiple proofs, but with no convergence assessment model). SIGNATIF adds independent dimension attestations (data, person, time, location, environment, and extensible others) with a coverage report and scheme-defined classification.
Threshold protection. VC issuers use single keys. SIGNATIF requires threshold at every authority level, preventing single-key compromise.
Mandatory transparency. VCs can be issued without any public record. SIGNATIF requires every artifact in a recognized transparency log with inclusion proofs as a verification input.
Trust lifecycle. VC revocation invalidates the credential. SIGNATIF revocation propagates to condition-dependent artifacts, including scope condition withdrawal — revoking trust when the real-world conditions that made the artifact trustworthy no longer hold.
Graduated, reproducible assessment. VC verification is binary (valid or invalid). SIGNATIF produces an objective coverage report that the scheme’s classification policy maps to domain-specific grade labels.
G.7 Two trust models: recognition claims and delegated authority
A trust model built on verifiable credentials typically establishes issuer trust through recognition credentials: an anchor issues a credential asserting that an organization was recognized under an arrangement at a given time, the recognized organization issues credentials of its own, and a verifier walks the recognition links at verification time to decide whether to accept an issuer’s credential. In this model, a link in the trust chain is a claim about an issuer’s standing.
The model specified in this document establishes issuer trust through cryptographic delegation: the root authority delegates signing authority to a key, narrowed to a scope, and the delegation is enforced by verification itself. In this model, a link in the trust chain is delegated authority: an artifact outside the delegated scope does not verify, regardless of any claim made about the issuer’s standing (Clause 10).
Table G.2 summarizes the consequences of the difference.
| Property | Recognition-chain model | Delegated-authority model (this document) |
|---|---|---|
| A trust link is | A signed claim about an issuer’s standing | Delegated signing authority, narrowed by scope (Clause 10) |
| Bound on issuer authority | The verifier compares each artifact against the recognition claims after issuance | Scope is enforced at verification; an out-of-scope artifact does not verify (Clause 10, 10.4) |
| Compromise of an anchor key | Forges recognition at will; unbounded within the model | A threshold quorum is required at every authority level (Clause 9) |
| Covert issuance | Possible; credentials carry no public-record requirement | Detectable by construction; transparency log inclusion is a verification requirement (Clause 12) |
| Which copy of a record governs | Unsettled; independently fetched documents may disagree | The log’s provable history governs over any presented copy (Clause 12) |
| Reach of revocation | The revoked credential | Every artifact transitively bound to the revoked state (11.5) |
| Verification posture | Online: identifier resolution and status retrieval | Offline-capable: anchor bundle, embedded chains, cached state (6.5) |
| Assessment result | Binary acceptance of the issuer chain | Coverage report and scheme classification (13.5) |
Both models are sound engineering for their respective questions. The recognition model answers who is this organization and what is it recognized for: accreditation registers, mutual-recognition listings, and institutional directories are natural applications, and the verifiable-credentials ecosystem serves them well. The delegated model answers may this key perform this act, and can the act be audited afterwards: regulated artifact issuance falls in this class, because a regulator must bound issuer authority cryptographically, detect covert issuance, and propagate revocation to everything issued under a withdrawn state. These obligations follow from the regulatory role, not from a deficiency of the credential model.
The models compose rather than compete. A recognition credential can be carried as the identity dimension of a SIGNATIF artifact, and the composition patterns above allow verifiable-credentials infrastructure to present artifacts whose authority, transparency, and revocation remain in the delegated model. What each side of such a composition still has to agree is recorded in Annex I.
G.8 Adoption paths
Organizations already using VCs can adopt SIGNATIF incrementally:
Add dimensions. Keep the existing VC issuance pipeline. Add person, time, or environment co-signatures as additional VC proofs (pattern 2). The existing VC verifier continues to work; SIGNATIF-aware verifiers get the coverage report.
Add scope and transparency. Wrap the VC in a SIGNATIF artifact (pattern 1). Add scope enforcement and transparency logging. The VC payload is unchanged; the trust infrastructure is added around it.
Full SIGNATIF deployment. Issue SIGNATIF artifacts natively, using VC as the payload format (pattern 3 with native SIGNATIF co-signatures). This gives the full feature set: scope, threshold, transparency, convergence, revocation propagation, and condition lifecycle.
NOTE SIGNATIF does not replace the W3C VC data model. The two standards operate at different layers: VC defines the credential data model and proof verification; SIGNATIF defines the trust infrastructure (delegation, scope, convergence, transparency, lifecycle). Organizations can use VC for data modeling and SIGNATIF for trust infrastructure simultaneously.
Annex H
(informative)
Composition with the EU Digital Product Passport
H.1 General
The EU Ecodesign for Sustainable Products Regulation Regulation (EU) 2024/1781 establishes the Digital Product Passport (DPP): structured product data for regulated goods, a data carrier on the product, and a decentralized registry, with product-group requirements arriving through delegated acts. Credential-based representations of DPP data are under evaluation in the European standardization program.
This annex describes how a DPP scheme and the SIGNATIF framework compose. The DPP data model, product-group requirements, and delegated acts are external to this document; nothing in this annex specifies or anticipates them. A DPP deployment is a scheme in the sense of Annex C: it maintains registries, defines scope dimensions and classification policies, and claims conformance classes. This annex is informative. It does not specify requirements.
H.2 Concept mapping
Table H.1 maps the EU DPP concepts to SIGNATIF mechanisms.
| EU DPP concept | SIGNATIF equivalent | Relationship |
|---|---|---|
| DPP record (structured product data) | trusted artifact payload | The DPP data model for a product group is the payload; SIGNATIF wraps and attests it with multi-dimensional co-signatures over the canonical payload. |
| Data carrier (QR code on the product) | Barcode and passport delivery (15.2, 15.3) | The carrier requirements — self-containment, version identification, error correction — are those of Clause 15; a connected verifier may instead resolve a compact reference. |
| DPP registry | transparency logs with mirrors | Registry function is met by log operators and mirrors; inclusion in M of K independent logs satisfies the multi-log attestation quorum, so no single registry operator controls the record. |
| Unique product identifier | Artifact identifier and version | The product identifier binds to the artifact identifier; successive DPP versions follow the version compatibility rules of the artifact format. |
| Economic operator | delegated trust authorities and end certificate holders | Operators hold scoped signing authority delegated from the scheme root; the scope narrows to product groups and roles. |
| Market surveillance authority | Verifier with an acceptance policy | Inspection verifies offline from the trust anchor bundle; the acceptance policy encodes the surveillance risk threshold, and the classification label carries the graded evidence. |
| Operator registration withdrawal | Revocation propagation (11.5) | Withdrawing an operator’s recognition revokes its authority state and propagates to every passport artifact transitively bound to it. |
| Decade-plus product lifetimes | Algorithm agility (19.4) | Passports signed classically migrate through composite to post-quantum-only phases on a published schedule without re-issuing the trust graph. |
H.3 Composition pattern 1: DPP record as SIGNATIF payload
The DPP record for a product group is the logical payload. The SIGNATIF artifact wraps it; each dimension attestation co-signs the same canonical payload:
{
"version": "1.0",
"artifact_id": "dpp-2026-00001",
"payload": {
"product_group": "textiles",
"unique_product_identifier": "urn:dpp:eu:abc-manufacturing:sku-4711",
"material_composition": { },
"carbon_footprint_declared": "in-development",
"economic_operator_id": "urn:eu:eop:vat:DE123456789"
},
"co_signatures": [
{ "dimension": "authority", "signer": "end-certificate:operator-key" },
{ "dimension": "time", "signer": "time-key:eu-time-authority" },
{ "dimension": "location", "signer": "location-key:plant-registry" }
],
"transparency": { "logs": ["log-a", "log-b"], "quorum": "2-of-3" }
}Fields shown are illustrative; the payload schema belongs to the DPP scheme’s registry, not to this document.
H.4 Composition pattern 2: DPP data carrier
A DPP data carrier on the product is a SIGNATIF barcode or passport in the sense of Clause 15:
Self-contained carriers hold the artifact or its passport — identifier, key fingerprint, scope summary, validity period — with error correction matched to the scanning environment.
Where the artifact exceeds carrier capacity, the carrier holds a compact reference that a connected verifier resolves from a transparency log or mirror on first encounter and caches.
Offline inspection verifies from the carrier and the verifier’s trust anchor bundle without contacting any registry.
H.5 Composition pattern 3: DPP registry as multi-operator transparency
The decentralized-registry intent of the DPP is met by the transparency infrastructure of Clause 12:
Multiple independent log operators record passport issuance; the scheme’s federated trust authority requires inclusion in M of K logs.
Mirrors replicate log state through gossip, giving every economic operator and surveillance authority third-party evidence of what was issued, independent of any single operator.
Inclusion proofs anchor each passport artifact to its log entries; a verifier’s cached tree heads suffice for offline re-verification within the freshness window.
H.6 What SIGNATIF adds to the DPP data model
Table H.2 summarizes the concerns the framework addresses beyond the DPP data model itself.
| Concern | SIGNATIF mechanism |
|---|---|
| Who may issue for which product group | Cryptographic authorization scope narrowing at every delegation link |
| Evidence quality at inspection | Objective coverage report and graduated classification label |
| Registry capture and avoidance | Mandatory transparency inclusion with M-of-K multi-log quorum |
| Withdrawal of an operator’s recognition | Threshold-gated revocation propagating to bound artifacts |
| Verification without registry access | Offline verification from the trust anchor bundle |
| Long-lived products | Published classical-to-composite-to-post-quantum migration |
H.7 Adoption paths
A DPP scheme may adopt incrementally:
Start with the authority dimension only — issuer chains, scope narrowing, transparency inclusion — which is PKI-like and sufficient for issuance accountability.
Add the time and location dimensions as attestation sources become available, raising dimensional coverage and labels.
Introduce multi-root cross-domain co-signatures when several economic operators or notified bodies attest the same passport.
Migrate algorithm classes per the deployment’s declared migration phase as product lifetimes extend beyond the classical-only horizon.
NOTE Delegated acts under Regulation (EU) 2024/1781 continue to define DPP data models, carriers, and registry interfaces. A conforming DPP scheme tracks those external definitions in its registries; the composition described here does not depend on their final form.
Annex I
(informative)
What must be agreed
This annex records what has to be agreed — by a single arrangement, across arrangements, and infrastructure-wide — for independent trust infrastructures to interoperate, and where this document addresses each item. It is adapted from the harmonisation analysis of the Verifiable credentials for the quality infrastructure exploration2), which implemented a three-branch trust graph (metrology, accreditation, legal metrology) end to end and documented every interoperability obstacle it met.
I.1 Per arrangement
Within one scheme, the deploying arrangement agrees:
One cryptosuite, and one canonical form. Addressed by 7.3 (canonical payload determinism) and Clause 8 (the registry names what is recognized).
One protocol for asking, not just one format for answering. Delivery of a credential to its subject, and presentation to a verifier, are conversations. Addressed by 15.7.
One identifier method, and an agreed meaning for resolving it. The scheme declares its identifier method; cross-identifier meaning is the cross-arrangement tier below.
How a chain crosses from one arrangement into the other. Addressed by cross-domain co-signatures (7.7) and multi-path verification (6.4 for path enumeration): the chains compose at the artifact, not by cross-certification of the roots.
What a status value means, not how it is encoded. Addressed by 11.3: the profile assigns the consequence; the encoding carries the value.
What the anchors’ identifiers are, and how a verifier learns them. Addressed by the trust anchor bundle (6.5) and its versioned, out-of-band distribution.
What a document authorises, as distinct from what it attests. A type evaluation attests; the legal permission to use the instrument comes from the competent authority of each jurisdiction. A scheme profile shall state the authorisation semantics of each credential type it defines, so a verifier never reads an attestation as a licence.
What identifies a type, rather than an instrument. Addressed by the model and serial scope dimensions (Table 72): the type identity is a scope dimension of its own, narrowed independently of the individual instrument.
I.2 Across arrangements
Between arrangements that want to recognise each other:
Whose timestamps everybody accepts. Addressed by the time dimension (7.9.3) and external, irrefutable anchoring: the anchored commitment is accepted regardless of whose clock produced it.
Which copy governs. Addressed by the transparency log as the record of what was true (Clause 12): the log’s history, provable by consistency proof, governs over any presented copy.
How long an identifier goes on meaning what it means. Identifier longevity is an institutional commitment the framework cannot create; the manifest declares the operator’s retention policy, and long-term verification (archival re-signing) is specified in the key-lifecycle clause.
A log of what was true, not a document saying what is true. This is the transparency log’s reason for existing (Clause 12), including the by-hash index by which a verifier confirms every certificate on a path.
Who still serves the documents a verification reads. Dependency documents (evaluation reports, calibration states) must remain fetchable for the artifact’s lifetime; the hash-binding model (11.4) lets a verifier hold the digest, but the serving obligation is an operational commitment declared in the manifest.
I.3 Infrastructure-wide
For the discipline as a whole:
One digital representation of the SI. Unit authority is outside this document’s scope; schemes reference a common unit authority so quantity values compare.
Machine-actionable requirements, in the instrument standard itself. When the Recommendation carries its requirements machine-readably, the scope condition language (10.4) evaluates against them directly rather than against a transcribed form.
A certificate format with international standing. The purpose of this document: a format any conforming verifier can check offline.
Measurand and quantity identifiers. Shared identifiers for measurands and quantities, so a certified capability and a claimed measurement name the same thing.
How uncertainty travels, dependencies included. At the calibration tier, uncertainty propagation across dependency chains is a metrological concern this framework carries (as signed measurement content) but does not compute; the state-binding model preserves the dependency structure a GUM propagation would need.
I.4 Reading of the tiers
The pattern across the tiers: the per-arrangement items are profile decisions this document’s requirements already name; the cross-arrangement items are what the transparency log, the anchoring model, and the co-signature composition exist to settle; the infrastructure-wide items are institutional commitments no framework can create, only declare. A scheme that claims conformance to this document has answered the first tier by construction, and has the machinery to answer the second; the third tier is the standards and institutional work that remains genuinely open.
Bibliography
[1] ISO 3166-1:2020, Codes for the representation of names of countries and their subdivisions — Part 1: Country code
[2] ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules
[3] ISO 22739:20203) , Blockchain and distributed ledger technologies — Vocabulary
[4] ISO/IEC 7064:2003, Information technology — Security techniques — Check character systems
[5] ISO/IEC 9594-8:2020, Information technology — Open systems interconnection — Part 8: The Directory: Public-key and attribute certificate frameworks
[6] ISO/IEC 11770, Information technology — Security techniques — Key management
[7] ISO/IEC 14888, Information technology — Security techniques — Digital signatures with appendix
[8] ISO/IEC 18031:2025, Information technology — Security techniques — Random bit generation
[9] ISO/IEC 18045:2026, Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Requirements and methodology for IT security evaluation
[10] ISO/IEC 19790:2025, Information security, cybersecurity and privacy protection — Security requirements for cryptographic modules
[11] ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements
[12] OpenTimestamps, Scalable, Trustless, Distributed Timestamping, OpenTimestamps specification
[13] GM/T 0003-2012, SM2 Elliptic Curve Public Key Cryptography Algorithm, Chinese cryptographic standard
[14] GM/T 0005-2010, SM3 Cryptographic Hash Algorithm, Chinese cryptographic standard
[15] JSON Schema Specification (Draft 7), IETF Internet-Draft, 2018
[16] PKCS #10 v1.7, Certification Request Syntax Specification, RFC 2986, IETF, 2000
[17] PKCS #11 v3.0, Cryptographic Token Interface Standard, OASIS, 2020
[18] BIP 340, Taproot: Schnorr Signatures for SegWit v1, Bitcoin Improvement Proposal, 2020
[19] Regulation (EU) 2024/1183, Establishing the European Digital Identity Framework, European Parliament and Council, 2024
[20] Regulation (EU) 2024/1781, Ecodesign for Sustainable Products Regulation, European Parliament and Council, 2024
[21] IETF RFC 39864) , BERNERS-LEE, T., R. FIELDING and L. MASINTER. Uniform Resource Identifier (URI): Generic Syntax. Internet standard. RFC Series
[22] IETF RFC 49495) , SHIREY, R. Internet Security Glossary, Version 2. Informational. RFC Series
[23] IETF RFC 52806) , COOPER, D., S. SANTESSON, S. FARRELL, S. BOEYEN, R. HOUSLEY, W. POLK and INTERNET ENGINEERING TASK FORCE. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Proposed standard. RFC Series
[24] IETF RFC 69607) , SANTESSON, S., M. MYERS, R. ANKNEY, A. MALPANI, S. GALPERIN, C. ADAMS and INTERNET ENGINEERING TASK FORCE. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP. Proposed standard. RFC Series
[25] IETF RFC 69628) , LAURIE, B., A. LANGLEY and E. KASPER. Certificate Transparency. Experimental. RFC Series
[26] IETF RFC 75159) , JONES, M., J. BRADLEY, N. SAKIMURA and INTERNET ENGINEERING TASK FORCE. JSON Web Signature (JWS). Proposed standard. RFC Series
[27] IETF RFC 803210) , JOSEFSSON, S. and I. LIUSVAARA. Edwards-Curve Digital Signature Algorithm (EdDSA). Informational. RFC Series
[28] IETF RFC 815211) , SCHAAD, J. and INTERNET ENGINEERING TASK FORCE. CBOR Object Signing and Encryption (COSE). Proposed standard. RFC Series
[29] IETF RFC 839112) , HUELSING, A., D. BUTIN, S. GAZDAG, J. RIJNEVELD and A. MOHAISEN. XMSS: eXtended Merkle Signature Scheme. Informational. RFC Series
[30] IETF RFC 844613) , RESCORLA, E. and INTERNET ENGINEERING TASK FORCE. The Transport Layer Security (TLS) Protocol Version 1.3. Proposed standard. RFC Series
[31] IETF RFC 855414) , MCGREW, D., M. CURCIO and S. FLUHRER. Leighton-Micali Hash-Based Signatures. Informational. RFC Series
[32] IETF RFC 878515) , RUNDGREN, A., B. JORDAN and S. ERDTMAN. JSON Canonicalization Scheme (JCS). Informational. RFC Series
[33] IETF RFC 894916) , BORMANN, C., P. HOFFMAN and INTERNET ENGINEERING TASK FORCE. Concise Binary Object Representation (CBOR). Internet standard. RFC Series
[34] IETF RFC 916217) , LAURIE, B., E. MESSERI, R. STRADLING and INTERNET ENGINEERING TASK FORCE. Certificate Transparency Version 2.0. Experimental. RFC Series
[35] NIST FIPS 204, NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Module-Lattice-Based Digital Signature Standard. Final
[36] NIST FIPS 205, NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Stateless Hash-Based Digital Signature Standard. Final
[37] NIST FIPS 186-4, NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Digital Signature Standard (DSS). Version Revision 4. Final
[38] NIST SP 800-57pt1r5, BARKER, E. Recommendation for Key Management — Part 1 – General. Version Revision 5. Final
[39] NIST SP 800-131Ar2, BARKER, E. and A. ROGINSKY. Transitioning the Use of Cryptographic Algorithms and Key Lengths. Version Revision 2. Final
[40] W3C Recommendation: Exclusive XML Canonicalization Version 1.0, W3C, 2002
[41] W3C Recommendation: JSON-LD 1.1, W3C, 2020
[42] W3C Recommendation: Verifiable Credentials Data Model 1.1, W3C, 2022
[43] W3C Recommendation: Verifiable Credentials Data Model 2.0, W3C, 2025
[44] W3C Recommendation: XML Signature Syntax and Processing Version 2.0, W3C, 2013