Signature Base

What the signature base is for

The signature base is the exact canonical string that both parties must derive the same way before verification succeeds. It turns a request into a deterministic input to signing, so small differences in field order, encoding, normalization, or delimiter handling change the bytes and invalidate the signature.

That determinism is what makes the construct useful: it binds the signature to the specific request content that matters, rather than to a loosely described intent. In practice, the signature base is where protocol design meets cryptographic verification, because the verifier cannot accept “close enough”; it must reconstruct the same byte sequence.

Why serialization rules matter

The security value of a signature base depends on an unambiguous serialization format. If two implementations disagree on how to represent the same fields, they may either reject valid requests or, more dangerously, accept attacker-modified content that was serialized differently from what the signer intended.

Canonicalization rules typically cover field selection, ordering, whitespace, percent-encoding, and how repeated values are represented. Those rules are not cosmetic. They define the exact trust boundary for the signature and prevent a verifier from validating a string that is merely similar to the one the signer actually approved.

When a protocol or bot signs request-related material, the signature base also helps establish freshness and integrity expectations. A robust design usually ties the signed material to a nonce, timestamp, request target, or other contextual fields so that replay or tampering changes the verified input and breaks the signature.

How signature bases fit into request integrity

Signature bases are common in API authentication, webhook verification, message signing, and other request-integrity schemes. The core idea is always the same: select the security-relevant request components, serialize them consistently, and sign the resulting canonical string with the private key.

Verification then becomes a reconstruction problem. The receiver extracts the same components from the incoming request, applies the same canonical rules, and compares the resulting bytes against the signature using the public key or shared verification material. If the request has been altered in transit, reordered, replayed outside its allowed window, or normalized differently, the validation step should fail.

Because the signature base is a protocol artifact, implementation drift is a common source of interoperability failures. One library may preserve byte order exactly while another silently normalizes characters, changes URL encoding, or trims whitespace, which can create false negatives during verification even when no attacker is involved.

Common failure modes and design trade-offs

The main risk with signature bases is ambiguity. If the signed string leaves room for multiple interpretations, an attacker may try to exploit parser differences between signer and verifier, or a developer may accidentally omit a field that should have been part of the trust decision.

Designers also have to balance strictness and usability. A very rigid canonical format improves security and reproducibility, but it can make integration harder across languages and runtimes. A looser format may be easier to implement at first, yet it increases the chance of inconsistent verification and subtle bugs that only appear under edge-case input.

Because the signature base is only as strong as the fields it includes, protocol designers must be careful about scope. If a field materially affects authorization, routing, expiry, or target resource identity, it usually belongs in the signed base; if it is left outside, it can become a tampering gap.

Risk and Threat Considerations

Signature base mistakes can create integrity failures even when the cryptography itself is sound. If the signer and verifier do not derive the same canonical string, attackers may exploit parser differentials, replay windows, or omitted fields to alter meaning without breaking the signature check.

Failure mechanism: Ambiguous serialization, inconsistent normalization, or incomplete field coverage lets the verifier validate a different logical request than the one the signer intended.

Impact: The result can be request forgery, replay, privilege abuse, or undetected tampering with signed traffic, especially when signatures are used as the primary trust control for bots, APIs, or webhook-style callbacks.

Practitioner Guidance

What to watch for: Treat the canonicalization rules as part of the security specification, not as an implementation detail. The most common operational failure is not weak cryptography, but disagreement over exactly which bytes are signed and how they are reconstructed.

Practitioner note: A good signature base design is testable. Cross-language test vectors, edge-case serialization cases, and negative tests for reordered or altered fields are often the fastest way to catch verification drift before it becomes a trust issue.

Related resources from NHI Mgmt Group

• What breaks when knowledge base access is mis-scoped in ServiceNow?
• What breaks when JWT claims are checked before signature validation?
• Why do JWTs fail even when the signature is valid?
• What breaks when SAML signature verification and assertion processing are separated?