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.

The following notation is used throughout this document. The notation is summarized in .

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 > syntax.

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.

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. lists the eight properties by letter.

The principles are grouped thematically below. Each principle appears in at least one requirements class defined in .

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 for use-case suitability guidance.

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.

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). defines the mandatory-to-implement baseline by conformance class.

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 .

The following core requirements classes address the primary roles in the trust infrastructure. Dependencies between classes are acyclic. lists the core requirements classes.

A trust infrastructure deployment shall conform to at least one topology profile. A deployment may conform to more than one. lists the topology profiles.

A trusted artifacttrusted artifact may carry dimension attestationdimension attestations from one or more trust dimensiontrust 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 and claimed by implementations. lists the initially defined dimension profiles.

This document is format-agnostic: the canonical payloadcanonical 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. gives examples of format profiles.

An implementation claiming conformance to a format profile shall satisfy the format-agnostic binding requirements in in addition to the profile-specific format requirements.

The detailed requirements and conformance tests for each requirements class are specified in the relevant subject-matter clauses and rendered from structured data:

• : /req/architecture/*

• : /req/artifact-format/*

• : /req/algorithms/*

• : /req/threshold-signing/*

• : /req/scope/*

• : /req/revocation/*

• : /req/transparency/*

• : /req/verification/*

• : /req/key-lifecycle/*

• : /req/delivery/*

• : /req/ceremony/*

• : /req/manifest/*

• : /req/governance/*

• : /req/algorithm-agility/*

The full set of conformance tests is rendered in .

Requirements classes and their dependencies

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 ();

• The trust graph: the directed acyclic graph that generalizes the linear chain to admit multiple paths, federations, and cross-domain links ();

• Chain discovery: the mechanisms by which a verifier resolves the path from an artifact to a root anchor ();

• The trust anchor bundle: the self-contained set of root anchors that enables offline verification ().

A trust anchor bundletrust anchor bundle is a self-contained set of root trust authoritytrust authority anchors — root aggregate keyaggregate 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).

The delegation model is domain-agnostic. Domain-specific hierarchies map onto it by identifying their tiers with the appropriate trust authority level.

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.

Architecture and trust model has its formalized requirements class described in , with its requirements listed from to .

A trusted artifacttrusted 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 ; the COSE profile encodes artifacts as CBOR ().

Any conforming signature wrapper shall guarantee the following five binding properties:

1. Canonical representation binding. The signature shall bind to a deterministic canonical payloadcanonical 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.

2. Algorithm identification. The wrapper shall explicitly identify the signing algorithm and its parameters, such that the verifier knows unambiguously how to validate the signature.

3. Signer identification. The wrapper shall reference or embed the signer’s public key or end certificateend certificate, enabling the verifier to locate the key and its delegation chain.

4. 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 ).

5. 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 bundletrust anchor bundle alone, without external convention.

The canonical payloadcanonical payload is the deterministic byte-string representation of the artifact data that all signatures and co-signatureco-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 ). 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 :

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.

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 in addition to the profile-specific canonicalization characteristics. The format profiles listed in are initially registered; additional profiles may be registered per .

Future formats may be registered upon demonstration of conformance to the five binding requirements and specification of their canonicalization algorithm.

The payload of a trusted artifacttrusted 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.

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.

A trusted artifacttrusted artifact may accumulate dimension attestationdimension attestations over time. As additional dimensions converge, the artifact’s classification labelclassification label may improve as additional dimensions are attested.

The accumulation protocol shall ensure that each added dimension attestation signs the original canonical payload, not a modified version.

Artifact format and signature binding has its formalized requirements class described in , with its requirements listed from to .

This clause specifies the cryptographic algorithms recognized in the SIGNATIF framework, the composite signaturecomposite 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 (, ), and classical mechanisms follow established digital-signature standards (). An implementation may support any subset, subject to the requirements of its claimed conformance classes.

Classical signature algorithms registered in the algorithm identifier registry () are recognized. The initial registry includes. The initial registry contents are listed in .

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.

Post-quantum signature algorithms registered in the algorithm identifier registry maintained by the scheme (see ) are recognized. The initial registry includes. The initial registry contents are listed in .

A composite signaturecomposite signature is a single signature produced by the AND-composition of two or more signature algorithms over the same canonical payloadcanonical 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.

The framework supports migration from classical to post-quantum algorithms. The migration is governed by the algorithm agility framework (see ).

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.

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.

Cryptographic algorithms has its formalized requirements class described in , with its requirements listed from to .

In the SIGNATIF framework, threshold signingthreshold signing is not a property of the root alone. Any trust authoritytrust authority at any level of the trust graphtrust 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 keyaggregate key. No individual holder possesses the full signing capability; the aggregate key is composed from member-contributed shares. Schnorr-based signature schemes () admit compact threshold aggregation under this model.

A delegated trust authoritydelegated 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 .

Each delegation certificate shall carry the child’s aggregate public key, the quorumquorum definition (T, N), and the member identity references. A single-key authority (1-of-1) omits the quorum parameters.

When a threshold authority rotates a member — adding, removing, or replacing a key holder — the aggregate keyaggregate 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.

A threshold delegated trust authoritydelegated 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.

A ceremonyceremony is the protocol by which a quorumquorum of key holders cooperates to produce a threshold signingthreshold 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 ) that is independently verifiable.

Threshold signing and federated trust authorities has its formalized requirements class described in , with its requirements listed from to .

The authorization scopescope 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 invariantmonotonic narrowing invariant, authorization scope conditionscope conditions as executable predicates, and the multi-layer enforcement model.

An authorization scope is a multi-dimensional constraint set. Each authorization scope dimensionscope dimension constrains one axis of the authorization boundary independently. The initially defined scope dimensions are listed in ; geographic values may use the country codes of .

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.

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 invariantmonotonic narrowing invariant ().

Monotonic scope narrowing through the delegation chain

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:

1. Normalize both scopes: singleton sets {x} are equivalent to the single value x and shall be normalized before comparison.

2. For each scope dimension d in the union of dimensions present in S_p and S_c:

   1. Let v_p be the value of dimension d in S_p (wildcard if absent).

   2. Let v_c be the value of dimension d in S_c (wildcard if absent).

   3. If v_p is wildcard, the dimension is narrowed regardless of v_c. Continue to the next dimension.

   4. If v_c is wildcard and v_p is not wildcard, the dimension is widened. Return false.

   5. 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.

   6. 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.

   7. 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.

   8. 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.

3. 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.

4. 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.

A authorization scope conditionscope condition is an executable predicate included in a scope, evaluated at verification time against the content and context of the trusted artifacttrusted 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.

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 define the concrete encoding for each supported serialization.

Scope is enforced at multiple independent layers:

1. Certificate extension. The scope is carried in the certificate, signed by the parent authority. Tampering with the scope invalidates the signature.

2. Chain verification. The monotonic narrowing invariantmonotonic narrowing invariant is checked at every delegation link. Widening on any dimension causes rejection.

3. Verification pipeline. The verification pipelineverification pipeline includes a scope check that confirms the artifact’s content falls within the scope of the signing key, including evaluation of all authorization scope conditionscope conditions.

4. Transparency log. The scope is recorded in the public transparency log for every certificate, enabling audit and detection of scope violations by third parties.

Trust chain and authorization scope governance has its formalized requirements class described in , with its requirements listed from to .

PKI provides robust certificate-level revocation through CRLs and OCSP (). In the SIGNATIF framework, revocation additionally propagates to artifacts: revoking a trust authoritytrust authority state flags every trusted artifacttrusted artifact transitively bound to that state, across all trust dimensiontrust dimensions and all trust chaintrust 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.

A certificate revocation list (CRL) is a signed, time-stamped list of revoked end certificateend certificates and delegated trust authoritydelegated trust authority credentials. A CRL shall:

• identify the issuing trust authoritytrust 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 );

• be itself recorded in a transparency logtransparency log to enable audit of revocation decisions.

The specific CRL format is a deployment decision.

X.509 CRLs as profiled in are an example of a recognized CRL format.

A trusted artifacttrusted 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 payloadcanonical payload.

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 logtransparency log operator (or a mirrormirror) to discover the set of affected artifacts; an offline verifier checks individual artifact bindings against cached revocation data.

1. Identify the revoked state by its hash or identifier.

2. Query the set of artifacts whose hash-binding includes the revoked state. This query uses the transparency log index.

3. Mark each affected artifact as bound to a revoked state. Marking does not delete or alter the artifact; it flags its revocation status.

4. Propagate through co-signatureco-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.

A authorization scope conditionscope 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:

1. Identify the revoked external state by its hash or identifier.

2. Query the set of artifacts whose authorization scopescope includes a condition referencing the revoked state. This query uses the scope encoding in the artifact’s chain certificates and the transparency log index.

3. 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 ).

4. 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 ).

Scope condition withdrawal is a form of trust repudiationtrust 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.

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.

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.

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.

Revocation and artifact binding has its formalized requirements class described in , with its requirements listed from to .

Every end certificateend certificate and every trusted artifacttrusted artifact shall be recorded in a recognized transparency logtransparency 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 ). 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, gossipgossip between mirrormirrors, and the multi-log attestation model.

A transparency logtransparency 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.

Merkle trees as specified in , continued by the version 2 design (), are an example of a log structure satisfying these properties. Other append-only log constructions with equivalent inclusion proof and consistency proof guarantees may be used.

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 ). A log that cannot produce a consistency proof between two claimed sequential tree heads is evidence of misbehaviour.

An inclusion proofinclusion 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.

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 satisfy this requirement.

For artifacts issued by a federated trust authorityfederated 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.

Transparency and multi-log attestation has its formalized requirements class described in , with its requirements listed from to .

A verifier in the SIGNATIF framework applies an ordered sequence of checks to a trusted artifacttrusted artifact, resolves the trust graphtrust 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.

The verification pipelineverification pipeline is an ordered sequence of checks applied to an artifact (). Checks are classified as hard or soft:

Verification pipeline — ordered checks and classification

• 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.

classifies each check and states its purpose.

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 .

These fields are the objective primitives from which classification and acceptance decisions are derived.

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:

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.

Each verifier defines an acceptance policy that maps the classification label to an accept or reject decision for a given context:

The acceptance policy is the verifier’s risk decision. The standard does not prescribe acceptance thresholds.

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.

A verifier shall be able to verify artifacts offline using:

• the trust anchor bundletrust anchor bundle;

• cached CRLs within their validity or grace period (see );

• 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.

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 .

An implementation may define additional failure reasons. Extensions shall use the x- prefix to avoid collision with future standardized reasons.

Verification pipeline has its formalized requirements class described in , with its requirements listed from to .

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 keyaggregate keys, threshold member shares, end certificateend certificate keys, and time keytime keys. Key management follows established practice (, ).

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.

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.

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.

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.

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 authoritytrust authority shall verify the PoP before issuing an end certificateend certificate or delegation certificate.

Keys shall be rotated according to the authority’s key rotation policy. Rotation of threshold member shares shall preserve the aggregate keyaggregate key (see ). Rotation of end certificate keys shall produce a new certificate under the same or narrower authorization scopescope.

Key lifecycle has its formalized requirements class described in , with its requirements listed from to .

This clause specifies how trusted artifacttrusted 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 ().

For delivery to devices without network connectivity, a trusted artifacttrusted artifact or its passportpassport 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.

A passportpassport is the machine-readable public projection of an end certificateend certificate or trusted artifacttrusted 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.

Chain discovery mechanisms are specified in . 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.

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.

The specific transport protocol is out of scope of this document (see ). Implementations may use any protocol that satisfies the above requirements.

A verifier may challenge a device signer to produce a fresh trusted artifacttrusted 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 ) to the challenge-response. A response received outside the window shall be rejected.

• Nonce binding. The device shall bind the nonce into the canonical payloadcanonical 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.

Delivery and discovery has its formalized requirements class described in , with its requirements listed from to .

A ceremonyceremony 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.

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 payloadcanonical payload hash that was signed.

• Signature. The resulting threshold signature under the authority’s aggregate keyaggregate key.

• Timestamp. The time of the ceremony, anchored to a time keytime key or external time source where possible.

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.

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 logtransparency log: the artifact or certificate produced by the ceremony shall appear in the log, and the transcript shall reference the corresponding log entry.

The ceremony audit algorithm verifies that a ceremony transcript is consistent and valid:

1. Verify each member’s participation signature.

2. Verify the aggregate threshold signature against the authority’s published aggregate key.

3. Confirm that at least T of N members participated.

4. Cross-reference the transcript’s payload with the transparency logtransparency log entry for the produced artifact or certificate.

5. Confirm the timestamp is consistent with the transparency log entry.

Ceremony records has its formalized requirements class described in , with its requirements listed from to .

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.

This clause specifies the manifest format, required fields, validation rules, and versioning.

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 authorityroot trust authority whose deployment it describes.

A deployment manifest shall declare the following:

• Topology type. The trust topology profile (hierarchical, federated, cross-recognized, or mesh) per .

• Authorities. The trust authoritytrust authorities in the deployment, each with its identifier, aggregate keyaggregate key or fingerprint, quorumquorum parameters (if threshold), and parent reference.

• Scope. The root authorization scopescope and any delegation narrowing rules.

• Algorithms. The signature algorithms recognized by the deployment (classical, post-quantum, or composite).

• Transparency endpoints. The transparency logtransparency logs and mirrormirrors 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 ). The classification policy shall be a pure function of the coverage report fields.

• Trust anchor references. References to the trust anchor bundletrust anchor bundle version(s) recognized by the deployment.

A deployment manifest shall satisfy the following validation rules:

• All declared authorities shall form a valid trust graphtrust graph — a DAG with no cycles.

• Every delegation link shall satisfy the monotonic narrowing invariantmonotonic 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.

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.

Deployment manifest has its formalized requirements class described in , with its requirements listed from to .

This clause specifies the governance requirements for root trust authorityroot trust authorities and the trust topology profiles that a SIGNATIF deployment may adopt. Topology is declared in the deployment manifest (see ) and determines the structure of the trust graphtrust graph ().

Trust topology profiles

A root trust authorityroot trust authority shall satisfy the following governance requirements:

• Defined scope. The root shall publish its initial authorization scopescope and delegation policy.

• Transparency. All root-level operations (delegation, scope changes, key rotation) shall be recorded in a recognized transparency logtransparency log.

• Threshold or federation. The root shall operate under a threshold scheme or as a federated trust authorityfederated 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 keyaggregate key shall be published in a trust anchor bundletrust anchor bundle with a version and validity period.

A delegated trust authoritydelegated 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.

Mutual recognition between two root trust authorityroot 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.

Governance and mutual recognition has its formalized requirements class described in , with its requirements listed from to .

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 .

The algorithm identifier registry is maintained by the scheme (see ). 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 . An implementation shall use algorithm identifiers from the registry. Unregistered identifiers shall not be accepted by conforming verifiers.

When an algorithm is identified as weak or obsolete, it shall be deprecated through the following process:

1. Announcement. The deprecation shall be announced with a deprecation date and a retirement date.

2. Deprecation period. During the deprecation period, the algorithm remains usable but verifiers shall downgrade artifacts using the deprecated algorithm.

3. 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.

Algorithm migration shall be governed by the deployment’s policy. The deployment manifest (see ) 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.

Algorithm agility has its formalized requirements class described in , with its requirements listed from to .

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 bundletrust anchor bundle, the append-only property of transparency logtransparency logs, and the threshold properties of ceremonyceremony protocols. Compromise of any of these foundations undermines the guarantees of the framework.

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 authoritytrust 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.

SIGNATIF artifacts may carry dimension attestationdimension 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.

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. Profiles of this document may specify privacy enhancements (e.g., zero-knowledge attestations, selective disclosure) appropriate to their domain.

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.

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.

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.

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.

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.

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 .

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).

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.

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.

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.

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.

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 ) shall include provision for mandatory re-signing of long-lived artifacts before algorithm retirement.

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.

Organizations operating SIGNATIF trust authorities should maintain an information security management system conforming to , 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.