draft-ietf-openpgp-rfc4880bis-04

[FuzzyDrawrings]

It is definitely my error in the m value I was hashing, which I failed to notice was not the same given in the documentation. I somehow repeatedly overlooked the fact that my obtained m value was different and only noticed that d (the hash) mismatch. Oops. 

Looking more carefully, I see did not in fact get the same value for m and am missing its trailing six octets 04ff0000000c.

Mystery solved. :)

But another more involved problem presents itself:

The value m is obtained as explained under "5.2.3.  {5.2.3} Version 4 Signature Packet Format"

| The concatenation of the data being signed and the signature data
| from the version number through the hashed subpacket data (inclusive)
| is hashed.

I can account for every part of that through the hashed subpacket data in the value m, but not in m's last six octets: 04ff0000000c

m: 4f70656e504750040016080006050255f95f9504ff0000000c
'4f70656e504750' is the text "OpenPGP" being signed.
'04' is the signature version
'00' is the signature type (Signature of a binary document)
'16' is the public-key algorithm (EdDSA)
'08' is the hash algorithm (SHA256)
'0006' is the length of following hashed subpackets (6 octets)
'05' is the length of the first hashed subpacket (5 octets)
'02' is the first hashed subpacket tag (Signature Creation Time)
'55f95f95' is the first hashed subpacket data (2014-08-19 14:28:27)

...and that's the end of hashed subpackets. That should be all that is hashed for the signature, yet there is the remaining octets in m:

 04ff0000000c

 I cannot figure out what information is contained in 04ff0000000c.  I'm sure the answer is some hilarious oversight on my part, but I'm stumped. :/