Sign fonts (make valid DSIG tables)

[davelab6]

MS offers a Font Signing Tool - https://www.microsoft.com/typography/developers/dsig/ - but its unlikely to ever be liberated.

It would be nice if fontTools could sign fonts.

[miguelsousa]

@davelab6 Honest question: Who really cares about signed fonts?

[davelab6]

@miguelsousa I think in future when fonts carry more sophisticated logic then this will be more important

[miguelsousa]

I ask because we're one of the few foundries that DSIG's their fonts but for some time now we've been wondering if there's a real benefit to doing it, especially since it adds an onerous step to our release process.

[ghost]

We use DSIG at Dalton Maag.

Would initiatives like https://letsencrypt.org/ make it easier to use digital signatures?

[davelab6]

If I was working in an organization that provided paid support for fonts, I would see a benefit in verifying that the fonts you are providing a warranty for haven't been modified. I guess that DaMa does more of that kind of support than Adobe.

What is your process today? The MS tool?

[ghost]

What is your process today? The MS tool?

We use an internal tool.

[miguelsousa]

What is your process today? The MS tool?

I'm not sure. @readroberts will know.

[behdad]

I'm interested in this in general, but note that woff2 invalidates and removes signatures.

[anthrotype]

note that woff2 invalidates and removes signatures

at least for CFF-OTF fonts, it could be possible to keep the integrity of the DSIG, by simply making sure the table order is unchanged in both the encoding and decoding stage. Since brotli compression is lossless, no other DSIG-invalidating transform occurs when compressing CFF fonts -- besides, ironically, the very act of dropping the DSIG...
I raised this in the Webfont-WG list some months ago, but they decided to drop the DSIG in all cases.

[davelab6]

On 29 June 2015 at 05:41, Cosimo Lupo notifications@github.com wrote:

I raised this in the Webfont-WG list some months ago, but they decided to
drop the DSIG in all cases.

Did they give a reason?

[anthrotype]

@davelab6 https://lists.w3.org/Archives/Public/public-webfonts-wg/2015Mar/0061.html

[svgeesus]

Hello Cosimo,

Monday, June 29, 2015, 11:41:25 AM, you wrote:

at least for CFF-OTF fonts, it could be possible to keep the
integrity of the DSIG, by simply making sure the table order is
unchanged in both the encoding and decoding stage. Since brotli
compression is lossless, no other DSIG-invalidating transform occurs
when compressing CFF fonts -- besides, ironically, the very act of dropping the DSIG...
I raised this in the Webfont-WG list some months ago, but they
decided to drop the DSIG in all cases.

I think we may have missed that there are no lossy transforms in the
CFF case. Please re-raise it, it sounds as if we prematurely closed
the issue.

Chris

[twardoch]

When some "brilliant" browser folks have implemented OT sanitiser, which got included in Chrome although it was buggy and originally false-flagged lots of legit fonts, it has cost us (font dev people) dearly. And still does, actually.

The current trend is to go https-only in many places, so more and more web content providers have to buy valid SSL certs.

If we have https and OT sanitiser, I think it's an overkill to have DSIG in WOFF2. At some point, some helpful browser dude might have the idea to verify the validity of the DSIG, and reject the invalid ones (actually, it wouldn't surprise me if someone adds such code to OT sanitiser).

It's becoming increasingly difficult to serve valid webfonts. I wouldn't want to add the burden to buy both valid SSL certs and valid MS code signing certs at the risk of their fonts otherwise not loading in browsers.

This is "security overkill" if you ask me. We're not digitally signing JS and SVG, are we? Isn't https supposed to solve this comprehensively?

I don't think DSIG should be in WOFF2 ever.

[twardoch]

Ps. I mean, if you put designated security-related portions into something like wdbfonts, it's almost guaranteed that some people will think you've seriously meant it, and add over-the-top assumptions to their code.

DSIG was created at MS in times whdn nobody really took code security that seriously. But we live in different times now.

Font DSIG is amateurish stuff, the font "industry" doesn't have a serious-enough size to maintain such custom solution. Let's delegate it to the big guys please (https). :) Keep DSIG out of WOFF2!

[adrientetar]

Let's delegate it to the big guys please (https)

Isn’t https made for confidentiality of sensible information while DSIG permits asserting that the font was emitted from a legit source (distributor etc)

[13rac1]

I was just reading the open type spec, as one does for fun, and came across this note:

The enforcement of signatures is an administrative policy, enabled by the operating system. Windows will soon require installed software components, including fonts, to be signed. Internet browsers will also give users and administrators the ability to screen out unsigned objects obtained on-line, including web pages, fonts, graphics, and software components.

Source: https://www.microsoft.com/typography/otspec/dsig.htm

[davelab6]

I'm not sure. @readroberts will know.

Read, I wonder if you could confirm this? :)

came across this note

hah! I wonder how many years that has been there...... 10?

web content providers have to buy valid SSL certs

Well, only those who haven't heard about https://letsencrypt.org :)

I don't think DSIG should be in WOFF2 ever.

I'm not sure about this. As @TiroTypeworks says in https://lists.w3.org/Archives/Public/public-webfonts-wg/2015Mar/0064.html this means that commercial foundries can not reliably certify and provide warrantees to their work.

[readroberts]

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.

Having a DSIG table, even if empty, does matter: see "http://typedrawers.com/discussion/192/making-ot-ttf-layout-features-work-in-ms-word-2010". It also makes a difference in what icon is shown in the MS Font Window.

[HinTak]

Signing and verifying shares a good deal of logic, so people please feel free to extend - Font-Validator/DSIGInfo/DSIGInfo.cs - for doing signing also; in any case it is probably useful to have the verification code to look at. Note the issues about dotnet/mono difference at HinTak/Font-Validator#4 .

[HinTak]

BTW, to one of Read Robert's quote comment by Adam Twardoch - I think using the 32-bit mssipotf.dll for signing under 64-bit windows is possible, you just need to register the com server under the wow64 system instead. see:
http://stackoverflow.com/questions/4897685/how-do-i-register-a-dll-file-on-windows-7-64-bit
But perhaps it is too complicated and getting hold of a 64-bit mssipotf.dll is easier.

The new DSIG check I wrote in font validator doesn't use mssipotf.dll or the wintrust system at all, but while playing with the 2003 font validator binary on 64-bit windows, I had encountered some interesting issues, where my new hybrid (part new part old) binary does not work under 64-bit windows (and eventually I built the hybrid binary differently to cope); the reason is that the 2003 binary was 32-bit through and through, since it was built in a era when 64-bit windows wasn't that popular!

On that note, if Greg or Read can send me the 64-bit dll for private reference if/when I want to implement platform-neutral signing (i.e. signing under linux/mono and mac), that would be nice.

[HinTak]

I was reminded in the other fonttools thread, that I should mention that there are already some code for writing font files within Font Validator. I can only speculate that MS has an internal/proprietary sister project for manipulating font files, as Font Validator obviously does not need to write font files. So a font signing tool based on Font Validator is relatively straight-forward.

[miguelsousa]

DSIG'ing fonts was an interesting idea but it never caught on, nor has it been enforced. This year we started putting just stub DSIG tables in our fonts.
I think this can be closed.

[anthrotype]

Good to know, thanks Miguel.
I don't think I'll find the time/interest in implementing this any time time soon.
I as well as @HinTak tried a few times in the OpenType list to convince the the spec owners to deal with DSIG: either by fixing the spec to match the only publicly available implementation (MS signtool does not zero out the checksum before sigining), or to finally deprecate it for good.
Nothing happened, probably because nobody cares.

[HinTak]

That reminds me - I need to keep up with the pestering :-). It needs to happen one way or another... I like the idea that some authenticity can be asserted post-release.

[behdad]

Not gonna happen unless someone contributes the code.

[khaledhosny]

All fonts are unreal.

[behdad]

Just get your fonts from trustable sources. That's all.

[khaledhosny]

You are asking the wrong people in the wrong place. You want something from MS, you ask MS for it.

[HinTak]

That was 4 years ago, on the opentype mailing list (a non-public mailing list for font people - which you have to explain who you are, and why you want to join, to be able to join) - most of us are on that. I am with @khaledhosny . The temporary file urls ( fairly sure out-dated as they are 4 years old) were posted on a non-for-public list, so were obviously not meant for random person.

Besides, there is very little justifiable need for the 64-bit dll. Even if you want to sign or verify fonts, the 32-bit version works quite adequately on 64-bit windows, afaik, as long as you follow the stackoverflow link's advice above.

The 32-bit version of the dll has always been part of the public font signing tool from Microsoft, so it is publicly available. If you cannot explain why you need specifically the 64-bit dll, you probably do not need it. (and, explain it to a Microsoft person, as @khaledhosny said)

[HinTak]

You are correct, it is not mpeg-otspec . I believe @anthrotype has an openssl-based DSIG signing tool, but , if you cannot explain why you need it, you are unlikely to get it, either from him or from the openssl folks. Don't let me stop you filing at openssl (and being told to go away from them also :-) ...) though!