Documentation overview · Pre-launch version

CERTCRYPT Documentation

Public concepts, claims boundaries, and evaluation model behind CERTCRYPT — infrastructure that makes certification independently verifiable under public rules.

Controlled pre-launch

CERTCRYPT is in controlled pre-launch. This documentation provides a public overview of the model behind CERTCRYPT. Normative protocol specifications and verifier conformance material will be published progressively as they become part of the public evaluation surface.

Protocol

The CERTCRYPT protocol layerA thin layer beneath the issuer's issuance flow: a public rule frame and the cryptographic structure that make a verdict reproducible later.→Common misreadingsValidation SaaS, registry, trust badge, custodian, truth authority, blockchain notarization: why none of them fits.→The verification dependencyToday, verifying most digital certifications means calling back to the system that issued them. That dependency, why it breaks over time and under conflict, and how CERTCRYPT removes it.→The Issued and Independent statesIssuer-side production against verifier-side verdict, the asymmetry between them, and the path that connects one to the other.→

Core Concepts

IssuedDomain attribution, rule binding, cryptographic structure: what an issuer produces when issuing under the CERTCRYPT frame.→IndependentConditions of independence, what verification can confirm, the fail-closed rule, and why CERTCRYPT is not in the verification path.→Proof of IndependenceWhat the property establishes per certificate and the guarantees it offers a third party.→The issuer, CERTCRYPT and the verifierThree roles, two asymmetries (production/verification, authority/evaluation) and the failure modes the split avoids.→Public rulesConditions of publicness, versioning bound to issuance, and why publicness is structural, not decorative transparency.→Offline verificationLayers of offline, what the verifier brings before evaluation, designs that fail the test, and why it does not mean 'forever'.→Zero-data by designNo storage, no transit, no reconstruction: the structural boundary that keeps the payload outside the protocol.→UnlinkabilityStrong per-artifact attribution with no aggregated graph: between artifacts, between tenants, between verifiers, and on the public surface.→Anchoring vs proofExistence in time against evaluation under rules, the 'hash on a chain' shortcut, and why anchoring is a component, not a substitute.→Design principlesThe system constraints that, taken together, keep independent verification possible over time.→

Claims Boundary

Not a claim of factual truthPublic-rule evaluation against factual, legal and semantic truth: what Prove Truth, Not Trust actually delivers beyond the slogan.→Not a validator of correctnessRules executed against truth judged, a taxonomy that is not binary, and why validation in the legal sense lies upstream.→Not a custodian of documentsRoles CERTCRYPT does not take on, and the obligations (retention, breach, residency, discovery) that stay with the holder.→Not blockchain notarizationCategories the protocol does not belong to, and why it stays outside trust-service regulation by design.→Not a trust badgePer-artifact, not per-issuer: marks CERTCRYPT does not confer, and why Independent is not an endorsement.→

Evaluation Model

Independent evaluationReproducible under rules, with no live dependency on the issuer or CERTCRYPT: the frame under which a verification counts as independent.→The verifier's checksWhat the verification establishes, the shape of the verdict, and what the verifier deliberately does not check.→fail-closed by designWhen in doubt, the verifier refuses rather than guess. The canonical negative outcomes, and why doing the opposite — defaulting to Independent — would erode the verdict's meaning.→Public rules as a preconditionPublic rules as a required verifier input, and what collapses when they are missing: reproducibility, stability, meaning.→

Pre-launch Technical Notes

The CLI is pre-launchOne binary covering every role (issue, verify, domain, operator, capacity, status), built for terminal and scripting use with the least friction.→SDKs are pre-launchThe components an issuer integrates into its issuance flow, published as a library per language.→The protocol-layer node is pre-launchThe component an operator runs to participate in issuance under the CERTCRYPT domain, open to recognized operators beyond CERTCRYPT itself.→The verifier toolkit is pre-launchThe library a third party uses to evaluate an artifact against the public rules, published per language.→Progressive specification publicationEach specification is published one at a time when it reaches the required maturity, rather than releasing the whole set at once.→Apply for accessAccess to the current pre-launch phase is granted by application; admitted participants get access to a working environment.→

Normative surface · pending publication

Public Specifications

Normative specifications are not yet published. This section will hold the public rules required to evaluate Independent artifacts under the CERTCRYPT domain. Each spec is promoted individually when its verifier and conformance material are ready.

Read the statement →