factual error in the DSIG description in the OT spec.

[Hin-Tak Leung]

Just reposting. Maybe I should reword the issue a bit: the problem
is that, for nearly 20 years, there is only one implementation of
the signing tool, and one implementation of the checking tool,
both from Microsoft. And they agrees with each other, but not with
the words of the spec. Since too many fonts had already been
signed (in a different way from what the words of the OT spec says), it would seem
necessary to change the spec to match how the Microsoft tool behaves.

--------------------------------------------
On Tue, 8/3/16, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:
 
 Since we are on correcting the spec,
 here is another issue with
 the DSIG description in 
 
 https://www.microsoft.com/typography/otspec/dsig.htm
 
 as well as the ISO/IEC 14496:22 2015 pdf.
 
 The "4. Zero out the file checksum in the head table." 
 in the "Format 1: For whole fonts, with either TrueType
 outlines and/or CFF data:"
  should be removed. i.e. it should read:
 
 <quote>
 1 . If there is an existing DSIG table in the font,
 
     1. Remove DSIG table from font.
     2. Remove DSIG table entry from sfnt Table
 Directory.
     3 . Adjust table offsets as necessary.
     4. Add the usFlag (reserved, set at 1 for now)
 to the stream of bytes
 </quote>
 
 because there is only one implementation of the signing
 tool, from Microsoft, for many years,
 and that's how it behaves, and that's how all the signed
 fonts in the past 15+ years look like.
 The spec needs to be corrected to match how the one and only
 signing implementation behaves.
 
 The new DSIG check ( https://github.com/HinTak/Font-Validator/blob/master/DSIGInfo/DSIGInfo.cs
 ),
 which re-implements and replaces the not-opened MS wintrust
 based mssipotf.dll COM server
 in Microsoft's Font Validator and the MS signing tool,
 behaves like the MS signing tool, not the written spec.
 
 I tried implementing as how the spec was written and was
 stuck not verifying
 known-well-signed fonts for some time, until Cosimo Lupo of
 Dalton Maag Ltd tipped me about that error in the spec. The
 credits go to one of his
 (unnamed) colleagues in Dalton Maag for discovering this.
 
 
 Note also in some rare cases, ttc's hashes are
 mis-calculated by my new implementation: 
 https://github.com/HinTak/Font-Validator/issues/4#issuecomment-161325775
 https://github.com/HinTak/Font-Validator/issues/4#issuecomment-193967387