Re: [secdir] SecDir Review of

John C Klensin <> Fri, 08 July 2016 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70DCB12D5F4; Fri, 8 Jul 2016 11:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PKxpc_UpAj7i; Fri, 8 Jul 2016 11:51:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C362A12D59E; Fri, 8 Jul 2016 11:51:29 -0700 (PDT)
Received: from [] (helo=JcK-HP8200) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1bLas0-000Ouf-VK; Fri, 08 Jul 2016 14:51:24 -0400
Date: Fri, 08 Jul 2016 14:51:19 -0400
From: John C Klensin <>
To: Phillip Hallam-Baker <>
Message-ID: <646056D5A75C4C2DCF5CE7FF@JcK-HP8200>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc:, IETF Discussion Mailing List <>,,
Subject: Re: [secdir] SecDir Review of
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 18:51:31 -0000

One comment about the introduction to this review that I think
may be important enough to justify at least rethinking the
review.  A few comments below apply to the document more

--On Friday, July 08, 2016 14:17 -0400 Phillip Hallam-Baker
<> wrote:

> I have reviewed this document as part of the security
> directorate's ongoing effort to review all IETF documents
> being processed by the IESG. These comments were written
> primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just
> like any other last call comments.
> The point of the draft is to create a MIME type for
> application/pdf. Which is long overdue. 

Independent of any other comments here, application/pdf was
described and registered as a Media Type (MIME type) in RFF 3778
over a dozen years ago, in May 2004.

The new I-D explicitly says that it updates the definition
provided by RFC 3778 and Obsoletes that document (it doesn't
include it among its references, which seems odd to me).  

> Which is why I would like to see some more comments in the
> security section.
> PDF is a document format that has a scripting language
> capability. And so this is something that needs to be
> discussed in quite a bit of detail. It is not apparent from
> reading the document if the scripting language is one that is
> safe or of the screaming heebijebies variety.

Curiously, 3778 contains a rather extensive discussion on that
point.  I have no idea whether it is still current, but
"obsoleting" 3778 in a way that loses, rather than including or
updating, significant information would be, at best,
unfortunate.   Appendix A says "The Security Considerations were
updated to match current status", but discarding all of the
information about scripting seems like much more than that.  It
is also my understanding that some of the subsets do not allow
embedded scripting.  If that is correct, it should certainly be
mentioned.  Given that at least one of the authors of the
current I-D is also an author of 3778, the omission of the
discussion about scripting cannot be a surprise.

Other that some words about new features being added in a way
that causes old viewers to "fail gracefully", it is not clear
how the current ISO version of PDf compares to the Adobe version
defined in 3772.  If the difference is significant, then a new
media type, not reuse of an old one, is required.  Even if it is
not that significant, it appears to me (as a co-author of RFC
6838) that there is a strong case to be made for parameters that
identify versions and/or specific subsets to help applications
to identify viewers or processors that will not fail.  The
authors may have good reasons to not include either parameter,
but it seems to me that the I-D should then explain why not.