Home / The record / EdDSA, the new clause
6.13.4.7
What the appendix carries
The appendix is the witness followed by the second part, with an optional text field after them. The text field is optional, so a protocol that needs to carry a context should decide whether it travels in the appendix or in the domain separation string of the larger set.
- What it asks
- Define the appendix layout your protocol carries, including whether the optional text field is present, and keep it stable across versions. Record the decision, because a verifier that assumes no text field will fail when one appears.
- What the amendment does
- Inserts 6.13.4.7. So this is new text rather than a change to wording.
- Who it binds
- The protocol owner and the API owner.
- Evidence an auditor samples
- The appendix layout in the interface specification (interface specification)
- The parser test, with and without the text field (test suite)
- The versioning note, stating whether the layout can change (design note)
- The test you can run
- Send an appendix with a text field to a verifier that expects none. If it fails with an unhandled error rather than a clean rejection, the parser is not bounded.
- Common failures
- The optional field is used for data that belongs in the signed message.
- The parser reads past the end of the appendix.
- How to close it
- An optional field in a security structure is a versioning problem. Decide whether it is present, say so in the contract, and bound the parser so that a future sender cannot turn a data field into a denial of service. Put the appendix layout in the interface specification in the register first, then work down the evidence list until every line has a date.
- Where it sits against the base standard
- The base standard does not carry this text. The amendment adds it, so an estate working from the 2018 edition alone will not find it. The citation has to name the amendment, and the record for 6.13.4.7 is the only place a reader can see it.