Annex A
- Public status
- The annex title is in the public contents. The identifiers themselves are in the normative text, which is not in the free public preview.
- Binding party
- The organisation that derives a cryptographic key from a human-memorised password, and anyone asked to show that its derivation follows this part.
- Evidence
- 3 items
- Read
- 2026-10-21
The register / Annex A
Object identifiers
Not stated in the public preview. The annex assigns object identifiers for the functions the document specifies.
Our reading
This is not a control annex. The build brief that started this site expected an Annex A control set; there is none. The annex is an identifier registry, and its audience is the implementer who has to name an algorithm in a protocol, a certificate or a configuration file.
Annex A is short and technical. It assigns object identifiers. In the ISO series an annex of this kind exists so that two systems can agree which algorithm they are using without inventing a private name. The public contents give the title, and the text that follows is not in the free public preview.
This matters more than it sounds. Object identifiers turn up in ASN.1 structures, certificate policies, protocol negotiations and product configuration. A homemade identifier, or a string such as argon2i with no registry behind it, creates an interoperability problem that surfaces years later when another team has to read the configuration.
The practical artefact is an identifier register. For each deployment, record the identifier used, the function it names, the parameters that travel with it, and the systems that must agree. Where the identifier is carried in a signed structure, record who can change it and how a change is approved.
The correction to the brief belongs on the site. Annex A in this part is not a set of controls to assess against. A reader who arrives expecting a control checklist should be told plainly, and pointed at the two function clauses and the guidance annex instead. That is more useful than a page of invented controls.
Identifiers travel further than the product. A value written into a configuration file can end up in a certificate request, a partner integration or a signed document. Keep the registry entry with the deployment, and treat a change as a change to an interface, not a rename. If the value is wrong, the failure surfaces in another team system. The register is the interface record.
The mistake to avoid
Inventing an algorithm name or identifier instead of using the registry value, then discovering the mismatch at integration.
Evidence to keep
- An identifier register with the value, the function, the parameters and the systems that must agreeInteroperability evidence, and the artefact the annex supports.
- The source of each identifier and the date it was checkedIdentifiers are registry entries, not local choices.
- A change note for any identifier carried in a signed or negotiated structureA silent change breaks other parties.
Test it
Trace one identifier from the configuration file to the implementation to the protocol field. If any hop uses a different name, the register is incomplete.
Source
https://www.iso.org/standard/87940.html
Read on 2026-10-21. The annex title is in the public contents. The identifiers themselves are in the normative text, which is not in the free public preview. ISO free public preview carries the foreword, the introduction, clauses 1 to 3 and the table of contents. It is the DIS, not the FDIS, and the FDIS may differ. Clauses 4 to 7, annexes A to D, the figures and the object identifiers are not in the free preview; ISO sells the text. This site does not reproduce it and does not invent it.