Attested Signing · NEW

Every signature carries proof of where it was signed.

PostQ Attested Signing pairs every hybrid ML-DSA + Ed25519 signature with a remote-attestation document produced inside the enclave that signed it. Bind a key to a policy, and the API rejects any sign attempt where the enclave image, the payload hash, or the signature hash isn’t what the policy pinned.

Read the launch postQuickstart
Per-org policies
Pin image + root key
Hash-bound
Payload + sig in claims
Re-verifiable
SDK · CLI · dashboard
Audit logged
Every verdict in the ledger
What it is

Signatures + provenance, in one envelope

A hybrid signature tells you the payload wasn’t modified. An attestation document tells you which exact binary, on which exact hardware, produced the signature. Attested Signing fuses the two: every signature carries a doc whose claims are cryptographically bound to the payload hash and the signature hash the API actually returned.

📜

Sign-time attestation

The enclave signs the payload AND attests to (imageHash, payloadSha256, sigSha256, counter, nonce, timestamp) in the same atomic operation. No window for substitution.

🛡️

Policy enforcement at the API

Each org configures one or more attestation policies (vendor, allowed image hashes, pinned root key, max doc age). The API verifies under the bound policy before persisting the signature.

🔁

Re-verifiable on the client

Don't trust the API's verdict — re-verify the doc yourself with @postq/sdk, postq attest verify, or the dashboard. All three use the same wire format.

How it works

One sign call. One verifiable bundle.

1

Create an attestation policy

Pick a vendor (today: mock enclave; reserved: AWS Nitro, Azure CVM, GCP Confidential Space), pin one or more allowed image hashes, and pin the enclave's root public key. Optionally cap the max doc age.

2

Create a key bound to that policy

Pass attestationPolicyId when you create a hybrid key with an enclave-kind pqProvider (e.g. enclave-mock). Enclave-kind keys without a bound policy are rejected at create time.

3

Sign as usual

POST /v1/sign returns the composite signature plus an attestation block: {vendor, imageHash, counter, docB64, verdict, reason?}. The API has already verified the doc against the bound policy.

4

Re-verify on the client

Call verifyAttestationDoc() in @postq/sdk, or postq attest verify --policy ./policy.json --sign-result ./sig.json --payload ./artifact in the CLI. The verifier checks the JWS-shaped doc's signature under the pinned root, the image-hash allow-list, freshness, and the (sigSha256, payloadSha256) bindings.

Code

Three calls, end-to-end

import { PostQ, verifyAttestationDoc } from "@postq/sdk";

const pq = new PostQ({ apiKey: process.env.POSTQ_API_KEY! });

// 1. Create the policy (one time, out of band — pin the image + root key)
const policy = await pq.attestationPolicies.create({
  name: "release-signing-prod",
  vendor: "mock",
  matchRules: {
    allowedImageHashes: [process.env.ENCLAVE_IMAGE_HASH!],
    rootPublicKeyB64:   process.env.ENCLAVE_ROOT_PUBKEY_B64!,
  },
  enforce: true,
});

// 2. Create a key bound to that policy
const key = await pq.hybridKeys.create({
  name: "release-signing",
  algorithm: "mldsa65+ed25519",
  pqProvider: "enclave-mock",
  attestationPolicyId: policy.id,
});

// 3. Sign — attestation rides along on the response
const sig = await pq.sign({ keyId: key.id, payload: artifact });

// 4. Re-verify the doc on the client side (zero trust in the API verdict)
const ok = await verifyAttestationDoc({
  docB64: sig.attestation!.docB64,
  vendor: sig.attestation!.vendor,
  policy, // your locally-pinned policy
});
if (!ok.ok) throw new Error("attestation rejected: " + ok.reason);
Backends

One verifier interface, multiple TEEs

The verifier is vendor-pluggable. The Phase 1 mock backend ships today — the production cloud TEEs slot into the same interface as they land, with hardware verification rather than an ed25519 root.

mock

Available now

JWS-shaped doc signed by an Ed25519 root inside the postq-enclave binary. Lets you wire up the full Attested Signing flow today — same wire format as the real backends will use.

aws-nitro-enclave

Reserved — Phase 2

Real Nitro EIF + AWS Nitro root CA chain. PCR0/PCR1/PCR2 allow-listed in policy.matchRules. Drops into the same verifier interface.

azure-confidential-vm

Reserved — Phase 3

Microsoft Azure Attestation (MAA) JWT, validated against Azure's signing key, with TPM-reported PCR claims constrained by policy.

gcp-confidential-space

Reserved — Phase 4

Confidential Space OIDC attestation token, validated against Google's JWKS, with image digest pinned in matchRules.

Bind your next release to an enclave

Attested Signing is live on the production API today. Create a policy, bind a key, and gate CI on postq attest verify.

Read the launch postView All Products