The fact that pre-commitments of the next keysets are hashed versions of the CESR public key identifier not in spec

[daidoji]

Pre-commitments (fields in the n list) are hashed versions of the CESR strings (b64) of the public keys appearing in the k field when rotated to and not hashes of the public keys themselves. This information is not included in the spec which speaks mostly of precommitments being hashes of the public key itself.

[SmithSamuelM]

Good clarification. The spec should state more specifically that the hashes are of the QB64 value of the public key not the raw value. We want the future committment to be the QB64 value of the public key which includes the algorithm derivation code which in turn removes a malleability attack based on different algorithms used to generate public keys.

But to be clear, everything in KERI that is public is expressed by default as fully qualified. The Raw values are hidden and are only used at the last stage for the call to the underlying cryptographic library. The default makes the cryptographic algorithm explicit, always. This removes malleability attacks on the algorithm choice. This may be jarring for those who are used to dealing with cryptography in an implicit algorithm mode. But explicity algorithm specification via the fully qualified mechanism in KERI/CESR is IMHO and advancement of some import as it makes all cryptographic primitives agile by default and removes an attack vector due to algorithmic ambiguity.

But yes it would be more precise to not assume that the reader understands this default policy.