# 6.13.4.3 One message part is empty by design

The message is prepared so that the part that carries the message holds the whole message and the other part is empty. The general model allows two parts, and EdDSA uses one. An implementation that splits the message to fit a legacy interface is not following the clause.

## What it asks

Prepare the message for signing so that the whole message occupies the first part and the second part is empty. Record this in the interface specification, because a caller that pre hashes or splits the message changes the bytes that are signed.

## What the amendment does

Inserts 6.13.4.3.

## Who it binds

The API owner and every calling system.

## Evidence an auditor samples

- The signing API contract, stating that the raw message is passed once (interface specification)
- The caller inventory, showing no caller pre hashes the message (configuration management database)
- The test that signs a message larger than one block (test suite)

## The test you can run

Sign a message that is longer than a hash block and verify with a second implementation. A failure points at pre hashing or splitting on the way in.

## Common failures

- A legacy interface splits the message and the second part is not empty.
- A caller hashes the message before calling the signer.

## How to close it

The signing API should take one message and nothing else. If it takes two parts, the contract has to say that the second is always empty for this mechanism, and a test has to hold that line.

## Source

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

Not legal advice; does not certify.