Summary

  • RFC 7515 requires a verifier to reject a JWS when its protected crit list names an extension the verifier does not understand and support, even if the signature calculation succeeds.
  • crit protects semantic interoperability: it stops an old or incomplete implementation from silently treating a message with changed rules as an ordinary JWS.
  • Cryptographic validity, extension processing and application authorization are three separate decisions, each with a different owner and evidence trail.

The signature that was not enough

Imagine a verifier receiving a compact, correctly encoded JWS. It reconstructs the signing input, selects the indicated algorithm and obtains the right key. The signature bytes match. Many dashboards would color the event green at this point. Yet the protected header also contains a parameter that changes how the message must be interpreted, and the parameter's name appears in crit. The verifier has never implemented it.

RFC 7515 does not permit a shrug. The JWS is invalid for that implementation. The verifier cannot ignore the extension, preserve the green signature result and continue with familiar semantics. The mathematical result remains a fact about the bytes and key. It is not permission to pretend that the verifier understood the signed statement.

This is the purpose of the Critical Header Parameter. Its value is an array of header-parameter names. Every name identifies an extension present in the JOSE Header whose processing is required. A recipient that does not understand and support any one of them must reject the JWS. The list itself must sit in the protected header, because an unprotected declaration of what is critical could be altered without invalidating the signature.

The rules are deliberately narrow. The list cannot be empty. It cannot repeat a name or cite a parameter absent from the JOSE Header. It is for extensions, not for relisting parameters already defined by JWS or JWA. Unknown header parameters that are not marked critical can generally be ignored; the crit list is what converts unfamiliar metadata into a mandatory semantic dependency.

A small field carrying a constitutional rule

Nat Sakimura is one of the three authors named on RFC 7515, alongside Michael B. Jones and John Bradley. The document sits at the center of the JOSE family that gave web systems a compact way to protect claims and other content. Sakimura's wider standards work and his role in the OpenID Foundation place him in a recurring institutional problem: how to let a protocol evolve without allowing two conforming participants to assign incompatible meanings to the same signed object.

The elegant answer in crit is not a registry of future meanings. It is a rule about who may proceed when meaning changes. The producer declares which extensions are indispensable to this particular JWS. The recipient proves capability by actually understanding and processing them. Neither side can replace that handshake with the observation that the signature matched.

That design disciplines extension authors too. A new parameter that merely supplies optional advice may remain ignorable. A parameter that changes the construction, interpretation or security properties of the message must be made critical under its defining specification or application profile. If a producer omits that declaration, an unaware verifier may accept the object under old rules. If a producer marks everything critical, it destroys graceful interoperability. The list is therefore a precise compatibility boundary, not a severity badge.

RFC 7515's validation sequence reinforces the point. The recipient validates the protected header encoding, checks that required fields and values are understood, constructs the signing input and validates the cryptographic operation. These are related tests, not synonyms. A library API that returns only a boolean called valid can erase which test failed—and can tempt callers to treat successful cryptography as successful processing.

b64:false shows why ignorance must fail closed

RFC 7797 supplies the clearest concrete example. Ordinary JWS processing base64url-encodes the payload before including it in the signing input. The later b64 extension permits an unencoded payload when its protected value is false. That changes the bytes over which the signature is computed and changes how the payload travels in serialized forms.

For that reason, a JWS using b64:false must also list b64 in crit. A verifier that knows RFC 7515 but not RFC 7797 will see the critical name and reject the object. It will not process the object as if ordinary payload encoding applied. The rejection is productive: it prevents a seemingly valid signature from bridging two incompatible interpretations.

The extension also exposes boundaries beyond the primitive. Application profiles are advised to use the setting consistently, rather than mixing encoded and unencoded payloads where the surrounding system cannot reliably distinguish them. Some payload octets require care in compact serialization. And JSON Web Tokens are prohibited from using the unencoded-payload option. A generic JWS library may implement b64:false correctly while a JWT application must still reject its use.

Thus there are at least three questions. Did the signature operation succeed? Did the JOSE processor understand and correctly apply every critical extension? Does the application profile permit this combination for this message type? One green answer cannot be copied into the other two columns.

Algorithms are another acceptance boundary

RFC 7518 defines the algorithms and identifiers used by JOSE, but recognition is not the same as acceptability. RFC 7515 leaves it to applications to decide which algorithms are acceptable in their context. A verifier may be technically capable of checking an algorithm and obtain a correct signature while policy rejects that algorithm, key, parameter set or deployment.

RFC 8725 makes this operational lesson explicit for JWT deployments. Implementations need an allow-list of acceptable algorithms and must not choose a verification method solely from attacker-controlled input. They must validate issuer, subject, audience and other application rules. Different kinds of JWT may require mutually exclusive validation rules so that a token created for one purpose cannot be confused with another.

crit does not replace those checks. It tells the recipient that certain extension semantics are mandatory. It does not certify that the issuer is trusted, that the audience names this service, that the claims are fresh, or that the requested transaction is allowed. It also does not make an extension safe merely because both endpoints recognize its name. Understanding is a prerequisite for judgment, not a substitute for judgment.

Multiple signatures do not collapse the decisions

The JSON serialization of JWS can carry more than one signature. RFC 7515 says an application must decide whether a JWS with multiple signatures is acceptable and which signatures must validate; in the general validation description, at least one signature must validate for the object to be considered valid. A stricter profile can demand more.

Each signature can bring its own protected header and therefore its own critical extensions. That means a system cannot safely calculate one global “crypto passed” bit and discard the paths that produced it. One signature may be understood and acceptable, another cryptographically correct but semantically unsupported, and a third rejected by key or algorithm policy. The application's threshold rule determines what the collection means.

This matters in migration. Teams may introduce a new algorithm or protected-header extension while retaining an older signature for compatibility. If acceptance logic says “any signature passed” without recording which one, the compatibility bridge can become a permanent downgrade path. If it demands both without ensuring all consumers understand the extension, rollout becomes an outage. The protocol supplies expressiveness; the deployment must supply an explicit transition rule.

The audit record needs three verdicts

A useful verifier record should preserve the distinction that the protocol created. First comes cryptographic evidence: serialization, signing-input construction, algorithm, key reference and signature result. Second comes JOSE processing: protected-header parsing, duplicate-name handling, recognized critical parameters and the code path that processed each one. Third comes application acceptance: issuer and audience policy, message profile, claim constraints, authorization decision and resulting action.

These records need not expose keys, tokens or sensitive claims. They do need stable identifiers and reason codes. “Invalid signature” is the wrong explanation when the signature matched but a critical extension was unsupported. “Valid token” is dangerously incomplete when JOSE processing passed but the audience or transaction policy failed. Precision is not merely helpful during incident review; it determines whether operators fix a key problem, an extension rollout or an authorization rule.

The name crit can encourage a superficial reading, as though it marked an alarming field. Its deeper function is epistemic. It lets a signer say: unless you understand these semantics, you do not understand what I signed. Sakimura and his co-authors made that claim enforceable within the signed envelope. Systems honor it only when they keep a correct cryptographic result from overruling a missing semantic capability.

Sources