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

[Adam Twardoch (List)]

Speaking from the perspective of a person consulting for font vendors: 

MyFonts currently lists near 2,000 font "foundries" i.e. vendors who publish their own fonts: 
http://old.myfonts.com/foundry/index.html

If we add those who don't sell via MyFonts plus the vendors of opensource and free fonts, we're probably around 3,000 entities — a few larger ones and very many who only ever made one or two families. 

With DSIG, you principally have four options: 

1. Purchase a code-signing certificate from a "certification authority" for $50-$200/year and add a DSIG with it, which is the only mechanism to ensure that it is "you" who are signing it — but this is far too costly for the small vendors

2. Add a self-signed DSIG, but the usefulness of doing it is questionable except if you want the green O icon in Windows and features in Word

3. Add a stub DSIG with no signature, which is even less sensible except to convince Windows/Office to start treating the .ttf font as "OpenType" rather than "TrueType"

4. Have no DSIG at all. 

Option 1 discriminates against smaller vendors. Options 2 and 3 are silly. And Option 4 forces OSes and apps to be able to process fonts without DSIG as much as those that have. 

So in short: I don't see much of a benefit with DSIG, yet many problems. 

A.

Sent from my mobile phone.

> On 19.04.2016, at 23:17, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote:
> 
> Dear Hin-Tak, 
> 
> Thank you for your contributions and active participation in OFF-related discussions. While I agree with you that DSIG table hasn't seen much use and often comes in the way when webfonts need to be altered (e.g. subsetted for a particular content) - the deprecation of the table shouldn’t be taken lightly and we should definitely consider implications of doing so _if_ there are certain contingencies where various implementations might rely on presence of certain tables to enable advanced layout functionality. 
> 
> I consider any changes to DSIG table (either editorial or functional or deprecation) to be a major change that is definitely needed and is likely to be a benefit but I am not sure if we can do so within a scope of the current ballot comments and definitely not until we have heard from MS and other major stakeholders. The change like this might be much more suitable as part of the next major revision of the spec that is expected to be initiated later this year. 
> 
> I'd like to ask all interested parties to express their views on the DSIG table functionality and share their experiences (either negative or positive) with using it. 
> 
> Thank you, 
> Vladimir 
> 
> 
> -----Original Message----- 
> From: Hin-Tak Leung [mailto:htl10 at users.sourceforge.net] 
> Sent: Thursday, April 14, 2016 6:01 PM 
> To: mpeg-OTspec at yahoogroups.com; opentype-list at indx.co.uk; mstwsite at microsoft.com; Levantovsky, Vladimir 
> Subject: RE: [mpeg-OTspec] Re: factual error in the DSIG description in the OT spec. 
> 
> Dear Vlad, 
> 
> For the mid-term future, seeing as DSIG is little used, and not useful for web fonts which are seen as increasingly important, it would be nice to explicitly deprecating DSIG tables (that some vintage of MS Windows' rendering behavior depends on its presence is a bit unfortunate - perhaps a paragraph about 'if the font is for this purpose, ....' in the 'recommended practice' section); or for somewhat longer future, to come up with a new format that's compatible with sub-setting and web font usage. I think acertaining the origin/authorship/copyright status of a font is a good thing, we just need to find a new format which can do that, while surviving sub-setting and web font usage. 
> 
> For the short-term, the Microsoft folks had been somewhat quiet on this matter... it would be nice to confirm the disagreement between the spec and the most widely-used MS implementation (not the 'only' as Adam Twardoch kindly pointed out), and come to an addendum in the spec - either remove the 4th step in the procedure of 5 in the spec slightly to match it, or add a sentence about the most widely used implementation does not quite do what the spec says. 
> 
> Regards, 
> Hin-Tak 
> 
> -------------------------------------------- 
> On Tue, 29/3/16, Levantovsky, Vladimir 
> <Vladimir.Levantovsky at monotype.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. 
> 
> <snipped> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20160420/94ed1bdb/attachment.html>