[mpeg-OTspec] Re: factual error in the DSIG description in the OT spec.

[Levantovsky, Vladimir]

Thank you Hin-Tak for reporting the issue and for providing additional details. 

I think it makes perfect sense to revisit the concept of the DSIG in general. We might want to consider few options:
1) update the spec to match the behavior of the only existing implementation;
2) review the existing algorithm to see if it makes sense to revisit it and define another format - I remember seeing reports of multiple vulnerabilities;
3) reconsider the whole approach to signing the fonts. 

The vast majority of valid uses where the font data travels either embedded in a document or as a web font resource involves preprocessing steps such as subsetting and compression that invalidate the signature. Compression algorithms such as MicroType Express used as part of EOT format or the new WOFF2 that in parts is based on MTX and shares the same concepts of content-aware preprocessing and compression produce font files that are 100% functional match to the original but the output font file is not a binary match to the input font file (even if only a simple step of font table reordering was applied). As a result, the DSIG would be invalidated in all of those cases (and WOFF2 recommends removing it when a font is compressed). Having a data block that is declared a secure signature but in fact provides no assurance of security and interferes with valid uses of a font is IMHO counter-productive since it creates a false sense of security and no real protection. 

I don’t have any grudge against DSIG but in my personal opinion having a tool that serves little purpose isn’t practical - I am willing and ready to be proven wrong and be convinced otherwise.

Thank you,
Vladimir


-----Original Message-----
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Hin-Tak Leung htl10 at users.sourceforge.net [mpeg-OTspec]
Sent: Monday, March 28, 2016 6:59 PM
To: mpeg-OTspec at yahoogroups.com; opentype-list at indx.co.uk; mstwsite at microsoft.com
Subject: [mpeg-OTspec] Re: factual error in the DSIG description in the OT spec.

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
 
 
 


------------------------------------
Posted by: Hin-Tak Leung <htl10 at users.sourceforge.net>
------------------------------------


------------------------------------

Yahoo Groups Links