# 6.13.5.4 The assignment is recomputed, not trusted

The verifier recomputes the assignment from the same fields the signer used, with the verification key in place of the signing key, and reads the digest the same way. Nothing in the signature carries the assignment, so it cannot be trusted from the message; it has to be derived again.

## What it asks

Recompute the assignment with the same field order, the same domain octet and the same length and endianness as the signer, and reduce it modulo the order of the base point. Record the field order in the design note and test it against a second implementation.

## What the amendment does

Inserts 6.13.5.4.

## Who it binds

The verifier owner and the test owner.

## Evidence an auditor samples

- The recomputation code, with the field order named (source repository)
- The cross-implementation test for the assignment (test suite)
- The endianness test (test suite)

## The test you can run

Change the order of two fields in the recomputation and verify. The signature must fail. If it still verifies, the fields are not both being hashed.

## Common failures

- The verifier reads a stored assignment instead of recomputing it.
- The digest is read big endian while the signer read it little endian.

## How to close it

The assignment is the one value both sides must derive identically. Put the formula in the design note, test it against a second implementation, and treat a change to it as a breaking change for every stored signature.

## Source

ISO/IEC 14888-3:2018/FDAM 1:2026(en), draft, 6.13.5.4. Read on 21 October 2026. Our wording, not the instrument's.
https://www.iso.org/standard/89517.html

Not legal advice; does not certify.