diff --git a/crypto-refresh.md b/crypto-refresh.md
index bd0486a..d4ff4f8 100644
--- a/crypto-refresh.md
+++ b/crypto-refresh.md
@@ -1113,6 +1113,10 @@ These meanings are as follows:
   Note that we really do mean SHOULD.
   There are plausible uses for this (such as a blind party that only sees the signature, not the key or source document) that cannot include a target subpacket.
 
+0xFF: Reserved.
+: An implementation MUST NOT create any signature with this type, and MUST NOT validate any signature made with this type.
+  See {{sig-computation-notes}} for more details.
+
 ### Version 3 Signature Packet Format {#version-three-sig}
 
 The body of a version 3 Signature Packet contains:
@@ -1201,7 +1205,7 @@ DSA signatures MUST use hashes that are equal in size to the number of bits of q
 If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q.
 This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm.
 
-### Version 4 and 5 Signature Packet Formats
+### Version 4 and 5 Signature Packet Formats {#version-four-and-five-sig}
 
 The body of a v4 or v5 Signature packet contains:
 
@@ -1889,15 +1893,28 @@ This trailer depends on the version of the signature.
 
   - the hashed subpacket body,
 
+  - For a v5 signature only, a number representing the coarse-grained length (in octets) of the hashed data from the Signature packet through the hashed subpacket body.
+    This is a four-octet big-endian unsigned integer of the length modulo 2\*\*64, divided by 2\*\*32.
+
   - A second version octet (0x04 for v4, 0x05 for v5)
 
   - A single octet 0xFF,
 
-  - A number representing the length of the hashed data from the Signature packet stopping right before the second version octet.
-    For a v4 signature, this is a four-octet big-endian number, considered to be an unsigned integer modulo 2\*\*32.
-    For a v5 signature, this is an eight-octet big-endian number, considered to be an unsigned integer modulo 2\*\*64.
+  - A number representing the fine-grained length (in octets) of the hashed data from the Signature packet through the hashed subpacket body.
+    This a four-octet big-endian unsigned integer of the length modulo 2\*\*32.
+
+After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm and its first two octets are placed in the Signature packet, as described in {{version-four-and-five-sig}}.
+
+#### Notes About Signature Computation {#sig-computation-notes}
+
+The data actually hashed by OpenPGP varies depending on signature version, in order to ensure that a signature made using one version cannot be repurposed as a signature with a different version over subtly different data.
+The hashed data streams differ based on their trailer, most critically in the fifth and sixth octets from the end of the stream.
+In particular:
 
-After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm and placed at the end of the Signature packet.
+- A v3 signature uses the fifth octet from the end to store its signature type.
+  This MUST NOT be signature type `0xff`.
+- All signature versions later than v3 always use a literal `0xff` in the fifth octet from the end.
+  For these later signature versions, the sixth octet from the end (the octet before the `0xff`) stores the signature version number.
 
 #### Subpacket Hints