Public verification
A digital signature lets a holder of a private signing key sign a defined message. A verifier uses the corresponding public key to detect message changes and confirm that the signature was created by a holder of that private key. The trust claim depends on how the verifier authenticated the public key and bound it to a signer and purpose.
Signatures do not encrypt the message. They do not prove that the signer was authorized to perform the represented action.
Signed representation
Define the exact bytes and semantics. Include protocol, version, purpose, algorithm, issuer, audience, subject, resource, action, time, nonce or sequence, and key identifier as required. Use a standard serialization and signing format. Reject duplicate or unknown critical fields that could make verifiers interpret the message differently.
Do not sign a display string and act on a separately parsed object. Do not let an attacker substitute an algorithm, verification key, certificate URL, or embedded public key without a trusted selection policy.
Key trust and lifecycle
Protect the private key according to its authority and lifetime. Prefer a cryptographic service or hardware boundary when compromise impact justifies it. Separate code-signing, identity-assertion, document, and transaction keys. Rotate through a published key set or trust chain with bounded overlap.
The verifier validates the algorithm, key purpose, trust path, issuer, audience, time, message context, and signature before use. It handles revocation and retired keys according to the protocol and evidence needs.
Failure and residual risk
A valid signature can cover false, stale, replayed, or unauthorized data. A compromised signer can create apparently valid messages. Long-term verification can fail when keys, algorithms, certificates, timestamps, and evidence expire. The word non-repudiation overstates what cryptography alone proves because key custody, process, identity, and evidence also matter.
Pomerium boundary
Pomerium can send a signed identity assertion to an upstream. The application must verify signature, algorithm, issuer, audience, expiry, and other documented claims before it trusts the identity. The application still authorizes the requested object and action. A valid Pomerium assertion is not a signature over the application's final business transaction.
Evaluation checklist
- What exact signer, key, purpose, audience, message, and time does the signature claim?
- How is the verification key authenticated and constrained to that purpose?
- Is the signed representation unambiguous and identical to the acted-on data?
- Can the message be replayed, substituted across protocols, or verified with an attacker-selected key?
- How are private-key compromise, rotation, revocation, and old-message verification handled?
- Which authorization and evidence claims remain outside the signature?
