Re: [IANA #1160739] Request for media type application/lpf+zip (comments)

Thank you Laurent.

I will take care of this on Saturday (I have a call coming up now and I am on the road tomorrow)

Ivan

> On 20 Feb 2020, at 13:18, Laurent Le Meur <laurent.lemeur@edrlab.org> wrote:
> 
> Reference: https://www.w3.org/TR/2019/NOTE-lpf-20191205/#app-media-type <https://www.w3.org/TR/2019/NOTE-lpf-20191205/#app-media-type>
> 
> About security:
>> I would suggest that this say explicitly something about executable content
>> being a possibility. The current language isn't as direct about that risk
>> as it could be; it just says the content could be risky in unspecified
>> ways. Then it cites the security considerations of zip, which are at least
>> specific.
> 
> I didn't find explicit security considerations in the zip note (1). I found more interesting info is some IETF drafts like "The Archive and Packaging Pointer (app) URI scheme", which highlights a zip bomb attack (2). 
> 
> I propose to move security considerations applicable to zip to the top of the section, add a mention about the zip bomb attack and rephrase the sentence about content which poses security issues as: 
> "In addition, because of the various content types that can be embedded in LPF files, application/lpf+zip may describe content that poses security issues, e.g. malicious executable content deliberately included in the package. ..."
> 
> Note: This section was copied from the OCF 3.2 spec (3), which should therefore also be made more explicit I guess. 
> 
>> Sorry, I'm not familiar with this notation. What in particular does "0:
>> PK" mean?
> 
> 
> In OCF 3.2, the notation is 0: PK 0x03 0x04, 30: mimetype, 38: application/epub+zip
> which means at offset 0 find "PK...", at offset 30 finf "mimetype", etc. 
> 
> In our case there is only the ZIP signature to look for, therefore I propose to remove the notion of offset.  
> 
> These proposals are now visible into the iana-response branch. see PR https://github.com/w3c/lpf/pull/16 <https://github.com/w3c/lpf/pull/16>
> 
> 1. https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT <https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT>
> 2. https://tools.ietf.org/html/draft-soilandreyes-app-03 <https://tools.ietf.org/html/draft-soilandreyes-app-03>
> 3. https://www.w3.org/publishing/epub3/epub-ocf.html#app-media-type <https://www.w3.org/publishing/epub3/epub-ocf.html#app-media-type>
> 
> Cordialement, 
> 
> Laurent Le Meur
> CTO EDRLab
> 
>> Le 13 févr. 2020 à 09:10, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> a écrit :
>> 
>> Laurent,
>> 
>> I have received the comments below for the submission of the media type. I copied the entries from the LPF document itself. As far as I can see, apart from the ’none’ vs. ’n/a’, there are two questions to answer to
>> 
>> extra text on security
>> the notation on magic number
>> We should try to get this off our chest as soon as possible. The changes have to be sent back to IETF (that is something I will have to do) but the LPF note itself has to be updated as well.
>> 
>> Thanks!
>> 
>> Ivan
>> 
>> ----
>> Ivan Herman, W3C 
>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>> mobile: +31-641044153
>> ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704>
>> ---------- Forwarded message ----------
>> From: Amanda Baber via RT <iana-mime@iana.org <mailto:iana-mime@iana.org>>
>> Date: 13 Feb 2020, 05:25 +0100
>> To: ivan@w3.org <mailto:ivan@w3.org>
>> Subject: [IANA #1160739] Request for media type application/lpf+zip
>> 
>>> Dear Ivan,
>>> 
>>> The IESG-designated media type experts have reviewed this request and returned the inline comments below.
>>> 
>>> Please reply to this message by 14 March with a revised version of your submission.
>>> 
>>> A clean copy of your reviewed template is included at the end of this email, after the version that includes the inline comments. Please edit your changes into that text and return it with your reply.
>>> 
>>> If you have any questions, please don't hesitate to contact us.
>>> 
>>> Best regards,
>>> 
>>> Amanda Baber
>>> Lead IANA Services Specialist
>>> 
>>> =====
>>> 
>>> Review:
>>> 
>>>> Name: Ivan Herman
>>>> Email: ivan@w3.org <mailto:ivan@w3.org>
>>>> 
>>>> Media type name: application
>>>> Media subtype name: lpf+zip
>>>> 
>>>> Required parameters: None
>>>> 
>>>> Optional parameters:
>>>> None
>>>> 
>>> 
>>> N/A, not "None", please (see RFC 6838, Section 5.6).
>>> 
>>> Encoding considerations: binary
>>>> LPF files are binary files encoded in the application/zip media type (
>>>> https://www.iana.org/assignments/media-types/application/zip <https://www.iana.org/assignments/media-types/application/zip>)
>>>> 
>>>> Security considerations:
>>>> User agents that read LPF files should rigorously check the size and
>>>> validity of data retrieved.
>>>> 
>>>> In addition, because of the various content types that can be embedded in
>>>> LPF files , application/lpf+zip may describe content that poses security
>>>> implications beyond those noted here. However, only in cases where the user
>>>> agent recognizes and processes the additional content, or where further
>>>> processing of that content is dispatched to other user agents, would
>>>> security issues potentially arise. In such cases, matters of security would
>>>> fall outside the domain of this registration document.
>>>> 
>>> 
>>> I would suggest that this say explicitly something about executable content
>>> being a possibility. The current language isn't as direct about that risk
>>> as it could be; it just says the content could be risky in unspecified
>>> ways. Then it cites the security considerations of zip, which are at least
>>> specific.
>>> 
>>>> Security considerations that apply to application/zip also apply to LPF
>>>> files. (https://www.iana.org/assignments/media-types/application/zip <https://www.iana.org/assignments/media-types/application/zip>)
>>>> 
>>>> Interoperability considerations:
>>>> Any format based on LPF, if using content encryption, MUST choose a
>>>> different MIME media type and file extension than those defined in this
>>>> specification.
>>>> 
>>>> Published specification:
>>>> https://www.w3.org/TR/lpf/ <https://www.w3.org/TR/lpf/>
>>>> 
>>>> Applications which use this media:
>>>> This media type is intended to be used by multiple interoperable
>>>> applications for the distribution and consumption of ebooks, audiobooks,
>>>> digital visual narratives and other types of digital publications.
>>>> 
>>>> Fragment identifier considerations:
>>>> None
>>>> 
>>>> Restrictions on usage:
>>>> None
>>>> 
>>>> Provisional registration? (standards tree only):
>>>> No
>>>> 
>>>> Additional information:
>>>> 
>>>> 1. Deprecated alias names for this type: None
>>>> 2. Magic number(s): 0: PK 0x03 0x04
>>>> 
>>> 
>>> Sorry, I'm not familiar with this notation. What in particular does "0:
>>> PK" mean?
>>> 
>>> 3. File extension(s): .lpf
>>>> 4. Macintosh file type code: ZIP
>>>> 5. Object Identifiers: N/A
>>>> 
>>>> General Comments:
>>>> None
>>>> 
>>>> Person to contact for further information:
>>>> 
>>>> 1. Name: Ivan Herman
>>>> 2. Email: ivan@w3.org <mailto:ivan@w3.org>
>>>> 
>>>> Intended usage: Common
>>>> This media type is intended to be used by multiple interoperable
>>>> applications for the distribution and consumption of ebooks, audiobooks,
>>>> digital visual narratives and other types of digital publications.
>>>> 
>>>> Author/Change controller: World Wide Web Consortium (W3C)
>>>> 
>>> 
>>> =====
>>> 
>>> Original submission:
>>> 
>>> Name: Ivan Herman
>>> Email: ivan@w3.org <mailto:ivan@w3.org>
>>> 
>>> Media type name: application
>>> Media subtype name: lpf+zip
>>> 
>>> Required parameters: None
>>> 
>>> Optional parameters:
>>> None
>>> 
>>> Encoding considerations: binary
>>> LPF files are binary files encoded in the application/zip media type (https://www.iana.org/assignments/media-types/application/zip <https://www.iana.org/assignments/media-types/application/zip>)
>>> 
>>> Security considerations:
>>> User agents that read LPF files should rigorously check the size and validity of data retrieved.
>>> 
>>> In addition, because of the various content types that can be embedded in LPF files , application/lpf+zip may describe content that poses security implications beyond those noted here. However, only in cases where the user agent recognizes and processes the additional content, or where further processing of that content is dispatched to other user agents, would security issues potentially arise. In such cases, matters of security would fall outside the domain of this registration document.
>>> 
>>> Security considerations that apply to application/zip also apply to LPF files. (https://www.iana.org/assignments/media-types/application/zip <https://www.iana.org/assignments/media-types/application/zip>)
>>> 
>>> Interoperability considerations:
>>> Any format based on LPF, if using content encryption, MUST choose a different MIME media type and file extension than those defined in this specification.
>>> 
>>> Published specification:
>>> https://www.w3.org/TR/lpf/ <https://www.w3.org/TR/lpf/>
>>> 
>>> Applications which use this media:
>>> This media type is intended to be used by multiple interoperable applications for the distribution and consumption of ebooks, audiobooks, digital visual narratives and other types of digital publications.
>>> 
>>> Fragment identifier considerations:
>>> None
>>> 
>>> Restrictions on usage:
>>> None
>>> 
>>> Provisional registration? (standards tree only):
>>> No
>>> 
>>> Additional information:
>>> 
>>> 1. Deprecated alias names for this type: None
>>> 2. Magic number(s): 0: PK 0x03 0x04
>>> 3. File extension(s): .lpf
>>> 4. Macintosh file type code: ZIP
>>> 5. Object Identifiers: N/A
>>> 
>>> General Comments:
>>> None
>>> 
>>> Person to contact for further information:
>>> 
>>> 1. Name: Ivan Herman
>>> 2. Email: ivan@w3.org <mailto:ivan@w3.org>
>>> 
>>> Intended usage: Common
>>> This media type is intended to be used by multiple interoperable applications for the distribution and consumption of ebooks, audiobooks, digital visual narratives and other types of digital publications.
>>> 
>>> Author/Change controller: World Wide Web Consortium (W3C)
> 


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704