Subject: IPP> PRO - Registering MIME types for the Printer MIB PDL types

From: [email-masked] (Stephen Zilles)
Date: Thu, 24 Apr 1997 15:04:37 PDT

There was a discussion in the Security meeting about how to identify PDL
data within a MIME based (e.g. Multipart/formdata) encoding of the model
data. It was observed that it makes much more sense to be able to label
the PDF data with a MIME type than to try to use (directly) the
enumeration of PDLs in the Printer MIB/IANA registration.

One question that came up is what aspects of the PDF format need to be
registered. I would argue that if a format has identification of Level
and Version information within the format, then it suffices to register
the format as a whole and expect that anyone that understands the format
can extract the Level and Version information from an instance of the
format. Therefore, I propose that the registration of each PDL format be
required to describe how to determine Level and Version information. If
this information is in the PDF format instances, then the registration
would describe how to find this information within the PDF data. If the
Level and Version information is not in the PDF format, then the
registration should (probably) specifiy parameters on the MIME type that
provide Level and Version information where that is needed. (Note, it
may never be necessary to determine Version information since files are
(normally) not prepared for a specific version of the information, but
only the Level of the PDL.

Registration of PDL formats is a bit tricky. The MIME registration has
more requirements than did the registration in the Printer MIB. There
are things like a security section. I have attached the
Application/PostScript registration below as an example. I think that
rather than expect that the PWG can register these MIME types, it only
makes sense for the organization that owns the intellectual property to
register the MIME type. This probably necessitates the PWG contacting
these organizations are requesting they register their formats. 

There is a separater question as to whether these formats will be
registered as Application/X or Application/vnd.X. The recent revision of
MIME registration rules (RFC 2048, MIME Part Four: Registration
Procedures) created subtrees within the MIME space. There is an IETF
subtree and a Vendor subtree.

   "The IETF tree is intended for types of general interest to the
   Internet Community. Registration in the IETF tree requires approval
   by the IESG and publication of the media type registration as some
   form of RFC."

   "The vendor tree is used for media types associated with commercially
   available products.  "Vendor" or "producer" are construed as
   equivalent and very broadly in this context. A registration may be
   placed in the vendor tree by anyone who has need to interchange files
   associated with the particular product.  However, the registration
   formally belongs to the vendor or organization producing the software
   or file format." (see RFC 2048 for full description of vendor tree)

Based on these statements I suspect the most of the PDL formats will be
registered with the vendor tree, but not necessarily all. Note that some
already registered types (e.g. Application/PostScript) were
grandfathered when the vendor tree was introduced.

Comments are solicited!

        Steve

------------------------Application PostScript-------------------------
The following is taken from RFC 2046:

4.5.2.  PostScript Subtype

   A media type of "application/postscript" indicates a PostScript
   program.  Currently two variants of the PostScript language are
   allowed; the original level 1 variant is described in [POSTSCRIPT]
   and the more recent level 2 variant is described in [POSTSCRIPT2].

   PostScript is a registered trademark of Adobe Systems, Inc.  Use of
   the MIME media type "application/postscript" implies recognition of
   that trademark and all the rights it entails.

   The PostScript language definition provides facilities for internal
   labelling of the specific language features a given program uses.
   This labelling, called the PostScript document structuring
   conventions, or DSC, is very general and provides substantially more
   information than just the language level.  The use of document
   structuring conventions, while not required, is strongly recommended
   as an aid to interoperability.  Documents which lack proper
   structuring conventions cannot be tested to see whether or not they
   will work in a given environment.  As such, some systems may assume
   the worst and refuse to process unstructured documents.

   The execution of general-purpose PostScript interpreters entails
   serious security risks, and implementors are discouraged from simply
   sending PostScript bodies to "off- the-shelf" interpreters.  While it
   is usually safe to send PostScript to a printer, where the potential
   for harm is greatly constrained by typical printer environments,
   implementors should consider all of the following before they add
   interactive display of PostScript bodies to their MIME readers.

   The remainder of this section outlines some, though probably not all,
   of the possible problems with the transport of PostScript entities.

    (1)   Dangerous operations in the PostScript language
          include, but may not be limited to, the PostScript
          operators "deletefile", "renamefile", "filenameforall",
          and "file".  "File" is only dangerous when applied to
          something other than standard input or output.
          Implementations may also define additional nonstandard
          file operators; these may also pose a threat to
          security. "Filenameforall", the wildcard file search
          operator, may appear at first glance to be harmless.

          Note, however, that this operator has the potential to
          reveal information about what files the recipient has
          access to, and this information may itself be
          sensitive.  Message senders should avoid the use of
          potentially dangerous file operators, since these
          operators are quite likely to be unavailable in secure
          PostScript implementations.  Message receiving and
          displaying software should either completely disable
          all potentially dangerous file operators or take
          special care not to delegate any special authority to
          their operation.  These operators should be viewed as
          being done by an outside agency when interpreting
          PostScript documents.  Such disabling and/or checking
          should be done completely outside of the reach of the
          PostScript language itself; care should be taken to
          insure that no method exists for re-enabling full-
          function versions of these operators.

    (2)   The PostScript language provides facilities for exiting
          the normal interpreter, or server, loop.  Changes made
          in this "outer" environment are customarily retained
          across documents, and may in some cases be retained
          semipermanently in nonvolatile memory.  The operators
          associated with exiting the interpreter loop have the
          potential to interfere with subsequent document
          processing.  As such, their unrestrained use
          constitutes a threat of service denial.  PostScript
          operators that exit the interpreter loop include, but
          may not be limited to, the exitserver and startjob
          operators.  Message sending software should not
          generate PostScript that depends on exiting the
          interpreter loop to operate, since the ability to exit
          will probably be unavailable in secure PostScript
          implementations.  Message receiving and displaying
          software should completely disable the ability to make
          retained changes to the PostScript environment by
          eliminating or disabling the "startjob" and
          "exitserver" operations.  If these operations cannot be
          eliminated or completely disabled the password
          associated with them should at least be set to a hard-
          to-guess value.

    (3)   PostScript provides operators for setting system-wide
          and device-specific parameters.  These parameter
          settings may be retained across jobs and may
          potentially pose a threat to the correct operation of
          the interpreter.  The PostScript operators that set
          system and device parameters include, but may not be
          limited to, the "setsystemparams" and "setdevparams"
          operators.  Message sending software should not
          generate PostScript that depends on the setting of
          system or device parameters to operate correctly.  The
          ability to set these parameters will probably be
          unavailable in secure PostScript implementations.
          Message receiving and displaying software should
          disable the ability to change system and device
          parameters.  If these operators cannot be completely
          disabled the password associated with them should at
          least be set to a hard-to-guess value.

    (4)   Some PostScript implementations provide nonstandard
          facilities for the direct loading and execution of
          machine code.  Such facilities are quite obviously open
          to substantial abuse.  Message sending software should
          not make use of such features.  Besides being totally
          hardware-specific, they are also likely to be
          unavailable in secure implementations of PostScript.
          Message receiving and displaying software should not
          allow such operators to be used if they exist.

    (5)   PostScript is an extensible language, and many, if not
          most, implementations of it provide a number of their
          own extensions.  This document does not deal with such
          extensions explicitly since they constitute an unknown
          factor.  Message sending software should not make use
          of nonstandard extensions; they are likely to be
          missing from some implementations.  Message receiving
          and displaying software should make sure that any
          nonstandard PostScript operators are secure and don't
          present any kind of threat.

    (6)   It is possible to write PostScript that consumes huge
          amounts of various system resources.  It is also
          possible to write PostScript programs that loop
          indefinitely.  Both types of programs have the
          potential to cause damage if sent to unsuspecting
          recipients.  Message-sending software should avoid the
          construction and dissemination of such programs, which
          is antisocial.  Message receiving and displaying
          software should provide appropriate mechanisms to abort
          processing after a reasonable amount of time has
          elapsed. In addition, PostScript interpreters should be
          limited to the consumption of only a reasonable amount
          of any given system resource.

    (7)   It is possible to include raw binary information inside
          PostScript in various forms.  This is not recommended
          for use in Internet mail, both because it is not
          supported by all PostScript interpreters and because it
          significantly complicates the use of a MIME Content-
          Transfer-Encoding.  (Without such binary, PostScript
          may typically be viewed as line-oriented data.  The
          treatment of CRLF sequences becomes extremely
          problematic if binary and line-oriented data are mixed
          in a single Postscript data stream.)

    (8)   Finally, bugs may exist in some PostScript interpreters
          which could possibly be exploited to gain unauthorized
          access to a recipient's system.  Apart from noting this
          possibility, there is no specific action to take to
          prevent this, apart from the timely correction of such
          bugs if any are found.