Re: DSIG and other issues

Thank you Vlad, this is helpful.  Not being familiar with the DSIG
table and the full implications (esp. in not having one), I am not
sure how well this approach would work, or what the trade-offs would
be in going down this path.  In quickly reading through the Microsoft
documentation (link follows), I have a few more questions.

http://www.microsoft.com/typography/developers/dsig/

In regards to resigning the font, it would seem like the only option
would be for the browser to sign the font with a different signature.
While perhaps technically possible, there could be legal hurdles to
doing so.  From the documentation:

"Anyone with the requisite technical ability should be able to remove
a signature from a file, and even re-sign it with their own signature.
Legislation is being drafted in various territories that will make
this practice illegal."

Resigning the font with the original signature would not seem to be an
option, as the browser would not have access to the public + private
keys.

"To digitally sign a file, a publisher obtains public and private keys
from an independent 'Certificate Authority' (Microsoft does not
provide such keys.) The public key is a kind of certificate that
identifies a specific publisher. The publisher uses a 'signing tool'
to sign each file using their private key."

The signing (and validating) process seems time consuming, but it
would be great to have hard numbers.  Both for small fonts and large
fonts (e.g. Chinese, Japanese, Korean fonts).

In regards to determining whether a font was an OpenType or TrueType
font, this sentence seems problematic.  Further, the specifications do
not seem to convey this (checking for the presence of the DSIG table)
as the recommended practice, thus it would almost seem to be (not
knowing any better) a hack.

"We have released a font signing tool that publishers can use to sign
TrueType and OpenType fonts."

In regards to what Simon Daniel wrote, would you happen to know if the
DirectWrite API fell into this category?

"However, if an app uses Win API to do the layout, then it may be
affected by the differences in font treatment based on whether DSIG is
present or not."

Chrome is adding support to render fonts with DirectWrite.  It would
be great to know if DirectWrite was not compatible with WOFF 2.0 as we
have currently defined it (without the presence of the DSIG table).

I'm seeing red flags all over the places... I would be great for us to
better understand the full implications.




On Wed, May 21, 2014 at 12:26 PM, Levantovsky, Vladimir
<Vladimir.Levantovsky@monotype.com> wrote:
> On Tuesday, May 20, 2014 10:17 PM Chris Lilley wrote:
>
> On Wednesday, May 21, 2014, 12:33:06 AM, Vladimir wrote:
>
>>  It is not
>> clear whether only certain applications are affected, or any that use
>> the underlying Win API, but this is something we may need to
>> investigate because of the WOFF2 spec recommendation to remove DSIG
>> because it will be compromised  by pre-processing and reconstruction
>> steps. What we may consider instead (or in addition to) is to remove
>> the DSIG table while encoding a font and recreate a dummy DSIG (if the
>> original font had it) to preserve font compatibility with Win API.
>
> That is a) gross and b) will be removed again by the font validators that are commonly used to check downloaded fonts.
>
> Okay, I should have made myself clear and explain what I had in mind in more details. One possible way to remedy the problem is to:
> - indicate whether the original font had DSIG table or not. If yes, the DSIG presence would be recorded by the encoder in the table directory but without the actual DSIG table present (which is similar to the way we treat the 'loca' table today);
> - if DISG was present in the original font, the decoder would have to resign the font according to the algorithms specified by the DSIG table specification (http://www.microsoft.com/typography/otspec/dsig.htm).
>
> I believe this approach should be perfectly compatible with the spec and with the current implementations.
>
> Thank you
> Vlad
>

Received on Wednesday, 21 May 2014 21:15:59 UTC