Comparison

Different designs, different jobs — and what Signatif adds

This comparison follows the standard’s own informative annexes — and it cuts both ways. PKI remains the right tool for TLS and web identity, and each technology below is mature for the problem it was designed to solve. What follows asks a different question: the regulated-artifact problem, where the difference is one of design intent, not implementation quality.

Scenario 1 — pharmaceuticals

Prove the batch, not just the signature

A batch release must demonstrate that the product came from an authorized manufacturer, was inspected by a certified operator, was manufactured under compliant environmental conditions, and was released at a verifiable time. Four independent claims about reality — one artifact.

·Traditional PKI

Validates that the signing key belonged to the manufacturer. Says nothing about the operator, the conditions, or the time — the key’s authority is defined by external policy documents a verifier must read and interpret.

·Blockchain attestation

Immutably records that something was logged. No scope enforcement over who may attest what, no condition lifecycle, and no revocation that reaches artifacts already bound to a revoked state.

·W3C Verifiable Credentials

The issuer signs the claims, but the trust model is issuer-asserted: one proof, no convergence semantics across independent attestations, no mandatory transparency, no standardized coverage assessment.

✓With Signatif

Each claim is a cryptographic co-signature on the same canonical payload, backed by its own trust dimension — authority, person, environment, time. The coverage report states exactly which dimensions attest and how independently. Convergence, not issuer reputation, is the evidence.

Scenario 2 — legal metrology

Verify at inspection, fifteen years later, offline

An inspector holds a calibration certificate in a facility with no connectivity. The issuing laboratory may no longer exist. The certificate must still verify — with the same classification — against what the inspector carries.

·Traditional PKI

Path validation leans on reachable CRL/OCSP services or cleverly cached state; long-term validation (CAdES-A, PAdES-LTV) preserves archive-time signature validity but still reasons about certificates, not about the artifact’s conditions.

·Blockchain attestation

Verification means reconciling with the ledger — a network round trip, a synced node, and an operator still in business. Offline verification is outside its design case.

·Code-signing transparency

Built for software artifacts under an ecosystem log; inclusion proofs exist, but the model carries no notion of dimensional attestations, scope conditions, or graduated labels for a metrology certificate.

✓With Signatif

The trust anchor bundle, an embedded delegation chain, cached tree heads with inclusion proofs, and cached revocation lists within validity or grace produce the same classification label as online verification — differing only where freshness-dependent checks cannot be satisfied. Border posts and factory floors are first-class environments, not degraded ones.

Scenario 3 — food safety

One record, two jurisdictions

A consignment crosses a border. The importing authority trusts its own roots; the exporter attests under another hierarchy. Both must accept one record without a policy negotiation between the two regimes.

·Traditional PKI

Cross-recognition means bridge CAs or cross-certificates with constraints — single entities joining hierarchies, with path building across regimes. The verifier never sees why the other domain’s key is trusted.

·Blockchain attestation

Replaces the trust question with membership: one ledger, one operator consortium. Cross-domain recognition collapses into “was it logged on our chain”.

·Code-signing transparency

A single ecosystem log per community. Multi-operator redundancy is a monitoring practice, not a verifiable quorum attached to each artifact.

✓With Signatif

Cross-domain recognition happens on the artifact: co-signatures from independent roots ride the payload itself, and the count of independent roots feeds the coverage report and the grade. No bridge authorities, no cross-certificate topology — the verifier’s own anchors decide, and diversity is measurable.

Scenario 4 — defense procurement

The authorization is withdrawn

A supplier’s accreditation is revoked. Every conformity statement that supplier ever issued — and every artifact downstream that leans on it — must stop being acceptable, provably and immediately.

·Traditional PKI

Revocation is key-centric: it captures “this key is no longer trustworthy”. The certificate is invalidated; signatures made while it was valid commonly remain valid. It cannot express “the real-world conditions under which these artifacts were produced no longer hold”.

·Blockchain attestation

Append-only by design. Nothing can be un-issued; revocation means out-of-band blacklists that the ledger itself never learns.

·W3C Verifiable Credentials

Status lists invalidate the credential — but do not propagate to dependent artifacts or across dimensions, and the relying party must know where to look.

✓With Signatif

Threshold-gated revocation of authority state propagates to every artifact transitively bound to it, across all trust dimensions and all chains, because revocation state is hash-bound into verification. Withdrawal is a first-class operation of the trust lifecycle — the property the name originally encoded.

Capability matrix

Structural properties, drawn from the standard’s comparison annex. “Does not provide” means the property is not expressible in the model — not that implementations are sloppy.

Capability	Traditional PKI	Code-signing transparency	Blockchain attestation	W3C VCs	Signatif
Authorization boundary	Policy-defined; not verifiable from the certificate	Ecosystem policy	Out of scope — membership model	Issuer-asserted	Cryptographic scope, hard check at every link
Attestations per object	One signature	One signature + log inclusion	One ledger entry	One proof	N co-signatures, one per dimension
Multi-dimensional evidence	Authority only	Provenance only	Whatever is logged	Claims, ungraded	Time, location, environment as cryptographic dimensions
Threshold protection	Optional; root-only in practice	N/A	Consensus, not signing authority	N/A	Mandatory at every authority level
Transparency	Optional (CT is web-PKI only)	Ecosystem log, single log suffices	The ledger itself	Not required	Inclusion required; M-of-K log quorum
Revocation reach	The certificate	Not applicable here	Out of scope — append-only	The credential	Propagates to all transitively bound artifacts
Time evidence	Issuer-asserted validity period	Signing time	Block timestamps	Issuance date	Independent time authority as a trust dimension
Trust assessment	At best policy-interpreted (certificate policy classes)	Binary	Logged or not	Valid or invalid	Objective coverage report, graduated labels
Offline verification	Freshness-sensitive; not the design case	Not the design case	Requires the ledger	Possible for proofs only	First-class: same label except freshness
Cross-domain recognition	Bridge CAs, cross-certificates	One ecosystem	One chain	Per-issuer trust	Co-signatures from independent roots on the artifact

Hard requirements, both ways

Some properties are structural: if a deployment needs them, the technology without them cannot be used. The standard is explicit that this list points in both directions.

Only Signatif provides

Multi-party co-signed artifacts
Cryptographic scope enforcement
Threshold at every authority level
Transparency as a verification requirement
Revocation propagation to artifacts
Multi-dimensional attestation
Graduated classification labels

Only PKI provides

Web browser interoperability and the web PKI trust stores
TLS session authentication
Mature S/MIME email ecosystems

Coexistence, not replacement

A Signatif end certificate may reference a PKI certificate for the identity dimension, and a W3C Verifiable Credential can be the payload a Signatif artifact wraps — its single proof replaced by multi-dimensional co-signatures. PKI continues to carry TLS; Signatif carries the artifacts.

PKI is a special case

A deployment configured with single-signer end authorities, one dimension, and binary acceptance behaves exactly like a traditional PKI. Migration can be graduated: start with the data dimension and existing keys, then add person, time, location, and environment dimensions as the artifact model permits.

Where preference decides

Code signing, document signing, device identity, and internal CAs are viable in both. PKI wins on ecosystem maturity; Signatif wins where scope enforcement, threshold, transparency, or revocation propagation is wanted.

Source: Annex B of the standard —CalConnect/cc-signatif