Repository navigation
PDF Spec 12 Signatures
Part of: PDF-Spec-12-Interactive-Features
Navigation: PDF-Spec-12-Forms | PDF-Spec-Index | PDF-Spec-12-Security
- HTML Form format (described in the HTML 4.01 Specification )
- Forms Data Format (FDF), which is described in 12.7.7, 'Forms Data Format.'
- XFDF, a version of FDF based on XML. XFDF is described in the Adobe technical note XML Forms Data Format Specification, Version 2.0. XML is described in the W3C document Extensible Markup Language (XML) 1.1 )
- PDF (in this case, the entire document shall be submitted rather than individual fields and values).
The name submitted for each field shall be its fully qualified name (see 12.7.3.2, 'Field Names'), and the value shall be specified by the V entry in its field dictionary.
For pushbutton fields submitted in FDF, the value submitted shall be that of the AP entry in the field's widget annotation dictionary. If the submit-form action dictionary contains no Fields entry, such pushbutton fields shall not be submitted.
Fields with no value (that is, whose field dictionary does not contain a V entry) are ordinarily not included in the submission. The submit-form action's IncludeNoValueFields flag may override this behaviour. If this flag is set, such valueless fields shall be included in the submission by name only, with no associated value.
Upon invocation of a reset-form action , a conforming processor shall reset selected interactive form fields to their default values; that is, it shall set the value of the V entry in the field dictionary to that of the DV entry (see Table 220). If no default value is defined for a field, its V entry shall be removed. For fields that can have no value (such as pushbuttons), the action has no effect. Table 238 shows the action dictionary entries specific to this type of action.
The value of the action dictionary's Flags entry is a non-negative containing flags specifying various characteristics of the action. Bit positions within the flag word shall be numbered starting from 1 (low-order). Only one flag is defined for this type of action. All undefined flag bits shall be reserved and shall be set to 0.
Table 238 - Additional entries specific to a reset-form action
| Key | Type | Value |
|---|---|---|
| S | name | (Required) The type of action that this dictionary describes; shall be ResetForm for a reset-form action. |
| Fields | array | (Optional) An array identifying which fields to reset or which to exclude from resetting, depending on the setting of the Include/ Exclude flag in the Flags entry (see Table 239). Each element of the array shall be either an indirect reference to a field dictionary or (PDF 1.3) a text string representing the fully qualified name of a field. Elements of both kinds may be mixed in the same array. If this entry is omitted, the Include/Exclude flag shall be ignored; all fields in the document's interactive form are reset. |
| Flags | integer | (Optional; inheritable) A set of flags specifying various characteristics of the action (see Table 239). Default value: 0. |
Table 239 - Flag for reset-form actions
| Bit position | Name | Meaning |
|---|---|---|
| 1 | Include/Exclude | If clear, the Fields array (see Table 238) specifies which fields to reset. (All descendants of the specified fields in the field hierarchy are reset as well.) If set, the Fields array indicates which fields to exclude from resetting; that is, all fields in the document's interactive form shall be reset except those listed in the Fields array. |
Upon invocation of an import-data action , a conforming processor shall import Forms Data Format (FDF) data into the document's interactive form from a specified file.
Table 240 - Additional entries specific to an import-data action
| Key | Type | Value |
|---|---|---|
| S | name | (Required) The type of action that this dictionary describes; shall be ImportData for an import-data action. |
| F | file specification | (Required) The FDF file from which to import the data. |
The optional Pages entry (PDF 1.3) in a document's name dictionary (see 7.7.4, 'Name Dictionary') contains a name tree that maps name strings to individual pages within the document. Naming a page allows it to be referenced in two different ways:
- An import-data action can add the named page to the document into which FDF is being imported, either as a page or as a button appearance.
- A script executed by a JavaScript action can add the named page to the current document as a regular page.
A named page that is intended to be visible to a user shall be left in the page tree (see 7.7.3, 'Page Tree'), and there shall be a reference to it in the appropriate leaf node of the name dictionary's Pages tree. If the page is not intended to be displayed by the reader, it shall be referenced from the name dictionary's Templates tree instead. Such invisible pages shall have an object type of Template rather than Page and shall have no Parent or B entry (see Table 30).
This sub-clause describes Forms Data Format (FDF), the file format used for interactive form data (PDF 1.2) . FDF can be used when submitting form data to a server, receiving the response, and incorporating it into the interactive form. It can also be used to export form data to stand-alone files that can be stored, transmitted electronically, and imported back into the corresponding PDF interactive form. In addition, beginning in PDF 1.3, FDF can be used to define a container for annotations that are separate from the PDF document to which they apply.
FDF is based on PDF; it uses the same syntax and has essentially the same file structure (7.5, 'File Structure'). However, it differs from PDF in the following ways:
- The cross-reference table (7.5.4, 'Cross-Reference Table') is optional.
- FDF files shall not be updated (see 7.5.6, 'Incremental Updates'). Objects shall only be of generation 0, and no two objects within an FDF file shall have the same object number.
- The document structure is much simpler than PDF, since the body of an FDF document consists of only one required object.
- The length of a stream shall not be specified by an indirect object.
FDF uses the MIME content type application / vnd . fdf. On the Windows and UNIX platforms, FDF files have the extension . fdf; on Mac OS, they have file type ' FDF '.
An FDF file shall be structured in essentially the same way as a PDF file but contains only those elements required for the export and import of interactive form and annotation data. It consists of three required elements and one optional element (see Figure 65):
- A one-line header identifying the version number of the PDF specification to which the file conforms
- A body containing the objects that make up the content of the file
- An optional cross-reference table containing information about the indirect objects in the file
- An optional trailer giving the location of the cross-reference table and of certain special objects within the body of the file
Figure 65 - FDF file structure
The first line of an FDF file shall be a header , which shall contain
The version number is given by the Version entry in the FDF catalogue dictionary (see 12.7.7.3, 'FDF Catalog').
The body of an FDF file shall consist of a sequence of indirect objects representing the file's catalogue (see 12.7.7.3, 'FDF Catalog') and any additional objects that the catalogue references. The objects are of the same basic types described in 7.5, 'File Structure' (other than the %PDF-n.m and %%EOF comments described in 7.5, 'File Structure') have no semantics. They are not necessarily preserved by applications that edit PDF files.' Just as in PDF, objects in FDF can be direct or indirect.
The trailer of an FDF file enables a reader to find significant objects quickly within the body of the file. The last line of the file contains only the end-of-file marker, %%EOF. This marker shall be preceded by the FDF trailer dictionary , consisting of the keyword trailer followed by a series of one or more key-value pairs enclosed in double angle brackets (<< … >>) (using LESS-THAN SIGNs (3Ch) and GREATER-THAN SIGNs (3Eh)). The only required key is Root , whose value is an indirect reference to the file's catalogue dictionary (see Table 242). The trailer may optionally contain additional entries for objects that are referenced from within the catalogue.
Table 241 - Entry in the FDF trailer dictionary
| Key | Type | Value |
|---|---|---|
| Root | dictionary | (Required; shall be an indirect reference) The Catalog object for this FDF file (see 12.7.7.3, 'FDF Catalog'). |
Thus, the trailer has the overall structure
trailer << /Root c 0 R key 2 value 2 … key n value n >> %%EOF
where c is the object number of the file's catalogue dictionary.
The root node of an FDF file's object hierarchy is the Catalog dictionary, located by means of the Root entry in the file's trailer dictionary (see FDF Trailer in 12.7.7.2, 'FDF File Structure'). As shown in Table 241, the only required entry in the catalogue is FDF ; its value shall be an FDF dictionary (Table 243), which in turn shall contain references to other objects describing the file's contents. The catalogue may also contain an optional Version entry identifying the version of the PDF specification to which this FDF file conforms.
Table 242 - Entries in the FDF catalog dictionary
| Key | Type | Value |
|---|---|---|
| Version | name | (Optional; PDF 1.4) The version of the FDF specification to which this FDF file conforms (for example, 1.4) if later than the version specified in the file's header (see FDF Header in 12.7.7.2, 'FDF File Structure'). If the header specifies a later version, or if this entry is absent, the document conforms to the version specified in the header. The value of this entry is a name object, not a number, and therefore shall be preceded by a slash character ( / ) when written in the FDF file (for example, /1.4 ). |
| FDF | dictionary | (Required) The FDF dictionary for this file (see Table 243). |
Table 243 - Entries in the FDF dictionary
| Key | Type | Value |
|---|---|---|
| F | file specification | (Optional) The source file or target file : the PDF document file that this FDF file was exported from or is intended to be imported into. |
| ID | array | (Optional) An array of two byte strings constituting a file identifier (see 14.4, 'File Identifiers') for the source or target file designated by F , taken from the ID entry in the file's trailer dictionary (see 7.5.5, 'File Trailer'). |
| Fields | array | (Optional) An array of FDF field dictionaries (see FDF Fields in 12.7.7.3, 'FDF Catalog') describing the root fields (those with no ancestors in the field hierarchy) that shall be exported or imported. This entry and the Pages entry shall not both be present. |
| Status | PDFDocEncoded string | (Optional) A status string that shall be displayed indicating the result of an action, typically a submit-form action (see 12.7.5.2, 'Submit-Form Action'). The string shall be encoded with PDFDocEncoding . This entry and the Pages entry shall not both be present. |
| Pages | array | (Optional; PDF 1.3) An array of FDF page dictionaries (see FDF Pages in 12.7.7.3, 'FDF Catalog') describing pages that shall be added to a PDF target document. The Fields and Status entries shall not be present together with this entry. |
| Encoding | name | (Optional; PDF 1.3) The encoding that shall be used for any FDF field value or option ( V or Opt in the field dictionary; see Table 246) or field name that is a string and does not begin with the Unicode prefix U+FEFF. Default value: PDFDocEncoding . Other allowed values include Shift_JIS , BigFive , GBK , UHC , utf_8 , utf_16 |
| Annots | array | (Optional; PDF 1.3) An array of FDF annotation dictionaries (see FDF Annotation Dictionaries in 12.7.7.3, 'FDF Catalog'). The array may include annotations of any of the standard types listed in Table 169 except Link , Movie , Widget , PrinterMark , Screen , and TrapNet . |
Table 243 - Entries in the FDF dictionary (continued)
| Key | Type | Value |
|---|---|---|
| Differences | stream | (Optional; PDF 1.4) A stream containing all the bytes in all incremental updates made to the underlying PDF document since it was opened (see 7.5.6, 'Incremental Updates'). If a submit-form action submitting the document to a remote server as FDF has its IncludeAppendSaves flag set (see 12.7.5.2, 'Submit-Form Action'), the contents of this stream shall be included in the submission. This allows any digital signatures (see 12.8, 'Digital Signatures') to be transmitted to the server. An incremental update shall be automatically performed just before the submission takes place, in order to capture all changes made to the document. The submission shall include the full set of incremental updates back to the time the document was first opened, even if some of them may already have been included in intervening submissions. Although a Fields or Annots entry (or both) may be present along with Differences , there is no requirement that their contents will be consistent with each other. In particular, if Differences contains a digital signature, only the values of the form fields given in the Differences stream shall be considered trustworthy under that signature. |
| Target | string | (Optional; PDF 1.4) The name of a browser frame in which the underlying PDF document shall be opened. This mimics the behaviour of the target attribute in HTML tags. |
| EmbeddedFDFs | array | (Optional; PDF 1.4) An array of file specifications (see 7.11, 'File Specifications') representing other FDF files embedded within this one (7.11.4, 'Embedded File Streams'). |
| JavaScript | dictionary | (Optional; PDF 1.4) A JavaScript dictionary (see Table 245) defining document-level JavaScript scripts. |
Embedded FDF files specified in the FDF dictionary's EmbeddedFDFs entry may be encrypted. Besides the usual entries for an embedded file stream, the stream dictionary representing such an encrypted FDF file shall contain the additional entry shown in Table 244 to identify the revision number of the FDF encryption algorithm used to encrypt the file. Although the FDF encryption mechanism is separate from the one for PDF file encryption described in 7.6, 'Encryption,' revision 1 (the only one defined) uses a similar RC4 encryption algorithm based on a 40-bit encryption key. The key shall be computed by means of an MD5 hash, using a padded user-supplied password as input. The computation shall be identical to steps (a) and (b) of the "Algorithm 2: Computing an encryption key" in 7.6.3.3, "Encryption Key Algorithm"; the first 5 bytes of the result shall be the encryption key for the embedded FDF file.
Table 244 - Additional entry in an embedded file stream dictionary for an encrypted FDF file
| Key | Type | Value |
|---|---|---|
| EncryptionRevision | integer | (Required if the FDF file is encrypted; PDF 1.4) The revision number of the FDF encryption algorithm used to encrypt the file. This value shall be defined at the time of publication is 1. |
The JavaScript entry in the FDF dictionary holds a JavaScript dictionary containing JavaScript scripts that shall be defined globally at the document level, rather than associated with individual fields. The dictionary may contain scripts defining JavaScript functions for use by other scripts in the document, as well as scripts that shall be executed immediately before and after the FDF file is imported. Table 245 shows the contents of this dictionary.
Table 245 - Entries in the JavaScript dictionary
| Key | Type | Value |
|---|---|---|
| Before | text string or text stream | (Optional) A text string or text stream containing a JavaScript script that shall be executed just before the FDF file is imported. |
| After | text string or text stream | (Optional) A text string or text stream containing a JavaScript script that shall be executed just after the FDF file is imported. |
| AfterPermsReady | text string or text stream | (Optional; PDF 1.6) A text string or text stream containing a JavaScript script that shall be executed after the FDF file is imported and the usage rights in the PDF document have been determined (see 12.8.2.3, 'UR'). Verification of usage rights requires the entire file to be present, in which case execution of this script shall be deferred until that requirement is met. |
| Doc | array | (Optional) An array defining additional JavaScript scripts that shall be added to those defined in the JavaScript entry of the document's name dictionary (see 7.7.4, 'Name Dictionary'). The array shall contain an even number of elements, organized in pairs. The first element of each pair shall be a name and the second shall be a text string or text stream defining the script corresponding to that name. Each of the defined scripts shall be added to those already defined in the name dictionary and shall then be executed before the script defined in the Before entry is executed. NOTE As described in 12.6.4.16, 'JavaScript Actions,' these scripts are used to define JavaScript functions for use by other scripts in the document. |
Each field in an FDF file shall be described by an FDF field dictionary . Table 246 shows the contents of this type of dictionary. Most of the entries have the same form and meaning as the corresponding entries in a field dictionary (Table 220, Table 222, Table 229, and Table 231) or a widget annotation dictionary (Table 168 and Table 188). Unless otherwise indicated in the table, importing a field causes the values of the entries in the FDF field dictionary to replace those of the corresponding entries in the field with the same fully qualified name in the target document.
Table 246 - Entries in an FDF field dictionary
| Key | Type | Value |
|---|---|---|
| Kids | array | (Optional) An array containing the immediate children of this field. Unlike the children of fields in a PDF file, which shall be specified as indirect object references, those of an FDF field may be either direct or indirect objects. |
| T | text string | (Required) The partial field name (see 12.7.3.2, 'Field Names'). |
| V | (various) | (Optional) The field's value, whose format varies depending on the field type; see the descriptions of individual field types in 12.7.4, 'Field Types' for further information. |
| Ff | integer | (Optional) A set of flags specifying various characteristics of the field (see Table 221, Table 226, Table 228, and Table 230). When imported into an interactive form, the value of this entry shall replace that of the Ff entry in the form's corresponding field dictionary. If this field is present, the SetFf and ClrFf entries, if any, shall be ignored. |
| SetFf | integer | (Optional) A set of flags to be set (turned on) in the Ff entry of the form's corresponding field dictionary. Bits equal to 1 in SetFf shall cause the corresponding bits in Ff to be set to 1. This entry shall be ignored if an Ff entry is present in the FDF field dictionary. |
Table 246 - Entries in an FDF field dictionary (continued)
| Key | Type | Value |
|---|---|---|
| ClrFf | integer | (Optional) A set of flags to be cleared (turned off) in the Ff entry of the form's corresponding field dictionary. Bits equal to 1 in ClrFf shall cause the corresponding bits in Ff to be set to 0. If a SetFf entry is also present in the FDF field dictionary, it shall be applied before this entry. This entry shall be ignored if an Ff entry is present in the FDF field dictionary. |
| F | integer | (Optional) A set of flags specifying various characteristics of the field's widget annotation (see 12.5.3, 'Annotation Flags'). When imported into an interactive form, the value of this entry shall replace that of the F entry in the form's corresponding annotation dictionary. If this field is present, the SetF and ClrF entries, if any, shall be ignored. |
| SetF | integer | (Optional) A set of flags to be set (turned on) in the F entry of the form's corresponding widget annotation dictionary. Bits equal to 1 in SetF shall cause the corresponding bits in F to be set to 1. This entry shall be ignored if an F entry is present in the FDF field dictionary. |
| ClrF | integer | (Optional) A set of flags to be cleared (turned off) in the F entry of the form's corresponding widget annotation dictionary. Bits equal to 1 in ClrF shall cause the corresponding bits in F to be set to 0. If a SetF entry is also present in the FDF field dictionary, it shall be applied before this entry. This entry shall be ignored if an F entry is present in the FDF field dictionary. |
| AP | dictionary | (Optional) An appearance dictionary specifying the appearance of a pushbutton field (see Pushbuttons in 12.7.4.2, 'Button Fields'). The appearance dictionary's contents are as shown in Table 168, except that the values of the N , R , and D entries shall all be streams. |
| APRef | dictionary | (Optional; PDF 1.3) A dictionary holding references to external PDF files containing the pages to use for the appearances of a pushbutton field. This dictionary is similar to an appearance dictionary (see Table 168), except that the values of the N , R , and D entries shall all be named page reference dictionaries (Table 250). This entry shall be ignored if an AP entry is present. |
| IF | dictionary | (Optional; PDF 1.3; button fields only) An icon fit dictionary (see Table 247) specifying how to display a button field's icon within the annotation rectangle of its widget annotation. |
| Opt | array | (Required; choice fields only) An array of options that shall be presented to the user. Each element of the array shall take one of two forms: A text string representing one of the available options A two-element array consisting of a text string representing one of the available options and a default appearance string for constructing the item's appearance dynamically at viewing time (see 12.7.3.3, 'Variable Text'). |
| A | dictionary | (Optional) An action that shall be performed when this field's widget annotation is activated (see 12.6, 'Actions'). |
| AA | dictionary | (Optional) An additional-actions dictionary defining the field's behaviour in response to various trigger events (see 12.6.3, 'Trigger Events'). |
| RV | text string or text stream | (Optional; PDF 1.5) A rich text string, as described in 12.7.3.4, 'Rich Text Strings.' |
In an FDF field dictionary representing a button field, the optional IF entry holds an icon fit dictionary (PDF 1.3) specifying how to display the button's icon within the annotation rectangle of its widget annotation. Table 247 shows the contents of this type of dictionary.
Table 247 - Entries in an icon fit dictionary
| Key | Type | Value |
|---|---|---|
| SW | name | (Optional) The circumstances under which the icon shall be scaled inside the annotation rectangle: A Always scale. B Scale only when the icon is bigger than the annotation rectangle. S Scale only when the icon is smaller than the annotation rectangle. N Never scale. Default value: A. |
| S | name | (Optional) The type of scaling that shall be used: A Anamorphic scaling : Scale the icon to fill the annotation rectangle exactly, without regard to its original aspect ratio (ratio of width to height). P Proportional scaling : Scale the icon to fit the width or height of the annotation rectangle while maintaining the icon's original aspect ratio. If the required horizontal and vertical scaling factors are different, use the smaller of the two, centering the icon within the annotation rectangle in the other dimension. Default value: P. |
| A | array | (Optional) An array of two numbers that shall be between 0.0 and 1.0 indicating the fraction of leftover space to allocate at the left and bottom of the icon. A value of [0.0 0.0] shall position the icon at the bottom-left corner of the annotation rectangle. A value of [0.5 0.5] shall center it within the rectangle. This entry shall be used only if the icon is scaled proportionally. Default value: [0.5 0.5]. |
| FB | boolean | (Optional; PDF 1.5) If true , indicates that the button appearance shall be scaled to fit fully within the bounds of the annotation without taking into consideration the line width of the border. Default value: false . |
The optional Pages field in an FDF dictionary (see Table 243) shall contain an array of FDF page dictionaries (PDF 1.3) describing new pages that shall be added to the target document. Table 248 shows the contents of this type of dictionary.
Table 248 - Entries in an FDF page dictionary
| Key | Type | Value |
|---|---|---|
| Templates | array | (Required) An array of FDF template dictionaries (see Table 249) that shall describe the named pages that serve as templates on the page. |
| Info | dictionary | (Optional) An FDF page information dictionary that shall contain additional information about the page. |
An FDF template dictionary shall contain information describing a named page that serves as a template. Table 249 shows the contents of this type of dictionary.
Table 249 - Entries in an FDF template dictionary
| Key | Type | Value |
|---|---|---|
| TRef | dictionary | (Required) A named page reference dictionary (see Table 250) that shall specify the location of the template. |
| Fields | array | (Optional) An array of references to FDF field dictionaries (see Table 246) describing the root fields that shall be imported (those with no ancestors in the field hierarchy). |
| Rename | boolean | (Optional) A flag that shall specify whether fields imported from the template shall be renamed in the event of name conflicts with existing fields; see the Note in this sub-clause for further discussion. Default value: true . |
NOTE The names of fields imported from a template can sometimes conflict with those of existing fields in the target document. This can occur, for example, if the same template page is imported more than once or if two different templates have fields with the same names.
The Rename flag does not define a renaming algorithm (see Annex J).
The TRef entry in an FDF template dictionary shall hold a named page reference dictionary that shall describe the location of external templates or page elements. Table 250 shows the contents of this type of dictionary.
Table 250 - Entries in an FDF named page reference dictionary
| Key | Type | Value |
|---|---|---|
| Name | string | (Required) The name of the referenced page. |
| F | file specification | (Optional) The file containing the named page. If this entry is absent, it shall be assumed that the page resides in the associated PDF file. |
Each annotation dictionary in an FDF file shall have a Page entry (see Table 251) that shall indicate the page of the source document to which the annotation is attached.
Table 251 - Additional entry for annotation dictionaries in an FDF file
| Key | Type | Value |
|---|---|---|
| Page | integer | (Required for annotations in FDF files) The ordinal page number on which this annotation shall appear, where page 0 is the first page. |
PDF 1.5 introduces support for interactive forms based on the Adobe XML Forms Architecture (XFA). The XFA entry in the interactive forms dictionary (see Table 218) specifies an XFA resource , which shall be an XML stream that contains the form information. The format of an XFA resource is described in the XML Data Package (XDP) Specification (see the Bibliography).
The XFA entry shall be either a stream containing the entire XFA resource or an array specifying individual packets that together make up the XFA resource. The resource includes but is not limited to the following information:
-
The form template (specified in the template packet), which describes the characteristics of the form, including its fields, calculations, validations, and formatting. The XML Template Specification describes the architecture of a form template (see Bibliography).
-
The data (specified in the datasets packet), which represents the state of the form
-
The configuration information (specified in the config packet), which shall be used to properly process the form template and associated data. Configuration information shall be formatted as described in the XML Configuration Specification (see Bibliography).
A packet is a pair of a string and stream. The string contains the name of the XML element and the stream contains the complete text of this XML element. Each packet represents a complete XML element, with the exception of the first and last packet, which specify begin and end tags for the xdp:xdp element (see EXAMPLE 1 in this sub-clause).
EXAMPLE 1 This example shows the XFA entry consisting of an array of packets. 1 0 obj XFA entry in interactive form dictionary << /XFA [(xdp:xdp) 10 0 R XFA resource specified as individual packets (template) 11 0 R (datasets) 12 0 R (config) 13 0 R (/xdp:xdp) 14 0 R ] >> endobj 10 0 obj stream <xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/"> endstream 11 0 obj stream <template xmlns="http://www.xfa.org/schema/xfa-template/2.4/"> ...remaining contents of template packet... </template> endstream 12 0 obj stream <xfa:datasets xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/"> ...contents of datasets packet... </xfa:datasets> endstream 13 0 obj stream <config xmlns="http://www.xfa.org/schema/xci/1.0/"> ...contents of config node of XFA Data Package... <config> endstream 14 0 obj stream </xdp:xdp> endstream EXAMPLE 2 The following example shows the same entry specified as a stream. 1 0 obj XFA entry in interactive form dictionary << /XFA 10 0 R >> endobj 10 0 obj stream <xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/"> <template xmlns="http://www.xfa.org/schema/xfa-template/2.4/"> ...remaining contents of template packet...
</template>
<xfa:datasets xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/"> ...contents of datasets packet... </xfa:datasets> <config xmlns="http://www.xfa.org/schema/xci/1.0/"> ...contents of config node of XFA Data Package... <config> </xdp:xdp> endstream endobj
When an XFA entry is present in an interactive form dictionary, the XFA resource provides information about the form; in particular, all form-related events such as calculations and validations. The other entries in the interactive form dictionary shall be consistent with the information in the XFA resource. When creating or modifying a PDF file with an XFA resource, a conforming writer shall follow these rules:
- PDF interactive form field objects shall be present for each field specified in the XFA resource. The XFA field values shall be consistent with the corresponding V entries of the PDF field objects.
- The XFA Scripting Object Model (SOM) specifies a naming convention that shall be used to connect interactive form field names with field names in the XFA resource. Information about this model is available in the XFA Specification, version 2.5 (see the Bibliography).
- No A or AA entries (see Table 164) shall be present in the annotation dictionaries of fields that also have actions specified by the XFA resource.
A digital signature (PDF 1.3) may be used to authenticate the identity of a user and the document's contents. It stores information about the signer and the state of the document when it was signed. The signature may be purely mathematical, such as a public/private-key encrypted document digest, or it may be a biometric form of identification, such as a handwritten signature, fingerprint, or retinal scan. The specific form of authentication used shall be implemented by a special software module called a signature handler . Signature handlers shall be identified in accordance with the rules defined in Annex E.
Digital signatures in ISO 32000 currently support two activities: adding a digital signature to a document and later checking that signature for validity. Revocation information is a signed attribute, which means that the signing software must capture the revocation information before signing. A similar requirement applies to the chain of certificates. The signing software must capture and validate the certificate's chain before signing.
Signature information shall be contained in a signature dictionary , whose entries are listed in Table 252. Signature handlers may use or omit those entries that are marked optional in the table but should use them in a standard way if they are used at all. In addition, signature handlers may add private entries of their own. To avoid name duplication, the keys for all such private entries shall be prefixed with the registered handler name followed by a PERIOD (2Eh).
Signatures shall be created by computing a digest of the data (or part of the data) in a document, and storing the digest in the document. To verify the signature, the digest shall be re-computed and compared with the one stored in the document. Differences in the digest values indicate that modifications have been made since the document was signed.
There are two defined techniques for computing a digital signature of the contents of all or part of a PDF file:
-
A byte range digest shall be computed over a range of bytes in the file, that shall be indicated by the ByteRange entry in the signature dictionary. This range should be the entire file, including the signature dictionary but excluding the signature value itself (the Contents entry). Other ranges may be used but since they do not check for all changes to the document, their use is not recommended. When a byte range digest is present, all values in the signature dictionary shall be direct objects.
-
Additionally, modification detection may be specified by a signature reference dictionary . The TransformMethod entry shall specify the general method for modification detection, and the TransformParams entry shall specify the variable portions of the method.
A PDF document may contain the following standard types of signatures:
- One or more approval signatures. These signatures appear in signature form fields (see 12.7.4.5, 'Signature Fields'). The signature dictionary corresponding to each signature shall be the value of the form field (as specified by its V entry). The signature dictionary shall contain a ByteRange entry representing a byte range digest, as described previously. A signature shall be validated by recomputing the digest and comparing it with the one stored in the signature.
- NOTE 1 If a signed document is modified and saved by incremental update (see 7.5.6, 'Incremental Updates'), the data corresponding to the byte range of the original signature is preserved. Therefore, if the signature is valid, it is possible to recreate the state of the document as it existed at the time of signing.
- At most one certification signature ( PDF 1.5 ). The signature dictionary of a certification signature shall be the value of a signature field and shall contain a ByteRange entry. It may also be referenced from the DocMDP entry in the permissions dictionary (see 12.8.4, 'Permissions'). The signature dictionary shall contain a signature reference dictionary (see Table 253) that has a DocMDP transform method. See 12.8.2.2, 'DocMDP' for information on how these signatures shall be created and validated.
A signature dictionary for a certification or approval signature may also have a signature reference dictionary with a FieldMDP transform method; see 12.8.2.4, 'FieldMDP.'
- At most two usage rights signatures ( PDF 1.5 ). Its signature dictionary shall be referenced from the UR3 ( PDF 1.6 ) entry in the permissions dictionary, whose entries are listed in Table 258, (not from a signature field). The signature dictionary shall contain a Reference entry whose value is a signature reference dictionary that has a UR transform method. See 12.8.2.3, 'UR' for information on how these signatures shall be created and validated.
Table 252 - Entries in a signature dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Optional) The type of PDF object that this dictionary describes; if present, shall be Sig for a signature dictionary. |
| Filter | name | (Required; inheritable) The name of the preferred signature handler to use when validating this signature. If the Prop_Build entry is not present, it shall be also the name of the signature handler that was used to create the signature. If Prop_Build is present, it may be used to determine the name of the handler that created the signature (which is typically the same as Filter but is not needed to be). A conforming reader may substitute a different handler when verifying the signature, as long as it supports the specified SubFilter format. Example signature handlers are Adobe.PPKLite , Entrust.PPKEF , CICI.SignIt , and VeriSign.PPKVS . The name of the filter (i.e. signature handler) shall be identified in accordance with the rules defined in Annex E. |
| SubFilter | name | (Optional) A name that describes the encoding of the signature value and key information in the signature dictionary. A conforming reader may use any handler that supports this format to validate the signature. (PDF 1.6) The following values for public-key cryptographic signatures shall be used: adbe.x509.rsa_sha1 , adbe.pkcs7.detached , and adbe.pkcs7.sha1 (see 12.8.3, 'Signature Interoperability'). Other values may be defined by developers, and when used, shall be prefixed with the registered developer identification. All prefix names shall be registered (see Annex E). The prefix 'adbe' has been registered by Adobe Systems and the three subfilter names listed above and defined in 12.8.3, 'Signature Interoperability' may be used by any developer. |
Table 252 - Entries in a signature dictionary (continued)
| Key | Type | Value |
|---|---|---|
| Contents | byte string | (Required) The signature value. When ByteRange is present, the value shall be a hexadecimal string (see 7.3.4.3, 'Hexadecimal Strings') representing the value of the byte range digest. For public-key signatures, Contents should be either a DER-encoded PKCS#1 binary data object or a DER-encoded PKCS#7 binary data object. Space for the Contents value must be allocated before the message digest is computed. (See 7.3.4, 'String Objects') |
| Cert | array or byte string | (Required when SubFilter is adbe.x509.rsa_sha1 ) An array of byte strings that shall represent the X.509 certificate chain used when signing and verifying signatures that use public-key cryptography, or a byte string if the chain has only one entry. The signing certificate shall appear first in the array; it shall be used to verify the signature value in Contents , and the other certificates shall be used to verify the authenticity of the signing certificate. If SubFilter is adbe.pkcs7.detached or adbe.pkcs7.sha1 , this entry shall not be used, and the certificate chain shall be put in the PKCS#7 envelope in Contents . |
| ByteRange | array | (Required for all signatures that are part of a signature field and usage rights signatures referenced from the UR3 entry in the permissions dictionary) An array of pairs of integers (starting byte offset, length in bytes) that shall describe the exact byte range for the digest calculation. Multiple discontiguous byte ranges shall be used to describe a digest that does not include the signature value (the Contents entry) itself. |
| Reference | array | (Optional; PDF 1.5) An array of signature reference dictionaries (see Table 253). |
| Changes | array | (Optional) An array of three integers that shall specify changes to the document that have been made between the previous signature and this signature: in this order, the number of pages altered, the number of fields altered, and the number of fields filled in. The ordering of signatures shall be determined by the value of ByteRange . Since each signature results in an incremental save, later signatures have a greater length value. |
| Name | text string | (Optional) The name of the person or authority signing the document. This value should be used only when it is not possible to extract the name from the signature. EXAMPLE 1 From the certificate of the signer. |
| M | date | (Optional) The time of signing. Depending on the signature handler, this may be a normal unverified computer time or a time generated in a verifiable way from a secure time server. This value should be used only when the time of signing is not available in the signature. EXAMPLE 2 A time stamp can be embedded in a PKCS#7 binary data object (see 12.8.3.3, 'PKCS#7 Signatures as used in ISO 32000'). |
| Location | text string | (Optional) The CPU host name or physical location of the signing. |
| Reason | text string | (Optional) The reason for the signing, such as (I agree…). |
| ContactInfo | text string | (Optional) Information provided by the signer to enable a recipient to contact the signer to verify the signature. EXAMPLE 3 A phone number. |
Table 252 - Entries in a signature dictionary (continued)
| Key | Type | Value |
|---|---|---|
| R | integer | (Optional) The version of the signature handler that was used to create the signature. (PDF 1.5) This entry shall not be used, and the information shall be stored in the Prop_Build dictionary. |
| V | integer | (Optional; PDF 1.5) The version of the signature dictionary format. It corresponds to the usage of the signature dictionary in the context of the value of SubFilter . The value is 1 if the Reference dictionary shall be considered critical to the validation of the signature. Default value: 0. |
| Prop_Build | dictionary | (Optional; PDF 1.5) A dictionary that may be used by a signature handler to record information that captures the state of the computer environment used for signing, such as the name of the handler used to create the signature, software build date, version, and operating system. he PDF Signature Build Dictionary Specification, provides implementation guidelines for the use of this dictionary. |
| Prop_AuthTime | integer | (Optional; PDF 1.5) The number of seconds since the signer was last authenticated, used in claims of signature repudiation. It should be omitted if the value is unknown. |
| Prop_AuthType | name | (Optional; PDF 1.5) The method that shall be used to authenticate the signer, used in claims of signature repudiation. Valid values shall be PIN, Password, and Fingerprint. |
NOTE 2 The entries in the signature dictionary can be conceptualized as being in different dictionaries; they are in one dictionary for historical and cryptographic reasons. The categories are signature properties ( R , M , Name , Reason , Location , Prop_Build , Prop_AuthTime , and Prop_AuthType ); key information ( Cert and portions of Contents when the signature value is a PKCS#7 object); reference (Reference and ByteRange ); and signature value ( Contents when the signature value is a PKCS#1 object).
Table 253 - Entries in a signature reference dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Optional) The type of PDF object that this dictionary describes; if present, shall be SigRef for a signature reference dictionary. |
| TransformMethod | name | (Required) The name of the transform method (see Section 12.8.2, 'Transform Methods') that shall guide the modification analysis that takes place when the signature is validated. Valid values shall be: DocMDP Used to detect modifications to a document relative to a signature field that is signed by the originator of a document; see 12.8.2.2, 'DocMDP.' UR Used to detect modifications to a document that would invalidate a signature in a rights- enabled document; see 12.8.2.3, 'UR.' FieldMDP Used to detect modifications to a list of form fields specified in TransformParams ; see |
| TransformParams | dictionary | (Optional) A dictionary specifying transform parameters (variable data) for the transform method specified by TransformMethod . Each method takes its own set of parameters. See each of the sub-clauses specified previously for details on the individual transform parameter dictionaries |
Table 253 - Entries in a signature reference dictionary (continued)
| Key | Type | Value |
|---|---|---|
| Data | (various) | (Required when TransformMethod is FieldMDP ) An indirect reference to the object in the document upon which the object modification analysis should be performed. For transform methods other than FieldMDP , this object is implicitly defined. |
| DigestMethod | name | (Optional; PDF 1.5 required) A name identifying the algorithm that shall be used when computing the digest. Valid values are MD5 and SHA1 . Default value: MD5 . For security reasons, MD5 should not be used. It is mentioned for backwards compatibility, since it remains the default value. |
Transform methods, along with transform parameters, shall determine which objects are included and excluded in revision comparison. The following sub-clauses discuss the types of transform methods, their transform parameters, and when they shall be used.
The DocMDP transform method shall be used to detect modifications relative to a signature field that is signed by the author of a document (the person applying the first signature). A document can contain only one signature field that contains a DocMDP transform method; it shall be the first signed field in the document. It enables the author to specify what changes shall be permitted to be made the document and what changes invalidate the author's signature.
NOTE
As discussed earlier, 'MDP' stands for modification detection and prevention . Certification signatures that use the DocMDP transform method enable detection of disallowed changes specified by the author. In addition, disallowed changes can also be prevented when the signature dictionary is referred to by the DocMDP entry in the permissions dictionary (see 12.8.4, 'Permissions').
A certification signature should have a legal attestation dictionary (see 12.8.5, 'Legal Content Attestations') that specifies all content that might result in unexpected rendering of the document contents, along with the author's attestation to such content. This dictionary may be used to establish an author's intent if the integrity of the document is questioned.
The P entry in the DocMDP transform parameters dictionary (see Table 254) shall indicate the author's specification of which changes to the document will invalidate the signature. (These changes to the document shall also be prevented if the signature dictionary is referred from the DocMDP entry in the permissions dictionary.) A value of 1 for P indicates that the document shall be final; that is, any changes shall invalidate the signature. The values 2 and 3 shall permit modifications that are appropriate for form field or comment workflows.
To validate a signature that uses the DocMDP transform method, a conforming reader first shall verify the byte range digest. Next, it shall verify that any modifications that have been made to the document are permitted by the transform parameters.
Once the byte range digest is validated, the portion of the document specified by the ByteRange entry in the signature dictionary (see Table 252) is known to correspond to the state of the document at the time of signing.
Therefore, conforming readers may compare the signed and current versions of the document to see whether there have been modifications to any objects that are not permitted by the transform parameters.
Table 254 - Entries in the DocMDP transform parameters dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Optional) The type of PDF object that this dictionary describes; if present, shall be TransformParams for a transform parameters dictionary. |
| P | number | (Optional) The access permissions granted for this document. Valid values shall be: 1 No changes to the document shall be permitted; any change to the document shall invalidate the signature. 2 Permitted changes shall be filling in forms, instantiating page templates, and signing; other changes shall invalidate the signature. 3 Permitted changes shall be the same as for 2, as well as annotation creation, deletion, and modification; other changes shall invalidate the signature. Default value: 2. |
| V | name | (Optional) The DocMDP transform parameters dictionary version. The only valid value shall be 1.2 . NOTE this value is a name object, not a number. Default value: 1.2 . |
The UR transform method shall be used to detect changes to a document that shall invalidate a usage rights signature, which is referred to from the UR3 entry in the permissions dictionary (see 12.8.4, 'Permissions'). Usage rights signatures shall be used to enable additional interactive features that may not available by default in a conforming reader. The signature shall be used to validate that the permissions have been granted by a bonafide granting authority. The transform parameters dictionary (see Table 255) specifies the additional rights that shall be enabled if the signature is valid. If the signature is invalid because the document has been modified in a way that is not permitted or the identity of the signer is not granted the extended permissions, additional rights shall not be granted.
- EXAMPLE Adobe Systems grants permissions to enable additional features in Adobe Reader, using public-key cryptography. It uses certificate authorities to issue public key certificates to document creators with which it has entered into a business relationship. Adobe Reader verifies that the rights-enabling signature uses a certificate from an Adobe-authorized certificate authority. Other conforming readers are free to use this same mechanism for their own purposes.
UR3 ( PDF 1.6 ): The ByteRange entry in the signature dictionary (see Table 252) shall be present. First, a conforming reader shall verify the byte range digest to determine whether the portion of the document specified by ByteRange corresponds to the state of the document at the time of signing. Next, a conforming reader shall examine the current version of the document to see whether there have been modifications to any objects that are not permitted by the transform parameters.
Table 255 - Entries in the UR transform parameters dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Optional) The type of PDF object that this dictionary describes; if present, shall be TransformParams for a transform parameters dictionary. |
| Document | array | (Optional) An array of names specifying additional document-wide usage rights for the document. The only defined value shall be FullSave, which permits a user to save the document along with modified form and/or annotation data. (PDF 1.5) Any usage right that permits the document to be modified implicitly shall enable the FullSave right. If the PDF document contains a UR3 dictionary, only rights specified by the Annots entry that permit the document to be modified shall implicitly enable the FullSave right. For all other rights, FullSave shall be explicitly enabled in order to save the document. (Signature rights shall permit saving as part of the signing process but not otherwise). If the P entry in the UR transform parameters dictionary is true (PDF 1.6) and greater conforming readers shall permit only those rights that are enabled by the entries in the dictionary. However, conforming readers shall permit saving the document as long as any rights that permit modifying the document are enabled. |
| Msg | text string | (Optional) A text string that may be used to specify any arbitrary information, such as the reason for adding usage rights to the document. |
| V | name | (Optional) The UR transform parameters dictionary version. The value shall be 2.2 . If an unknown version is present, no rights shall be enabled. NOTE This value is a name object, not a number. Default value: 2.2 . |
| Annots | array | (Optional) An array of names specifying additional annotation-related usage rights for the document. Valid names (PDF 1.5) are Create, Delete, Modify, Copy, Import, and Export, which shall permit the user to perform the named operation on annotations. The following names (PDF 1.6) shall be permitted only when the signature dictionary is referenced from the UR3 entry of the permissions dictionary (see Table 258): Online Permits online commenting; that is, the ability to upload or download markup annotations from a server. SummaryView Permits a user interface to be shown that summarizes the |
Table 255 - Entries in the UR transform parameters dictionary (continued)
| Key | Type | Value |
|---|---|---|
| Form | array | (Optional) An array of names specifying additional form-field-related usage rights for the document. Valid names (PDF 1.5) are: Add Permits the user to add form fields to the document. Delete Permits the user to delete form fields to the document. FillIn Permits the user to save a document on which form fill-in has been done. Import Permits the user to import form data files in FDF, XFDF and text (CSV/TSV) formats. Export Permits the user to export form data files as FDF or XFDF. SubmitStandalone Permits the user to submit form data when the document is not open in a Web browser. SpawnTemplate Permits new pages to be instantiated from named page templates. The following names (PDF 1.6) shall be permitted only when the signature dictionary is referenced from the UR3 entry of the permissions dictionary; see Table 258: BarcodePlaintext Permits (PDF 1.6) text form field data to be encoded as a plaintext two-dimensional barcode. Online Permits (PDF 1.6) the use of forms-specific online |
| Signature | array | (Optional) An array of names specifying additional signature-related usage rights for the document. The only defined value shall be Modify, which permits a user to apply a digital signature to an existing signature form field or clear a signed signature form field. |
| EF | array | (Optional; PDF 1.6) An array of names specifying additional usage rights for named embedded files in the document. Valid names shall be Create, Delete, Modify, and Import, which shall permit the user to perform the named operation on named embedded files. |
| P | boolean | (Optional; PDF 1.6) If true , permissions for the document shall be restricted in all consumer applications to those permissions granted by a conforming reader, while allowing permissions for rights enabled by other entries in this dictionary. Default value: false . |
The FieldMDP transform method shall be used to detect changes to the values of a list of form fields. The entries in its transform parameters dictionary are listed in Table 256.
Table 256 - Entries in the FieldMDP transform parameters dictionary
| Key | Type | Value |
|---|---|---|
| Type | name | (Optional) The type of PDF object that this dictionary describes; if present, shall be TransformParams for a transform parameters dictionary. |
| Action | name | (Required) A name that, along with the Fields array, describes which form fields do not permit changes after the signature is applied. Valid values shall be: All All form fields. Include Only those form fields that specified in Fields . Exclude Only those form fields not specified in Fields . |
| Fields | array | (Required if Action is Include or Exclude) An array of text strings containing field names. |
Table 256 - Entries in the FieldMDP transform parameters dictionary (continued)
| Key | Type | Value |
|---|---|---|
| V | name | (Optional : PDF 1.5 required) The transform parameters dictionary version. The value for PDF 1.5 and later shall be 1.2 . NOTE This value is a name object, not a number. Default value: 1.2 . |
On behalf of a document author creating a document containing both form fields and signatures the following shall be supported by conforming writers:
- The author specifies that form fields shall be filled in without invalidating the approval or certification signature. The P entry of the DocMDP transform parameters dictionary shall be set to either 2 or 3 (see Table 254).
- The author can also specify that after a specific recipient has signed the document, any modifications to specific form fields shall invalidate that recipient's signature. There shall be a separate signature field for each designated recipient, each having an associated signature field lock dictionary (see Table 233) specifying the form fields that shall be locked for that user.
- When the recipient signs the field, the signature, signature reference, and transform parameters dictionaries shall be created. The Action and Fields entries in the transform parameters dictionary shall be copied from the corresponding fields in the signature field lock dictionary.
- NOTE This copying is done because all objects in a signature dictionary must be direct objects if the dictionary contains a byte range signature. Therefore, the transform parameters dictionary cannot reference the signature field lock dictionary indirectly.
FieldMDP signatures shall be validated in a similar manner to DocMDP signatures. See Validating Signatures That Use the DocMDP Transform Method in 12.8.2.2, 'DocMDP' for details.
It is intended that conforming readers allow interoperability between signature handlers; that is, a PDF file signed with a handler from one vendor shall be able to be validated with a handler from a different vendor.
If present, the SubFilter entry in the signature dictionary shall specify the encoding of the signature value and key information, while the Filter entry shall specify the preferred handler that should be used to validate the signature. When handlers are being registered according to Annex E they shall specify the SubFilter encodings they support enabling handlers other than the preferred handler to validate the signatures that the preferred handler creates.
There are several defined values for the SubFilter entry, all based on public-key cryptographic standards published by RSA Security and also as part of the standards issued by the Internet Engineering Task Force (IETF) Public Key Infrastructure (PKIX) working group; see the Bibliography for references.
The PKCS#1 standard supports several public-key cryptographic algorithms and digest methods, including RSA encryption, DSA signatures, and SHA-1 and MD5 digests (see the Bibliography for references). For signing PDF files using PKCS#1, the only value of SubFilter that should be used is adbe.x509.rsa_sha1, which uses the RSA encryption algorithm and SHA-1 digest method. The certificate chain of the signer shall be stored in the Cert entry.
When PKCS#7 signatures are used, the value of Contents shall be a DER-encoded PKCS#7 binary data object containing the signature. The PKCS#7 object shall conform to RFC3852 Cryptographic Message Syntax. Different subfilters may be used and shall be registered in accordance with Annex E. SubFilter shall take one of the following values:
- adbe.pkcs7.detached : The original signed message digest over the document's byte range shall be incorporated as the normal PKCS#7 SignedData field. No data shall be encapsulated in the PKCS#7 SignedData field.
- adbe.pkcs7.sha1 : The SHA1 digest of the document's byte range shall be encapsulated in the PKCS#7 SignedData field with ContentInfo of type Data. The digest of that SignedData shall be incorporated as the normal PKCS#7 digest.
The PKCS#7 object shall conform to the PKCS#7 specification in Internet RFC 2315, PKCS #7: Cryptographic Message Syntax, Version 1.5 (see the Bibliography). At minimum, it shall include the signer's X.509 signing certificate. This certificate shall be used to verify the signature value in Contents .
The PKCS#7 object should contain the following:
- Time stamp information as an unsigned attribute (PDF 1.6) : The timestamp token shall conform to RFC 3161 and shall be computed and embedded into the PKCS#7 object as described in Appendix A of RFC 3161. The specific treatment of timestamps and their processing is left to the particular signature handlers to define.
- Revocation information as an signed attribute (PDF 1.6) : This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature. This means that the software used by the signer must be able to construct the certification path and the associated revocation information. If one of the elements cannot be obtained (e.g. no connection is possible), a signature with this attribute will not be possible.
- (PDF 1.6) . This differs from the treatment when using adbe.x509.rsa_sha1 when the certificates shall be placed in the Cert key of the signature dictionary as defined in Table 252.
- One or more RFC 3281 attribute certificates associated with the signer certificate (PDF 1.7) . The specific treatment of attribute certificates and their processing is left to the particular signature handlers to define.
NOTE For maximum compatibility with earlier versions, conforming writers should follow this practice.
The policy of how to establish trusted identity lists to validate embedded certificates is up to the validation signature handler.
The adbe Revocation Information attribute:
adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
{ adbe(1.2.840.113583) acrobat(1) security(1) 8 }
The value of the revocation information attribute can include any of the following data types:
-
Certificate Revocation Lists (CRLs), described in RFC 3280 (see the Bibliography): CRLs are generally large and therefore should not be embedded in the PKCS#7 object.
-
Online Certificate Status Protocol (OCSP) Responses, described in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP (see the Bibliography): These are generally small and constant in size and should be the data type included in the PKCS#7 object.
-
Custom revocation information: The format is not prescribed by this specification, other than that it be encoded as an OCTET STRING. The application should be able to determine the type of data contained within the OCTET STRING by looking at the associated OBJECT IDENTIFIER.
adbe's Revocation Information attribute value has ASN.1 type RevocationInfoArchival:
---
> **Navigation**: [[PDF-Spec-12-Forms|← Previous]] | [[PDF-Spec-Index|Index]] | [[PDF-Spec-12-Security|Next →]]