Fwd: [Fwd: [IANA #628563] Request for MIME media type Application/Standards Tree - font-woff]

ACTION-114


This is a forwarded message
From: Philippe Le Hegaret <plh@w3.org>
To: Chris Lilley <chris@w3.org>, "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Friday, November 16, 2012, 12:02:04 AM
Subject: [Fwd: [IANA #628563] Request for MIME media type Application/Standards Tree - font-woff]

===8<==============Original message text===============
Chris, Vladimir,

can we answer those comments?

Philippe

-------- Forwarded Message --------
From: Amanda Baber via RT <iana-mime@iana.org>
Reply-to: iana-mime@iana.org
To: plh@w3.org
Subject: [IANA #628563] Request for MIME media type
Application/Standards Tree - font-woff
Date: Thu, 15 Nov 2012 21:41:02 +0000

Dear Philippe,

The IESG-designated expert has reviewed your application and returned 
the inline comments below. Please reply to this email within 30 days 
(i.e. by 15 December) with a revised application. 

If you have any questions, please don't hesitate to contact us.

Best regards,

Amanda Baber
ICANN/IANA

===

This is an *excellent* registration. The only thing that needs to be
fixed is the reference to the specification. I also made a couple of
suggestions for the security considerations, but I don't insist on any
action being taken there.

Ned

> Name : Philippe Le Hegaret

> Email : plh@w3.org

> MIME media type name : Application

> MIME subtype name : Standards Tree -font-woff

I assume the leading dash is superfluous here.

> Required parameters : none

> Optional parameters :
> none

> Encoding considerations : binary


> Security considerations :
> Fonts are interpreted data structures that represent collections of
> glyph outlines, metrics and layout information for various languages and
> writing systems. Currently, there are many standardized font data tables
> that allow an unspecified number of entries, and where existing,
> predefined data fields allow storage of binary data with variable
> length. There is a significant risk that the flexibility of font data
> structures may be exploited to hide malicious binary content disguised
> as a font data component.

> WOFF is based on the table-based SFNT (scalable font) format which is
> highly extensible and offers an opportunity to introduce additional data
> structures when needed. However, this same extensibility may present
> specific security concerns – the flexibility and ease of defining new
> data structures makes it easy for any arbitrary data to be added and
> hidden inside a font file.

> WOFF fonts may contain 'hints' for the alignment of graphical elements
> of the glyphs with the target display pixel grid, and depending on the
> font technology utilized in the creation of a font these hints may
> represent active code interpreted and executed by the font rasterizer.
> Even though they operate within the confines of the glyph outline
> conversion system and have no access outside the font rendering
> machinery, hint instructions can be, however, quite complex, and a
> maliciously designed complex font could cause undue resource consumption
> (e.g. memory or CPU cycles) on a machine interpreting it. Indeed, fonts
> are sufficiently complex that most if not all interpreters cannot be
> completely protected from malicious fonts without undue performance
> penalties.

> Widespread use of fonts as necessary component of visual content
> presentation warrants that a careful attention should be given to
> security considerations whenever a font is either embedded into an
> electronic document or transmitted alongside media content as a linked
> resource.

> WOFF uses gzip compression. The WOFF header contains the uncompressed
> length of each compressed table. Applications may therefore constrain
> the size of memory buffer allocated for decompression and may stop
> writing if a maliciously crafted WOFF file in fact contains more data
> than is indicated.

These security considerations are *excellent* and are fine as-is. I'd
suggest adding two additional items, but I don't insist on either of them:

(a) A note saying that the format provides neither privacy or integrity
protections internally, and if these are needed they have to be provided
externally.

(a) A mention of the private data block facility, noting that while it
can contain anything compliant implementations are required not to
interpret it.

> Interoperability considerations :


> Published specification :
> http://www.w3.org/TR/WOFF/#appendix-b

This needs to be a pointer to the entire doc, not to the registration,
which is essentially self-referential.

> Applications which use this media :
> WOFF is used by Web browsers, often in conjunction with HTML and CSS.

> Additional information :

> 1. Magic number(s) : The signature field in the WOFF header MUST be
> 0x774F4646
> 2. File extension(s) : woff
> 3. Macintosh file type code : (no code specified)
> 4. Object Identifiers: org.w3c.woff



> Person to contact for further information :

> 1. Name : Chris Lilley
> 2. Email : www-font@w3.org

> Intended usage : Common


> Author/Change controller : The WOFF specification is a work product of
> the World Wide Web Consortium's WebFonts Working Group.

> The W3C has change control over this specification.




===8<===========End of original message text===========


-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Thursday, 6 December 2012 14:40:39 UTC