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.