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

Tue Mar 29 19:43:20 CEST 2016

Hi David,

Thank you very much for your input and the additional information.
You wrote:
> You’ll recall that a secondary purpose of the table has been to indicate to Windows
> that a font was OpenType and not Type 1. There could certainly be better heuristics
> for that function, but it’s too late to change old Oses. That said, perhaps they’re old
> enough to not be a point of concern today. I’m not sure at what point (if ever) this
> behavior changed; perhaps someone can enlighten me.

As part of the WOFF2 development, the WebFonts WG has actually researched this in more details before adding the suggestion to remove the DSIG as part of the compression step, and our opinion was informed by this discussion: https://lists.w3.org/Archives/Public/public-webfonts-wg/2014May/0025.html

Cheers,
Vladimir

From: David Lemon [mailto:lemon at adobe.com]
Sent: Tuesday, March 29, 2016 12:42 PM
To: Levantovsky, Vladimir; Hin-Tak Leung; mpeg-OTspec at yahoogroups.com; opentype-list at indx.co.uk; mstwsite at microsoft.com
Cc: David Lemon
Subject: Re: [mpeg-OTspec] Re: factual error in the DSIG description in the OT spec.

Vladimir,
Your comments about the DSIG table are a solid summary of points that have been raised about this in the past, and I agree they are fairly compelling.

The primary purpose of the DSIG is to verify when the font is unchanged since being signed. I don’t know whether (potentially maliciously) modified fonts are still a concern, so I’d be curious to see what Microsoft has to say on this point, in light of the various steps they’ve taken over the years to bolster security around fonts.

You’ll recall that a secondary purpose of the table has been to indicate to Windows that a font was OpenType and not Type 1. There could certainly be better heuristics for that function, but it’s too late to change old Oses. That said, perhaps they’re old enough to not be a point of concern today. I’m not sure at what point (if ever) this behavior changed; perhaps someone can enlighten me.

Thanks,
--
David Lemon
Sr Manager, Type Development
Adobe

From: "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>> on behalf of "'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec]" <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>>
Reply-To: Vladimir Levantovsky <vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com>>
Date: Tuesday, March 29, 2016 at 7:01 AM
To: Hin-Tak Leung <htl10 at users.sourceforge.net<mailto:htl10 at users.sourceforge.net>>, "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>, "opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>" <opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>>, "mstwsite at microsoft.com<mailto:mstwsite at microsoft.com>" <mstwsite at microsoft.com<mailto:mstwsite at microsoft.com>>
Subject: RE: [mpeg-OTspec] Re: factual error in the DSIG description in the OT spec.

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> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Hin-Tak Leung htl10 at users.sourceforge.net<mailto:htl10 at users.sourceforge.net> [mpeg-OTspec]
Sent: Monday, March 28, 2016 6:59 PM
To: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>; opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>; mstwsite at microsoft.com<mailto: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<mailto: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<mailto:htl10 at users.sourceforge.net>>
------------------------------------

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

Yahoo Groups Links

------------------------------------
Posted by: "Levantovsky, Vladimir" <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>>
------------------------------------

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

Yahoo Groups Links

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20160329/b7975566/attachment.html>