POST-QUANTUM CERTIFICATE INFRASTRUCTURE

Trust, ready
for change.

Certificate infrastructure for a post-quantum world.

qarc brings post-quantum signatures, explicit issuance policy, and inspectable evidence to private certificate infrastructure.

Explore qarc For your organization

IN DEVELOPMENT · PRIVATE-PKI LAB

HOW TRUST IS BUILT

Start with a root you trust.

Separate root and issuer keys establish your private hierarchy. The service keeps its own private key.

Architecture illustration—not live security telemetry.

How a certificate authority works

A service keeps its private key. An authority validates its identity and permission before signing a certificate. Clients validate the certificate against a root they trust and check its current validity and status.

01 / THE SYSTEM

IDENTITY / POLICY / EVIDENCE

A certificate is a promise.
Make the terms explicit.

Not just a new signature algorithm. A deliberate chain from authority to identity—with controls you can examine.

ESTABLISH IDENTITY

Your hierarchy.
Your trust domain.

Issue certificates for services and clients you control. Separate root and issuer keys. Keep subscriber private keys local.

Where trust begins

A relying party chooses which root to trust. A separate issuer signs subscriber certificates within that hierarchy. The subscriber keeps its private key.

CONSTRAIN ISSUANCE

Policy before
the signature.

Declare client capabilities, pin acceptable roots, and constrain issuance with independently approved, signed policy catalogs.

What policy controls

A signed policy catalog binds enrollment to approved roots, profiles, and client capabilities. An account login alone does not authorize issuance.

RETAIN THE EVIDENCE

Inspect what
actually happened.

Trace certificate inventory, signing attempts, hash-linked audit records, and revocation status. A success message is not the whole story.

What you can inspect

Inventory records the certificate. The signing journal records the attempt. Revocation status describes whether that certificate should still be accepted. Each answers a different question.

02 / TRUST BOUNDARIES

NO BORROWED ASSURANCE

Know exactly
where trust ends.

Strong infrastructure starts with explicit limits. Here is what qarc does—and what it does not yet claim.

See the developer workflow

Private does not mean publicly trusted.

Private certificates are for relying parties you control. qarc does not currently offer publicly trusted TLS issuance.

Cryptography is not the whole control.

Distinct root and issuer keys establish separation. Custody, recovery, and access governance remain essential operational responsibilities.

Tests are evidence. Not certification.

Native cryptographic and independent interoperability tests inform development. HSM qualification and independent security review remain separate requirements.

PRODUCTION ISSUANCE DISABLED Admission work is still in progress.

03 / FOR BUILDERS

LOCAL KEYS. VERIFIED OUTPUT.

Keep the key.
Check the receipt.

The enrollment client submits a signed CSR, persists a retry reference, and verifies the returned certificate against your pinned hierarchy before writing output.

ENROLLMENT / CLILAB WORKFLOW

01 Generate your key locally
02 Submit a signed request
03 Verify against pinned trust

$ npm run enroll -- config.json service.pem

Requires the qarc source checkout, trusted configuration, an authorized credential, and an enabled isolated lab authority.

TWO ENTRIES. DISTINCT AUTHORITY.

FOR INDIVIDUALS & DEVELOPERS

CA application

Account and social sign-in.
Your identity, without implied workspace access.

SIGN-IN IN DEVELOPMENT FOR ORGANIZATIONS

Enterprise workspace

A separate organizational login.
Workspace membership is its own boundary.

SIGN-IN IN DEVELOPMENT

Trust, readyfor change.