Content      ..      1      2      3      ..

ISO 32000-1 Document management — Portable document format — Part 1: PDF 1.7 - page 2

Table 13 - Optional parameter for the DCTDecode filter

Key

Type

Value

ColorTransform

integer

(Optional) A code specifying the transformation that shall be

performed on the sample values:

0 No transformation.

1 If the image has three colour components, RGB values shall be

transformed to YUV before encoding and from YUV to RGB after

decoding. If the image has four components, CMYK values shall

be transformed to YUVK before encoding and from YUVK to

CMYK after decoding. This option shall be ignored if the image has

one or two colour components.

If the encoding algorithm has inserted the Adobe-defined marker^a

code in the encoded data indicating the ColorTransform value, then

the colours shall be transformed, or not, after the DCT decoding has

been performed according to the value provided in the encoded data

and the value of this dictionary entry shall be ignored. If the Adobe-

defined marker code in the encoded data indicating the

ColorTransform value is not present then the value specified in this

dictionary entry will be used. If the Adobe-defined marker code in the

encoded data indicating the ColorTransform value is not present and

this dictionary entry is not present in the filter dictionary then the

default value of ColorTransform shall be 1 if the image has three

components and 0 otherwise.

a

Parameters that control the decoding process as well as other metadata is embedded within the encoded data

stream using a notation referred to as “markers”. When it defined the use of JPEG images within PostScript data

streams, Adobe System Incorporated defined a particular set of rules pertaining to which markers are to be

recognized, which are to be ignored and which are considered errors. A specific Adobe-defined marker was also

introduced. The exact rules for producing and consuming DCT encoded data within PostScript are provide in

Adobe Technical Note #5116 (reference). PDF DCT Encoding shall exactly follow those rules established by

Adobe for PostScript.

NOTE 3

The encoding algorithm can reduce the information loss by making the step size in the quantization smaller at

the expense of reducing the amount of compression achieved by the algorithm. The compression achieved by

the JPEG algorithm depends on the image being compressed and the amount of loss that is acceptable. In

general, a compression of

15 : 1 can be achieved without perceptible loss of information, and

30 : 1

compression causes little impairment of the image.

NOTE 4

Better compression is often possible for colour spaces that treat luminance and chrominance separately than

for those that do not. The RGB-to-YUV conversion provided by the filters is one attempt to separate luminance

and chrominance; it conforms to CCIR recommendation 601-1. Other colour spaces, such as the CIE 1976

L*a*b* space, may also achieve this objective. The chrominance components can then be compressed more

than the luminance by using coarser sampling or quantization, with no degradation in quality.

In addition to the baseline JPEG format, beginning with PDF 1.3, the DCTDecode filter shall support the

progressive JPEG extension. This extension does not add any entries to the DCTDecode parameter

dictionary; the distinction between baseline and progressive JPEG shall be represented in the encoded data.

NOTE 5

There is no benefit to using progressive JPEG for stream data that is embedded in a PDF file. Decoding

progressive JPEG is slower and consumes more memory than baseline JPEG. The purpose of this feature is

to enable a stream to refer to an external file whose data happens to be already encoded in progressive JPEG.

7.4.9

JPXDecode Filter

The JPXDecode filter (PDF 1.5) decodes data that has been encoded using the JPEG2000 compression

method, an ISO standard for the compression and packaging of image data.

NOTE 1

JPEG2000 defines a wavelet-based method for image compression that gives somewhat better size reduction

than other methods such as regular JPEG or CCITT. Although the filter can reproduce samples that are

losslessly compressed.

35

7.4.10

Crypt Filter

The Crypt filter (PDF 1.5) allows the document-level security handler (see 7.6, "Encryption") to determine

which algorithms should be used to decrypt the input data. The Name parameter in the decode parameters

dictionary for this filter (see Table 14) shall specify which of the named crypt filters in the document (see 7.6.5,

"Crypt Filters") shall be used. The Crypt filter shall be the first filter in the Filter array entry.

Table 14 - Optional parameters for Crypt filters

Key

Type

Value

Type

name

(Optional) If present, shall be CryptFilterDecodeParms for a Crypt

filter decode parameter dictionary.

Name

name

(Optional) The name of the crypt filter that shall be used to decrypt this

stream. The name shall correspond to an entry in the CF entry of the

encryption dictionary (see Table 20) or one of the standard crypt filters

(see Table 26).

Default value: Identity.

In addition, the decode parameters dictionary may include entries that are private to the security handler.

Security handlers may use information from both the crypt filter decode parameters dictionary and the crypt

filter dictionaries (see Table 25) when decrypting data or providing a key to decrypt data.

NOTE

When adding private data to the decode parameters dictionary, security handlers should name these entries in

conformance with the PDF name registry (see Annex E).

If a stream specifies a crypt filter, then the security handler does not apply "Algorithm 1: Encryption of data

using the RC4 or AES algorithms" in 7.6.2, "General Encryption Algorithm," to the key prior to decrypting the

stream. Instead, the security handler shall decrypt the stream using the key as is. Sub-clause 7.4, "Filters,"

explains how a stream specifies filters.

7.5

File Structure

7.5.1

General

This sub-clause describes how objects are organized in a PDF file for efficient random access and incremental

update. A basic conforming PDF file shall be constructed of following four elements (see Figure 2):

•

A one-line header identifying the version of the PDF specification to which the file conforms

•

A body containing the objects that make up the document contained in the file

•

A cross-reference table containing information about the indirect objects in the file

•

A trailer giving the location of the cross-reference table and of certain special objects within the body of the

file

This initial structure may be modified by later updates, which append additional elements to the end of the file;

see 7.5.6, "Incremental Updates," for details.

38

Header

Body

Cross-reference

table

Trailer

Figure 2 - Initial structure of a PDF file

As a matter of convention, the tokens in a PDF file are arranged into lines; see 7.2, "Lexical Conventions."

Each line shall be terminated by an end-of-line (EOL) marker, which may be a CARRIAGE RETURN (0Dh), a

LINE FEED (0Ah), or both. PDF files with binary data may have arbitrarily long lines.

NOTE

To increase compatibility with compliant programs that process PDF files, lines that are not part of stream

object data are limited to no more than 255 characters, with one exception. Beginning with PDF 1.3, the

Contents string of a signature dictionary (see 12.8, "Digital Signatures") is not subject to the restriction on line

length.

The rules described here are sufficient to produce a basic conforming PDF file. However, additional rules apply

to organizing a PDF file to enable efficient incremental access to a document’s components in a network

environment. This form of organization, called Linearized PDF, is described in Annex F.

7.5.2

File Header

The first line of a PDF file shall be a header consisting of the 5 characters

%PDF- followed by a version

number of the form 1.N, where N is a digit between 0 and 7.

A conforming reader shall accept files with any of the following headers:

%PDF-1. 0

%PDF-1. 1

%PDF-1. 2

%PDF-1. 3

%PDF-1. 4

%PDF-1. 5

%PDF-1. 6

%PDF-1. 7

Beginning with PDF 1.4, the Version entry in the document’s catalog dictionary (located via the Root entry in

the file’s trailer, as described in 7.5.5, "File Trailer"), if present, shall be used instead of the version specified in

the Header.

39

Table 15 lists the contents of the trailer dictionary.

Table 15 - Entries in the file trailer dictionary

Key

Type

Value

Size

integer

(Required; shall not be an indirect reference) The total number of entries in

the file’s cross-reference table, as defined by the combination of the original

section and all update sections. Equivalently, this value shall be 1 greater

than the highest object number defined in the file.

Any object in a cross-reference section whose number is greater than this

value shall be ignored and defined to be missing by a conforming reader.

Prev

integer

(Present only if the file has more than one cross-reference section; shall be

an indirect reference) The byte offset in the decoded stream from the

beginning of the file to the beginning of the previous cross-reference section.

Root

dictionary

(Required; shall be an indirect reference) The catalog dictionary for the PDF

document contained in the file (see 7.7.2, "Document Catalog").

Encrypt

dictionary

(Required if document is encrypted; PDF 1.1) The document’s encryption

dictionary (see 7.6, "Encryption").

Info

dictionary

(Optional; shall be an indirect reference) The document’s information

dictionary (see 14.3.3, "Document Information Dictionary").

ID

array

(Required if an Encrypt entry is present; optional otherwise; PDF 1.1) An

array of two byte-strings constituting a file identifier

(see

14.4, "File

Identifiers") for the file. If there is an Encrypt entry this array and the two

byte-strings shall be direct objects and shall be unencrypted.

NOTE 1

Because the ID entries are not encrypted it is possible to check

the ID key to assure that the correct file is being accessed

without decrypting the file. The restrictions that the string be a

direct object and not be encrypted assure that this is possible.

NOTE 2

Although this entry is optional, its absence might prevent the file

from functioning in some workflows that depend on files being

uniquely identified.

NOTE 3

The values of the ID strings are used as input to the encryption

algorithm. If these strings were indirect, or if the ID array were

indirect, these strings would be encrypted when written. This

would result in a circular condition for a reader: the ID strings

must be decrypted in order to use them to decrypt strings,

including the ID strings themselves. The preceding restriction

prevents this circular condition.

NOTE

Table 19 defines an additional entry, XRefStm, that appears only in the trailer of hybrid-reference files,

described in 7.5.8.4, "Compatibility with Applications That Do Not Support Compressed Reference Streams."

EXAMPLE

This example shows a trailer for a file that has never been updated (as indicated by the absence of a Prev

entry in the trailer dictionary).

trailer

<< /Size 22

/Root 2 0 R

/Info

1 0 R

/ID [

< 81b14aafa313db63dbd6f981e49f94f4 >

< 81b14aafa313db63dbd6f981e49f94f4 >

]

>>

startxref

18799

%%EOF

43

Header

Original

body

Original

cross-reference

section

Original trailer

Body update 1

Cross-reference

section 1

Updated trailer 1

Body update n

Cross-reference

section n

Updated trailer n

Figure 3 - Structure of an updated PDF file

7.5.7

Object Streams

An object stream, is a stream object in which a sequence of indirect objects may be stored, as an alternative to

their being stored at the outermost file level.

NOTE 1

Object streams are first introduced in PDF 1.5. The purpose of object streams is to allow indirect objects other

than streams to be stored more compactly by using the facilities provided by stream compression filters.

NOTE 2

The term “compressed object” is used regardless of whether the stream is actually encoded with a

compression filter.

The following objects shall not be stored in an object stream:

•

Stream objects

•

Objects with a generation number other than zero

•

A document’s encryption dictionary (see 7.6, "Encryption")

•

An object representing the value of the Length entry in an object stream dictionary

45

•

In linearized files (see Annex F), the document catalog, the linearization dictionary, and page objects shall

not appear in an object stream.

NOTE 3

Indirect references to objects inside object streams use the normal syntax: for example, 14 0 R. Access to

these objects requires a different way of storing cross-reference information; see 7.5.8, "Cross-Reference

Streams." Use of compressed objects requires a PDF 1.5 conforming reader. However, compressed objects

can be stored in a manner that a PDF 1.4 conforming reader can ignore.

In addition to the regular keys for streams shown in Table 5, the stream dictionary describing an object stream

contains the following entries:

Table 16 - Additional entries specific to an object stream dictionary

key

type

description

Type

name

(Required) The type of PDF object that this dictionary describes; shall be

ObjStm for an object stream.

N

integer

(Required) The number of indirect objects stored in the stream.

First

integer

(Required) The byte offset in the decoded stream of the first compressed

object.

Extends

stream

(Optional) A reference to another object stream, of which the current object

stream shall be considered an extension. Both streams are considered part

of a collection of object streams (see below). A given collection consists of a

set of streams whose Extends links form a directed acyclic graph.

A conforming writer determines which objects, if any, to store in object streams.

EXAMPLE 1

It can be useful to store objects having common characteristics together, such as “fonts on page 1,” or

“Comments for draft #3.” These objects are known as a collection.

NOTE 4

To avoid a degradation of performance, such as would occur when downloading and decompressing a large

object stream to access a single compressed object, the number of objects in an individual object stream

should be limited. This may require a group of object streams to be linked as a collection, which can be done

by means of the Extends entry in the object stream dictionary.

NOTE 5

Extends may also be used when a collection is being updated to include new objects. Rather than modifying

the original object stream, which could entail duplicating much of the stream data, the new objects can be

stored in a separate object stream. This is particularly important when adding an update section to a

document.

The stream data in an object stream shall contain the following items:

•

N pairs of integers separated by white space, where the first integer in each pair shall represent the object

number of a compressed object and the second integer shall represent the byte offset in the decoded

stream of that object, relative to the first object stored in the object stream, the value of the stream's first

entry. The offsets shall be in increasing order.

NOTE 6

There is no restriction on the order of objects in the object stream; in particular, the objects need not be stored

in object-number order.

•

The value of the First entry in the stream dictionary shall be the byte offset in the decoded stream of the

first object.

•

The N objects are stored consecutively. Only the object values are stored in the stream; the obj and

endobj keywords shall not be used.

NOTE 7

A compressed dictionary or array may contain indirect references.

An object in an object stream shall not consist solely of an object reference.

46

•

The cross-reference stream shall not be encrypted and strings appearing in the cross-reference stream

dictionary shall not be encrypted. It shall not have a Filter entry that specifies a Crypt filter (see 7.4.10,

"Crypt Filter").

Table 17 - Additional entries specific to a cross-reference stream dictionary

key

type

description

Type

name

(Required) The type of PDF object that this dictionary describes; shall be

XRef for a cross-reference stream.

Size

integer

(Required) The number one greater than the highest object number used in

this section or in any section for which this shall be an update. It shall be

equivalent to the Size entry in a trailer dictionary.

Index

array

(Optional) An array containing a pair of integers for each subsection in this

section. The first integer shall be the first object number in the subsection;

the second integer shall be the number of entries in the subsection

The array shall be sorted in ascending order by object number. Subsections

cannot overlap; an object number may have at most one entry in a section.

Default value: [0 Size].

Prev

integer

(Present only if the file has more than one cross-reference stream; not

meaningful in hybrid-reference files; see

7.5.8.4, "Compatibility with

Applications That Do Not Support Compressed Reference Streams") The

byte offset in the decoded stream from the beginning of the file to the

beginning of the previous cross-reference stream. This entry has the same

function as the Prev entry in the trailer dictionary (Table 15).

W

array

(Required) An array of integers representing the size of the fields in a single

cross-reference entry. Table 18 describes the types of entries and their

fields. For PDF 1.5, W always contains three integers; the value of each

integer shall be the number of bytes (in the decoded stream) of the

corresponding field.

EXAMPLE

[1 2 1] means that the fields are one byte, two bytes, and

one byte, respectively.

A value of zero for an element in the W array indicates that the

corresponding field shall not be present in the stream, and the default value

shall be used, if there is one. If the first element is zero, the type field shall

not be present, and shall default to type 1.

The sum of the items shall be the total length of each entry; it can be used

with the Index array to determine the starting position of each subsection.

Different cross-reference streams in a PDF file may use different values for

W.

7.5.8.3

Cross-Reference Stream Data

Each entry in a cross-reference stream shall have one or more fields, the first of which designates the entry’s

type (see Table 18). In PDF 1.5 through PDF 1.7, only types 0, 1, and 2 are allowed. Any other value shall be

interpreted as a reference to the null object, thus permitting new entry types to be defined in the future.

50

The fields are written in increasing order of field number; the length of each field shall be determined by the

corresponding value in the W entry (see Table 17). Fields requiring more than one byte are stored with the

high-order byte first.

Table 18 - Entries in a cross-reference stream

Type

Field

Description

0

1

The type of this entry, which shall be 0. Type 0 entries define

the linked list of free objects (corresponding to f entries in a

cross-reference table).

2

The object number of the next free object.

3

The generation number to use if this object number is used

again.

1

1

The type of this entry, which shall be 1. Type 1 entries define

objects that are in use but are not compressed (corresponding

to n entries in a cross-reference table).

2

The byte offset of the object, starting from the beginning of the

file.

3

The generation number of the object. Default value: 0.

2

1

The type of this entry, which shall be 2. Type 2 entries define

compressed objects.

2

The object number of the object stream in which this object is

stored. (The generation number of the object stream shall be

implicitly 0.)

3

The index of this object within the object stream.

Like any stream, a cross-reference stream shall be an indirect object. Therefore, an entry for it shall exist in

either a cross-reference stream (usually itself) or in a cross-reference table (in hybrid-reference files; see

7.5.8.4, "Compatibility with Applications That Do Not Support Compressed Reference Streams").

7.5.8.4

Compatibility with Applications That Do Not Support Compressed Reference Streams

Readers designed only to support versions of PDF before PDF 1.5, and hence do not support cross-reference

streams, cannot access objects that are referenced by cross-reference streams. If a file uses cross-reference

streams exclusively, it cannot be opened by such readers.

However, it is possible to construct a file called a hybrid-reference file that is readable by readers designed only

to support versions of PDF before PDF 1.5. Such a file contains objects referenced by standard cross-

reference tables in addition to objects in object streams that are referenced by cross-reference streams.

In these files, the trailer dictionary may contain, in addition to the entry for trailers shown in Table 15, an entry,

as shown in Table 19. This entry may be ignored by readers designed only to support versions of PDF before

PDF 1.5, which therefore have no access to entries in the cross-reference stream the entry refers to.

Table 19 - Additional entries in a hybrid-reference file’s trailer dictionary

Key

Type

Value

XRefStm

integer

(Optional) The byte offset in the decoded stream from the beginning of the file

of a cross-reference stream.

51

Security Handler."

Entries for public-key security handlers are described in

7.6.4, "Public-Key Security

Handlers."

Table 20 - Entries common to all encryption dictionaries

Key

Type

Value

Filter

name

(Required) The name of the preferred security handler for this document. It shall

be the name of the security handler that was used to encrypt the document. If

SubFilter is not present, only this security handler shall be used when opening

the document. If it is present, a conforming reader can use any security handler

that implements the format specified by SubFilter.

Standard shall be the name of the built-in password-based security handler.

Names for other security handlers may be registered by using the procedure

described in Annex E.

SubFilter

name

(Optional; PDF

1.3) A name that completely specifies the format and

interpretation of the contents of the encryption dictionary. It allows security

handlers other than the one specified by Filter to decrypt the document. If this

entry is absent, other security handlers shall not decrypt the document.

NOTE

This entry was introduced in PDF 1.3 to support the use of public-

key cryptography in PDF files

(see 7.6.4, "Public-Key Security

Handlers"); however, it was not incorporated into the PDF

Reference until the fourth edition (PDF 1.5).

V

number

(Optional) A code specifying the algorithm to be used in encrypting and

decrypting the document:

0

An algorithm that is undocumented. This value shall not be used.

1

"Algorithm 1: Encryption of data using the RC4 or AES algorithms" in 7.6.2,

"General Encryption Algorithm," with an encryption key length of 40 bits; see

below.

2

(PDF 1.4) "Algorithm 1: Encryption of data using the RC4 or AES algorithms"

in 7.6.2, "General Encryption Algorithm," but permitting encryption key lengths

greater than 40 bits.

3

(PDF 1.4) An unpublished algorithm that permits encryption key lengths

ranging from 40 to 128 bits. This value shall not appear in a conforming PDF

file.

4

(PDF 1.5) The security handler defines the use of encryption and decryption

in the document, using the rules specified by the CF, StmF, and StrF entries.

The default value if this entry is omitted shall be 0, but when present should be a

value of 1 or greater.

Length

integer

(Optional; PDF 1.4; only if V is 2 or 3) The length of the encryption key, in bits.

The value shall be a multiple of 8, in the range 40 to 128. Default value: 40.

CF

dictionary

(Optional; meaningful only when the value of V is 4; PDF 1.5) A dictionary whose

keys shall be crypt filter names and whose values shall be the corresponding

crypt filter dictionaries (see Table 25). Every crypt filter used in the document

shall have an entry in this dictionary, except for the standard crypt filter names

(see Table 26).

The conforming reader shall ignore entries in CF dictionary with the keys equal to

those listed in Table 26 and use properties of the respective standard crypt filters.

StmF

name

(Optional; meaningful only when the value of V is 4; PDF 1.5) The name of the

crypt filter that shall be used by default when decrypting streams. The name shall

be a key in the CF dictionary or a standard crypt filter name specified in Table 26.

All streams in the document, except for cross-reference streams (see 7.5.8,

"Cross-Reference Streams") or streams that have a Crypt entry in their Filter

array (see Table 6), shall be decrypted by the security handler, using this crypt

filter.

Default value: Identity.

56

Table 20 - Entries common to all encryption dictionaries (continued)

Key

Type

Value

StrF

name

(Optional; meaningful only when the value of V is 4; PDF 1.5) The name of the

crypt filter that shall be used when decrypting all strings in the document. The

name shall be a key in the CF dictionary or a standard crypt filter name specified

in Table 26.

Default value: Identity.

EFF

name

(Optional; meaningful only when the value of V is 4; PDF 1.6) The name of the

crypt filter that shall be used when encrypting embedded file streams that do not

have their own crypt filter specifier; it shall correspond to a key in the CF

dictionary or a standard crypt filter name specified in Table 26.

This entry shall be provided by the security handler. Conforming writers shall

respect this value when encrypting embedded files, except for embedded file

streams that have their own crypt filter specifier. If this entry is not present, and

the embedded file stream does not contain a crypt filter specifier, the stream shall

be encrypted using the default stream crypt filter specified by StmF.

Unlike strings within the body of the document, those in the encryption dictionary shall be direct objects. The

contents of the encryption dictionary shall not be encrypted (the algorithm specified by the V entry). Security

handlers shall be responsible for encrypting any data in the encryption dictionary that they need to protect.

NOTE

Conforming writers have two choices if the encryption methods and syntax provided by PDF are not sufficient

for their needs: they can provide an alternate security handler or they can encrypt whole PDF documents

themselves, not making use of PDF security.

7.6.2

General Encryption Algorithm

One of the following algorithms shall be used when encrypting data in a PDF file:

•

A proprietary encryption algorithm known as RC4. RC4 is a symmetric stream cipher: the same algorithm

shall be used for both encryption and decryption, and the algorithm does not change the length of the data.

RC4 is a copyrighted, proprietary algorithm of RSA Security, Inc. Independent software vendors may be

required to license RC4 to develop software that encrypts or decrypts PDF documents. For further

information, visit the RSA Web site at

< http://www.rsasecurity.com > or send e-mail to

< products@rsasecurity.com >.

•

The AES (Advanced Encryption Standard) algorithm (beginning with PDF 1.6). AES is a symmetric block

cipher: the same algorithm shall be used for both encryption and decryption, and the length of the data

when encrypted is rounded up to a multiple of the block size, which is fixed to always be 16 bytes, as

specified in FIPS 197, Advanced Encryption Standard (AES); see the Bibliography).

Strings and streams encrypted with AES shall use a padding scheme that is described in Internet RFC

2898, PKCS #5: Password-Based Cryptography Specification Version 2.0; see the Bibliography. For an

original message length of M, the pad shall consist of 16 - (M mod 16) bytes whose value shall also be 16

- (M mod 16).

EXAMPLE

A 9-byte message has a pad of 7 bytes, each with the value 0x07. The pad can be unambiguously

removed to determine the original message length when decrypting. Note that the pad is present when M

is evenly divisible by 16; it contains 16 bytes of 0x10.

PDF’s standard encryption methods also make use of the MD5 message-digest algorithm for key generation

purposes (described in Internet RFC 1321, The MD5 Message-Digest Algorithm; see the Bibliography).

The encryption of data in a PDF file shall be based on the use of an encryption key computed by the security

handler. Different security handlers compute the encryption key using their own mechanisms. Regardless of

how the key is computed, its use in the encryption of data shall always be the same (see "Algorithm 1:

57

place of StdCF name. This nomenclature shall not be used as indicator of the type of the security handler or

encryption.

Once the document has been opened and decrypted successfully, a conforming reader technically has access

to the entire contents of the document. There is nothing inherent in PDF encryption that enforces the document

permissions specified in the encryption dictionary. Conforming readers shall respect the intent of the document

creator by restricting user access to an encrypted PDF file according to the permissions contained in the file.

NOTE 2

PDF 1.5 introduces a set of access permissions that do not require the document to be encrypted (see 12.8.4,

"Permissions"). This enables limited access to a document when a user is not be able to respond to a prompt

for a password. For example, there may be conforming readers that do not have a person running them such

as printing off-line or on a server.

7.6.3.2

Standard Encryption Dictionary

Table 21 shows the encryption dictionary entries for the standard security handler (in addition to those in

Table 20).

Table 21 - Additional encryption dictionary entries for the standard security handler

Key

Type

Value

R

number

(Required) A number specifying which revision of the standard security

handler shall be used to interpret this dictionary:

2

if the document is encrypted with a V value less than 2 (see Table 20)

and does not have any of the access permissions set to 0 (by means of

the P entry, below) that are designated “Security handlers of revision 3

or greater” in Table 22

3

if the document is encrypted with a V value of 2 or 3, or has any

“Security handlers of revision 3 or greater” access permissions set to 0

4

if the document is encrypted with a V value of 4

O

string

(Required) A 32-byte string, based on both the owner and user passwords,

that shall be used in computing the encryption key and in determining

whether a valid owner password was entered. For more information, see

7.6.3.3, "Encryption Key Algorithm," and 7.6.3.4, "Password Algorithms."

U

string

(Required) A 32-byte string, based on the user password, that shall be

used in determining whether to prompt the user for a password and, if so,

whether a valid user or owner password was entered. For more

information, see 7.6.3.4, "Password Algorithms."

P

integer

(Required) A set of flags specifying which operations shall be permitted

when the document is opened with user access (see Table 22).

EncryptMetadata

boolean

(Optional; meaningful only when the value of V is 4; PDF 1.5) Indicates

whether the document-level metadata stream

(see

14.3.2, "Metadata

Streams") shall be encrypted. Conforming products should respect this

value.

Default value: true.

The values of the O and U entries in this dictionary shall be used to determine whether a password entered

when the document is opened is the correct owner password, user password, or neither.

The value of the P entry shall be interpreted as an unsigned 32-bit quantity containing a set of flags specifying

which access permissions shall be granted when the document is opened with user access. Table 22 shows

the meanings of these flags. Bit positions within the flag word shall be numbered from 1 (low-order) to 32 (high-

order). A

1 bit in any position shall enable the corresponding access permission. Which bits shall be

meaningful, and in some cases how they shall be interpreted, shall depend on the security handler’s revision

number (specified in the encryption dictionary’s R entry).

60

Conforming readers shall ignore all flags other than those at bit positions 3, 4, 5, 6, 9, 10, 11, and 12.

NOTE

PDF integer objects can be interpreted as binary values in a signed twos-complement form. Since all the

reserved high-order flag bits in the encryption dictionary’s P value are required to be 1, the integer value P

shall be specified as a negative integer. For example, assuming revision 2 of the security handler, the value -

44 permits printing and copying but disallows modifying the contents and annotations.

Table 22 - User access permissions

Bit position

Meaning

3

(Security handlers of revision 2) Print the document.

(Security handlers of revision

3 or greater) Print the

document

(possibly not at the highest quality level,

depending on whether bit 12 is also set).

4

Modify the contents of the document by operations other than

those controlled by bits 6, 9, and 11.

5

(Security handlers of revision 2) Copy or otherwise extract

text and graphics from the document, including extracting text

and graphics

(in support of accessibility to users with

disabilities or for other purposes).

(Security handlers of revision 3 or greater) Copy or otherwise

extract text and graphics from the document by operations

other than that controlled by bit 10.

6

Add or modify text annotations, fill in interactive form fields,

and, if bit 4 is also set, create or modify interactive form fields

(including signature fields).

9

(Security handlers of revision 3 or greater) Fill in existing

interactive form fields (including signature fields), even if bit 6

is clear.

10

(Security handlers of revision 3 or greater) Extract text and

graphics (in support of accessibility to users with disabilities

or for other purposes).

11

(Security handlers of revision 3 or greater) Assemble the

document

(insert, rotate, or delete pages and create

bookmarks or thumbnail images), even if bit 4 is clear.

12

(Security handlers of revision

3 or greater) Print the

document to a representation from which a faithful digital

copy of the PDF content could be generated. When this bit is

clear

(and bit

3 is set), printing is limited to a low-level

representation of the appearance, possibly of degraded

quality.

7.6.3.3 Encryption Key Algorithm

As noted earlier, one function of a security handler is to generate an encryption key for use in encrypting and

decrypting the contents of a document. Given a password string, the standard security handler computes an

encryption key as shown in "Algorithm 2: Computing an encryption key".

Algorithm 2: Computing an encryption key

a) Pad or truncate the password string to exactly 32 bytes. If the password string is more than 32 bytes long,

use only its first 32 bytes; if it is less than 32 bytes long, pad it by appending the required number of

additional bytes from the beginning of the following padding string:

61

NOTE

Examples of existing security handlers that support public-key encryption are Entrust.PPKEF,

Adobe.PPKLite, and Adobe.PubSec. This handler will be the preferred handler when encrypting the

document.

Permitted values of the SubFilter entry for use with conforming public-key security handlers are

adbe.pkcs7.s3, adbe.pkcs7.s4, which shall be used when not using crypt filters (see 7.6.5, "Crypt Filters")

and adbe.pkcs7.s5, which shall be used when using crypt filters.

The CF, StmF, and StrF entries may be present when SubFilter is adbe.pkcs7.s5.

Table 23 - Additional encryption dictionary entries for public-key security handlers

Key

Type

Value

Recipients

array

(Required when SubFilter is adbe.pkcs7.s3 or adbe.pkcs7.s4; PDF 1.3)

An array of byte-strings, where each string is a PKCS#7 object listing

recipients who have been granted equal access rights to the document. The

data contained in the PKCS#7 object shall include both a cryptographic key

that shall be used to decrypt the encrypted data and the access permissions

(see Table 24) that apply to the recipient list. There shall be only one

PKCS#7 object per unique set of access permissions; if a recipient appears

in more than one list, the permissions used shall be those in the first

matching list.

When SubFilter is adbe.pkcs7.s5, recipient lists shall be specified in the

crypt filter dictionary; see Table 27.

P

integer

(Required) A set of flags specifying which operations shall be permitted

when the document is opened with user access. If bit 2 is set to 1, all other

bits are ignored and all operations are permitted. If bit

2 is set to

0,

permission for operations are based on the values of the remaining flags

defined in Table 24.

The value of the P entry shall be interpreted as an unsigned 32-bit quantity containing a set of flags specifying

which access permissions shall be granted when the document is opened with user access. Table 24 shows

the meanings of these flags. Bit positions within the flag word shall be numbered from 1 (low-order) to 32 (high-

order). A 1 bit in any position shall enable the corresponding access permission.

Conforming readers shall ignore all flags other than those at bit positions 2, 3, 4, 5, 6, 9, 10, 11, and 12.

Table 24 - Public-Key security handler user access permissions

Bit position

Meaning

2

When set permits change of encryption and enables all other

permissions.

3

Print the document (possibly not at the highest quality level,

depending on whether bit 12 is also set).

4

Modify the contents of the document by operations other than

those controlled by bits 6, 9, and 11.

5

Copy or otherwise extract text and graphics from the

document by operations other than that controlled by bit 10.

6

Add or modify text annotations, fill in interactive form fields,

and, if bit 4 is also set, create or modify interactive form fields

(including signature fields).

9

Fill in existing interactive form fields

(including signature

fields), even if bit 6 is clear.

10

Extract text and graphics (in support of accessibility to users

with disabilities or for other purposes).

65

Table 24 - Public-Key security handler user access permissions (continued)

Bit position

Meaning

11

Assemble the document (insert, rotate, or delete pages and

create bookmarks or thumbnail images), even if bit 4 is clear.

12

Print the document to a representation from which a faithful

digital copy of the PDF content could be generated. When

this bit is clear (and bit 3 is set), printing is limited to a low-

level representation of the appearance, possibly of degraded

quality.

7.6.4.3

Public-Key Encryption Algorithms

Figure 4 illustrates how PKCS#7 objects shall be used when encrypting PDF files. A PKCS#7 object is

designed to encapsulate and encrypt what is referred to as the enveloped data.

Plaintext byte array

PKCS#7 Object

20-byte seed

Permissions*

* Permissions not pres-

Enveloped data

ent when PKCS#7 object

Decrypt

is referenced from Crypt

filter decode parameter

dictionary

Plaintext key

Used to generate

encryption key

John Doe

Decrypt

Encrypted key

Jeff Smith

Encrypted key

John Doe’s private key

Figure 4 - Public-key encryption algorithm

The enveloped data in the PKCS#7 object contains keying material that shall be used to decrypt the document

(or individual strings or streams in the document, when crypt filters are used; see 7.6.5, "Crypt Filters"). A key

shall be used to encrypt (and decrypt) the enveloped data. This key (the plaintext key in Figure 4) shall be

encrypted for each recipient, using that recipient’s public key, and shall be stored in the PKCS#7 object (as the

encrypted key for each recipient). To decrypt the document, that key shall be decrypted using the recipient’s

private key, which yields a decrypted (plaintext) key. That key, in turn, shall be used to decrypt the enveloped

data in the PKCS#7 object, resulting in a byte array that includes the following information:

•

A 20-byte seed that shall be used to create the encryption key that is used by "Algorithm 1: Encryption of

data using the RC4 or AES algorithms". The seed shall be a unique random number generated by the

security handler that encrypted the document.

•

A 4-byte value defining the permissions, least significant byte first. See Table 24 for the possible

permission values.

•

When SubFilter is adbe.pkcs7.s3, the relevant permissions shall be only those specified for revision 2 of

the standard security handler.

•

For adbe.pkcs7.s4, security handlers of revision 3 permissions shall apply.

•

For adbe.pkcs7.s5, which supports the use of crypt filters, the permissions shall be the same as

adbe.pkcs7.s4 when the crypt filter is referenced from the StmF or StrF entries of the encryption

66

A value of None for the CFM entry in the crypt filter dictionary allows the security handler to do its own

decryption. This allows the handler to tightly control key management and use any preferred symmetric-key

cryptographic algorithm.

Table 25 - Entries common to all crypt filter dictionaries

Key

Type

Value

Type

name

(Optional) If present, shall be CryptFilter for a crypt filter dictionary.

CFM

name

(Optional) The method used, if any, by the conforming reader to

decrypt data. The following values shall be supported:

None The application shall not decrypt data but shall direct the

input stream to the security handler for decryption.

V2

The application shall ask the security handler for the

encryption key and shall implicitly decrypt data with

"Algorithm 1: Encryption of data using the RC4 or AES

algorithms", using the RC4 algorithm.

AESV2

(PDF 1.6) The application shall ask the security handler for

the encryption key and shall implicitly decrypt data with

"Algorithm 1: Encryption of data using the RC4 or AES

algorithms", using the AES algorithm in Cipher Block

Chaining (CBC) mode with a 16-byte block size and an

initialization vector that shall be randomly generated and

placed as the first 16 bytes in the stream or string.

When the value is V2 or AESV2, the application may ask once for this

encryption key and cache the key for subsequent use for streams that

use the same crypt filter. Therefore, there shall be a one-to-one

relationship between a crypt filter name and the corresponding

encryption key.

Only the values listed here shall be supported. Applications that

encounter other values shall report that the file is encrypted with an

unsupported algorithm.

Default value: None.

AuthEvent

name

(Optional) The event to be used to trigger the authorization that is

required to access encryption keys used by this filter. If authorization

fails, the event shall fail. Valid values shall be:

DocOpen: Authorization shall be required when a document is

opened.

EFOpen: Authorization shall be required when accessing

embedded files.

Default value: DocOpen.

If this filter is used as the value of StrF or StmF in the encryption

dictionary (see Table 20), the conforming reader shall ignore this key

and behave as if the value is DocOpen.

Length

integer

(Optional) The bit length of the encryption key. It shall be a multiple of

8 in the range of 40 to 128.

Security handlers may define their own use of the Length entry and

should use it to define the bit length of the encryption key. Standard

security handler expresses the length in multiples of 8 (16 means 128)

and public-key security handler expresses it as is (128 means 128).

68

Security handlers may add their own private data to crypt filter dictionaries. Names for private data entries shall

conform to the PDF name registry (see Annex E).

Table 26 - Standard crypt filter names

Name

Description

Identity

Input data shall be passed through without any processing.

Table 27 lists the additional crypt filter dictionary entries used by public-key security handlers (see 7.6.4,

"Public-Key Security Handlers"). When these entries are present, the value of CFM shall be V2 or AESV2.

Table 27 - Additional crypt filter dictionary entries for public-key security handlers

Key

Type

Value

Recipients

array or

(Required) If the crypt filter is referenced from StmF or StrF in the

string

encryption dictionary, this entry shall be an array of byte strings, where

each string shall be a binary-encoded PKCS#7 object that shall list

recipients that have been granted equal access rights to the

document. The enveloped data contained in the PKCS#7 object shall

include both a 20-byte seed value that shall be used to compute the

encryption key

(see

7.6.4.3, "Public-Key Encryption Algorithms")

followed by 4 bytes of permissions settings (see Table 22) that shall

apply to the recipient list. There shall be only one object per unique set

of access permissions. If a recipient appears in more than one list, the

permissions used shall be those in the first matching list.

If the crypt filter is referenced from a Crypt filter decode parameter

dictionary (see Table 14), this entry shall be a string that shall be a

binary-encoded PKCS#7 object shall contain a list of all recipients who

are permitted to access the corresponding encrypted stream. The

enveloped data contained in the PKCS#7 object shall be a 20-byte

seed value that shall be used to create the encryption key that shall be

used by the algorithm in "Algorithm 1: Encryption of data using the

RC4 or AES algorithms".

EncryptMetadata

boolean

(Optional; used only by crypt filters that are referenced from StmF in

an encryption dictionary) Indicates whether the document-level

metadata stream (see 14.3.2, "Metadata Streams") shall be encrypted.

Conforming readers shall respect this value when determining whether

metadata shall be encrypted. The value of the EncryptMetadata entry

is set by the security handler rather than the conforming reader.

Default value: true.

EXAMPLE

The following shows the use of crypt filters in an encrypted document containing a plaintext document-

level metadata stream. The metadata stream is left as is by applying the Identity crypt filter. The

remaining streams and strings are decrypted using the default filters.

%PDF-1.5

1 0 obj

% Document catalog

<< /Type /Catalog

/Pages 2 0 R

/Metadata 6 0 R

>>

endobj

2 0 obj

% Page tree

<< /Type /Pages

/Kids [3 0 R]

/Count 1

>>

endobj

3 0 obj

% 1s t page

<< /Type /Page

69

Content

stream

Thumbnail

Page

image

•

Annotations

Page

tree

•

•

•

•

•

Page

•

•

•

•

•

•

Outline

entry

•

Outline

hierarchy

•

•

Outline

entry

Document catalog

Thread

Bead

•

•

•

•

Article

threads

•

•

Bead

Thread

•

•

•

Named

destinations

Interactive

form

Figure 5 - Structure of a PDF document

72

Content      ..      1      2      3      ..