The application/pdf Media Type
draft-hardy-pdf-mime-05

[Ballot comment]

Thanks for handling my discuss point. I think the
security considerations text now seems sufficient.
Though I would still encourage adding some more
references if possible, but that's a non-blocking
comment, so no need to do anything if you think
it's right as-is.

OLD COMMENT text below, still happy to chat about
it if that's useful.


My old comment and discuss point-2 below. I think
Larry answered opint-2 well enough in [2].

I'd suggest adding a reference to [3] would be useful
as well.

  [3] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.174.2980&rep=rep1&type=pdf

(2) section 6: It's a pity there's no ISO document to
reference in this section as PDF files have been the
vector for various threats over the years. Can't you
find some reference (from ISO or not) that a viewer or
author developer would find helpful? That section seems
pretty vague to me as-is. (In particular the last clause
of the last sentence in this section is not useful.) And
I see from the discussion of the secdir review ([1], did
any authors respond to that? If so I didn't see it,
sorry).  The discuss point here is that we seem to have
less good security considerations compared with RFC3778,
and I think that ought be justified if it's the right
thing to do. (Not necessarily in the document if that's
not correct, but at least as part of the record, e.g. in
response to this.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06674.html
comments
- section 4: why no reference for PDF/A? I'd have
thought that was the most important one for which a good
reference is needed? The referred document is [ISOPDFA]
in 8.2 so I guess this is just an editing glitch.

[Ballot discuss]

I have one remaining thing I'd like to discuss about this
draft that I don't think was answered in Larry's earlier
response. [2]

  [2]  https://mailarchive.ietf.org/arch/msg/ietf/yKbjLYUcxHHdj63PbrWbte12jBE

(1) section 3: Are there any potential security issues
with namedest as a parameter? E.g. has any PDF reader or
MIME handler followed an absolute URL for the value
there perhaps? If so, is there a warning it'd be useful
to give?  Are there any other similarly known potential
vulnerabilities for other parameters? (Maybe fdf or ef?)
(This is also related to discuss-point-2 below)

I don't think this was answered in [2]. To try rephrase it:
"What (if any) security considerations text is needed about
the parameters of application/pdf?"

[Ballot comment]

My old comment and discuss point-2 below. I think
Larry answered opint-2 well enough in [2].

I'd suggest adding a reference to [3] would be useful
as well.

  [3] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.174.2980&rep=rep1&type=pdf

(2) section 6: It's a pity there's no ISO document to
reference in this section as PDF files have been the
vector for various threats over the years. Can't you
find some reference (from ISO or not) that a viewer or
author developer would find helpful? That section seems
pretty vague to me as-is. (In particular the last clause
of the last sentence in this section is not useful.) And
I see from the discussion of the secdir review ([1], did
any authors respond to that? If so I didn't see it,
sorry).  The discuss point here is that we seem to have
less good security considerations compared with RFC3778,
and I think that ought be justified if it's the right
thing to do. (Not necessarily in the document if that's
not correct, but at least as part of the record, e.g. in
response to this.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06674.html
comments
- section 4: why no reference for PDF/A? I'd have
thought that was the most important one for which a good
reference is needed? The referred document is [ISOPDFA]
in 8.2 so I guess this is just an editing glitch.

[Ballot comment]
I agree with all the security comments. I also agree with Suresh that the paragraph numbers are distracting. While they may be useful in the review process, they will distract readers down the road.

[Ballot comment]
I agree with others that the security section doesn't provide much: it neither describes how attacks could look like, nor how to handle them concretely. However, it also not clear to me if this is the right document to discuss these things or if a different doc would be needed.

[Ballot discuss]

I have two things I'd like to discuss about this
draft:

(1) section 3: Are there any potential security issues
with namedest as a parameter? E.g. has any PDF reader or
MIME handler followed an absolute URL for the value
there perhaps? If so, is there a warning it'd be useful
to give?  Are there any other similarly known potential
vulnerabilities for other parameters? (Maybe fdf or ef?)
(This is also related to discuss-point-2 below)

(2) section 6: It's a pity there's no ISO document to
reference in this section as PDF files have been the
vector for various threats over the years. Can't you
find some reference (from ISO or not) that a viewer or
author developer would find helpful? That section seems
pretty vague to me as-is. (In particular the last clause
of the last sentence in this section is not useful.) And
I see from the discussion of the secdir review ([1], did
any authors respond to that? If so I didn't see it,
sorry).  The discuss point here is that we seem to have
less good security considerations compared with RFC3778,
and I think that ought be justified if it's the right
thing to do. (Not necessarily in the document if that's
not correct, but at least as part of the record, e.g. in
response to this.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06674.html
comments

[Ballot comment]

- section 4: why no reference for PDF/A? I'd have
thought that was the most important one for which a good
reference is needed? The referred document is [ISOPDFA]
in 8.2 so I guess this is just an editing glitch.

[Ballot comment]
In the Security considerations, the text starts off saying:

  The PDF file format allows several constructs which may compromise
  security if handled inadequately by PDF processors.

Shouldn't this go a step further to also include the consideration that the feature could be exploited by an attacker?  I don't see how it is enough for the processor to handle all possible exploits.  If I am wrong, please explain.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-hardy-pdf-mime-02.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the application media types subregistry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

the existing registration will be updated with the information in Section 7 of the current document and the reference will be changed to [ RFC-to-be ].

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, draft-hardy-pdf-mime@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The application/pdf Media Type) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The application/pdf Media Type'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


<1>
  The Portable Document Format (PDF) is an ISO standard (ISO
  32000-1:2008) defining a final-form document representation language
  in use for document exchange, including on the Internet, since 1993.
  This document provides an overview of the PDF format and updates the
  media type registration of "application/pdf".




The file can be obtained via
https://datatracker.ietf.org/doc/draft-hardy-pdf-mime/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-hardy-pdf-mime/ballot/


No IPR declarations have been submitted directly on this I-D.

My AD review:

Need to split references into Normative and Informative.

What is "the default user space coordinate system"?
(Are coordinate values in fragments measured in what?)

Where are FDF files defined?

Does mentioning of JavaScript and XObject need Informative References?

In the media type registration template:

Author/change controller: please clarify the text that 2 people listed are not change controllers, but authors/editors. E.g. XXX and YYY are authors. ISO ... is the change controller.
The media type registration template has 2 separate fields, so the easiest way to fix this issue is to split them.