RE: DSIG and other issues

Thank you David for raising many good points.
I think that resigning the font by a browser should be possible, and this is where an additional bit set in the 'head' table (flags, bit 11) to indicate that the font was subjected to a content-aware transform would be helpful. So far, I have not heard about any legal implications of doing this - I don't say there are none, but I am not aware of any. There is an ongoing discussion about DSIG on the OTspec list, where various proposals (including the one to deprecate the DSIG) were brought up and are being discussed. The major concern that many folks expressed is that the DSIG failed to deliver any sensible protection (there are no apps or rendering solutions that would check the DSIG integrity before using a font in question), and many folks argue that the presence of DSIG is actually detrimental because it may create a false sense of security protection that isn't really there.

I suggest that we as a group should make every possible effort to collect more info about DSIG and possible implications of removing one from a font, and have it discussed in one of the upcoming telcons. 

Sergey, is there any chance you may be able to shed more light on the specifics of DSIG processing in Win APIs, what APIs are affected (DirectWrite, etc.)?

Thank you,
Vlad


-----Original Message-----
From: David Kuettel [mailto:kuettel@google.com] 
Sent: Wednesday, May 21, 2014 5:15 PM
To: Levantovsky, Vladimir
Cc: Chris Lilley; w3c-webfonts-wg (public-webfonts-wg@w3.org)
Subject: 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:28:17 UTC