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

[Adam Twardoch (List)]

I'd like to clarify that since 2005, FontLab Studio 5 has had an implementation of DSIG done using some opensource libraries, not using Microsoft's code. 

Our implementation was not very thoroughly tested, though, and some users reported problems with it (it did break for some time in 2011-12 when we were porting the Mac version to Intel, but I believe it got fixed in 2014-15). I'm not sure how many fonts were signed with FLS5, but I do know that quite a few have. 

A.

Sent from my mobile phone.

> On 29.03.2016, at 16:01, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote:
> 
> 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 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20160329/75e963d6/attachment.html>