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

[Adam Twardoch (List)]

My experience of the last ten years of advising FontLab customers tells me that: 

1. Only a small percentage of the smaller font foundries/developers ever wanted to put DSIG in their fonts, mostly because obtaining the certificates was somewhat burdensome and costly. 

Also, availability of code signing tools has been problematic, as attested last year by Adobe's Read Roberts: 
> The document about font signing in the AFDKO is really old (yes, more than 10 years), and I will take out of the next release, as it is outdated - there are now many places and workflows to get digital certs. 
> 
> The Adobe team still uses essentially the same workflow as described on: www.microsoft.com/typography/developers/dsig/. However, this page is also really outdated. In order to sign under Windows 8 and higher, you need the latest MS signcode tool, which is now called 'signtool.exe' and is available through the Windows SDK https://dev.windows.com/en-US/downloads/windows-10-sdk.
> 
> You also need a 64-bit version of the mssipotf.dll library to sign on a 64 bit system. I don't know where anyone else is getting this, but I got a copy by asking Greg Hitchcock nicely. This has been the same since around 2012.
> 
> An additional point of interest is that ' Microsoft, starting 1st January 2016, is enforcing restrictions in handling of SHA-1 signed binaries.'. The Adobe IT group decided that that meant the Adobe Type team needed to use SHA-256 instead of SHA-1 for its DSIG's. This does work with the existing tools. I doubt it matters, since there is no sign that DSIG's are checked for anything other than existence. There are a lot of fonts that have a DSIG which is empty.
> 

2. At least some of the recent Microsoft Word versions for Windows (2010, 2013?, 2016?) require(d?) the DSIG table (even a dummy one) to be present in TT-flavored OT fonts in order for the user-selectable OT features such as stylistic sets to become operational. CFF-flavored OT fonts worked without DSIG. 

So some font developers resorted to adding a dummy DSIG i.e. one that contained only a header but 0 signatures. 

Tools exist that have the functionality of adding dummy DSIGs (eg. FontForge or some Python scripts). 

However, font makers consistently reported to FontLab that the only reason they have done this was to work around the “discriminations” imposed by some implementations, that is, to get OT features to work in Office, and to get the “green OpenType icon” instead of the “blue TrueType icon” in Windows. 

I generally understood that most font makers have viewed the necessity to add dummy DSIGs to .ttfs to work around these discriminations as an annoyance and a burden (though if dummy signing is present out of the box in most font-making tools, it won’t matter that much). 

See:
http://typedrawers.com/discussion/192/making-ot-ttf-layout-features-work-in-ms-word-2010

3. There were discussions about DSIG in WOFF2 and due to complications in handling it, I believe it was decided that DSIG should not be included in WOFF2 at all. See:
https://lists.w3.org/Archives/Public/public-webfonts-wg/2014May/0022.html

It seems to me that overall, any workflows that make the DSIG table “mandatory” are cumbersome, and it would be especially so if any workflows required actual valid signatures to be present in the fonts (fortunately, it seems that dummy DSIGs with 0 signatures work OK with Windows and Office but this makes it feel even more like a hack). 

I guess it may be OK to keep DSIG as is for the benefit of those foundries who are happy to use it (though reading Read Roberts' remarks suggest that even Adobe isn't overly enthusiastic). But overall, I personally woul be happier if we got rid of it altogether, or treat it as “obsolete”. 

Either way, I’d like to urge implementors (esp. Microsoft) to not rely on the presence of the DSIG table for any discrimination. 

Best,
Adam

Sent from my mobile phone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20160330/749b775b/attachment.html>