Professional Documents
Culture Documents
Acrobat DigitalSignatures in PDF
Acrobat DigitalSignatures in PDF
Acrobat DigitalSignatures in PDF
This document describes how digital signatures are represented in a PDF document and what
signature-related features the PDF language supports. Adobe Reader and Acrobat have
implemented all of PDFs features and therefore provide comprehensive support for the authentication
of digital data based on public key infrastructure (PKI) technologies. Third-party developers can define
their own mechanisms in the form of an Acrobat plug-in signature handler.
Digital signatures can be used for many types of documents where traditional pen-and-ink signatures
were used in the past. However, the mere existence of a digital signature is not adequate assurance that
a document is what it appears to be. Moreover, government and enterprise settings often need to
impose additional constraints on their signature workflows, such as restricting user choices and
document behavior during and after signing.
For these reasons, the PDF language provides mechanisms for two broad categories of tasks:
Fully trusting an electronic document by enabling verification that the signed document has not
been altered and that it was signed by someone the recipient trusts.
Irrespective of the PDF viewing application, the PDF language supports the following:
Standards support
Signature interoperability
Multiple signatures
Incremental updates
Naturally, PDF includes features which are related to these activities but are not essential to them. For
example, support for adding signing reasons is tangential to signing, but valuable for many workflows.
Tip:
For complete PDF language details, refer to the PDF Reference at http://www.adobe.
com/devnet/pdf/pdf_reference.html.
REM)LHOGGLFWLRQDU\
REM)LHOGORFNGLFWLRQDU\
3HUPV'RF0'3REM,'!
)7ILHOGW\SHHJ6LJ
7\SH6LJ)LHOG/RFN
3HUPV85!
/RFN
$FWLRQ$OO
69RSWLRQDOVHHGYDOXH
3
REM6HHGYDOXHGLFWLRQDU\
6LJ)ODJVRSWLRQDORU
7\SH69
9LIVLJQHGDVLJGLFWREM,'
'RFORFNHGRQDSSURYDOVLJ
)LHOG0'37UDQVIRUP3DUDPV
)I6SHFLI\UHTXLUHGHQWULHV
6XE)LOWHU6LJQDWXUHHQFRGLQJ
$FWLRQV$OO_,QF_([F
REM6LJQDWXUHGLFWLRQDU\
)LOWHUVLJQDWXUHKDQGOHU
'LJHVW0HWKRG$OJRULWKP
6XE)LOWHUVLJQDWXUHIRUPDW
969SDUVHUFDSDELOLW\
%\WH5DQJHGRFXPHQWUDQJH
5HDVRQV6LJQLQJUHDVRQVOLVW
&RQWHQWV3.&6VLJYDOXH
0'3)RUFHFHUWLILFDWLRQVLJ
7\SH6LJ
7LPH6WDPS76GLFWLRQDU\
2WKHUVWXII
/HJDO$WWHVWDWLRQ$WWHVWDWLRQV
5HIHUHQFHQVLJUHIGLFWV
$GG5HY,QIR(PEHGUHYVWDWXV
&HUW&HUWLILFDWH69GLFWLRQDU\
REM6LJQDWXUHUHIHUHQFHGLFW
7\SH6LJ5HI
REM&HUWLILFDWH69GLFWLRQDU\
7\SH69&HUW
)I6SHFLI\UHTXLUHGHQWULHV
6XEMHFW,GHQWLI\FHUWLILFDWHV
2WKHUVWXII
7UDQVIRUP0HWKRG
)LHOG0'3
'RF0'3
85
7UDQVIRUP3DUDPV
7UDQVIRUP0HWKRGVHWVZKDW7UDQVIRUP3DUDPVDUHXVHG
)LOWHU6LJQDWXUHKDQGOHU
)LHOGV)LHOGQDPHV
3
)LHOGOHYHOSHUPLVVLRQV
'RF0'37UDQVIRUP3DUDPV
$OORZVLJQDQQRWVHWF
3__
&HUWLILFDWLRQVLJQDWXUH
857UDQVIRUP3DUDPV
9
'RFXPHQW>)XOO6DYH@
)RUP>IRUPILHOGULJKWV@
6LJQDWXUH>0RGLI\@
$QQRWV>DQQRWULJKWV@
()>HPEHGGHGILOHULJKWV@
)RUP(;>IRUPILHOGULJKWV@
GHILQHXVDJHULJKWV
$GPLQ
(QWHUSULVHRZQHG3.,HOHPHQWV
3ULYDWHNH\
EDFNXSVWRUH
'LJLWDO,'
FUHDWLRQWRRO
5HYRFDWLRQGDWDVWRUH
/RFDOFHUWLILFDWHUHYRFDWLRQ
OLVWV&5//'$3&5/
RQOLQHVWDWXVFKHFNHWF
3XEOLFNH\FHUWLILFDWHVWRUH
$FUREDWVWRUH:LQGRZVFHUW
VWRUH/'$3VWRUHHWF
,QWHUPHGLDWH
FHUWLILFDWHV
&RPSDQ\RUUGSDUW\
WLPHVWDPSVHUYHU
2IWHQWKHFRPSDQ\LVVXHV,'
WRHPSOR\HHV&DQGHILQH
SROLFLHVWUXVWDQFKRUHWF
'LJLWDO,'VWRUHGRQ
GLJLWDOLGHQG WKHVLJQHUVPDFKLQH
HQWLW\FHUW WRNHQVHUYHUHWF
6LJQHUV
When signing an important paper document, a person usually signs it in front of a notary public or other
trusted authority after providing them satisfactory evidence of their identity. Because the notary is
deemed trustworthy, you can trust the signature the notary witnesses. Using a PKI is a method of
providing a similar kind of trust.
Some common PKI components directly related to providing trust include:
Certificate authority (CA): An ultimate trust authority that sells or issues digital IDs (such as
Verisign or Geotrust). The CA signs its own certificate (self-signs) and its certificate is typically the
root certificate at the top of the certificate chain.
Intermediate certificates (ICAs): A type of CA whose certificate resides in the certificate chain
between the end entity and root certificates. The certificate is not self-signed, and the ICA often
provides services such as policies, timestamping, revocation lists, etc.
End entity certificate (EE): The signers certificate and the last element of a signing chain. By
definition, an end entity certificate does not contain the basic constraint value CA.
Digital ID: An electronic representation of data based on the ITU-T X.509 v3 standard, associated
with a person or entity. It is stored in a password-protected file on a computer or network, a USB
token, a smart card, etc. A digital ID contains a public key certificate, a private key, and other data.
Public key certificate: A file that contains the numeric public key portion of a public/private key
pair along with the associated extensions and attributes used to define the certificates owner,
validity period, and usage.
Private key: The secret key in a PKI system, used to validate incoming messages and sign outgoing
ones. A Private Key is always paired with its Public Key during those key generations.
While the digital ID and its issuing entities are central to any PKI, the PKI also includes many other
enterprise-owned and 3rd party items. A PKI administrator will usually manage the creation and
distribution of digital IDs, LDAP servers, timestamp servers, revocation lists, and other items. The PDF
language supports all the data needed to interface with those components.
Digital ID
. . .
%PDF
(PDF content)
Private key
signature dictionary
Certificate:
/ByteRange { . . . }
Public key
Identity info
/Contents
Certificate
(stored on computer
or security device)
Signature
value
Timestamp
%EOF
ByteRange is an array of four numbers. The first number in each pair is the offset in the file (from
the beginning, starting from 0) of the beginning of a stream of bytes to be included in the hash. The
second number is the length of that stream. The two pairs define two sequences of bytes that
define what is to be hashed. The actual signature value is stored in the /Contents key between
the end of the first sequence and the beginning of the second one. In Figure 4, the hash is
calculated for bytes 0 through 839, and 960 through 1200.
Figure 4 The ByteRange and signature value
PDF document
Example:
/ByteRange
[ 0, 840, 960, 240 ]
840 bytes
Byte
Signature
hash value
computed for
these bytes
/Contents <
840
240 bytes
signature
value
>
960
%%EOF
1200
3. Once the location of the signature value is known in terms of offsets in the file, the ByteRange
array is overwritten using the correct values. Because the byte offsets must not change, extra bytes
following the new array statement are overwritten with zeros.
4. The hash of the entire file is computed, using the bytes specified by the real ByteRange value
using a hash algorithm such as SHA-256. Acrobat always computes the hash for a document
signature over the entire PDF file, starting from byte 0 and ending with the last byte in the physical
file, but excluding the signature value bytes.
5. The hash value is encrypted with the signers private key and a hex-encoded PKCS#7 object
signature object is generated.
6. The signature object is placed in the file on disk, overwriting the placeholder /Contents value.
Any space not used for the signature object is overwritten with zeros.
7. The PDF file is re-loaded in Acrobat to ensure that the in-memory and on-disk versions are identical.
Tip:
This is a high level view. For a more detailed quick key that shows some
application-level configuration options, refer to Signature creation workflow.
Whether or not the signature is trusted or valid are separate issues. Signature trust
depends on the recipients application configuration. Signature status also depends on
a document integrity check.
Signature interoperability
Approval: There can be any number of approval signatures in a document. The field may optionally
be associated with FieldMDP permissions. See Locking form fields.
Certification: There can be only one certification signature and it must be the first one in a
document. The field is always associated with DocMDP (See Controlling post-signing changes) and
Legal content attestations. They may optionally be associated with FieldMDP permissions.
Subfilter value
Message digest
adbe.pkcs7.detached
adbe.pkcs7.sha1
adbe.x509.rsa.sha1 (a)
RIPEMD160 (PDF1.7)
RIPEMD160 (PDF1.7)
See adbe.pkcs7.
detached
See adbe.pkcs7.detached
See adbe.pkcs7.
detached
No
(a) Despite the appearance of sha1 in the name of this Subfilter value, supported encodings are not limited to the SHA1. The
PKCS#1 object has an identifier that indicates which algorithm is used.
(b) Other algorithms may be used to digest the signed data field; however, SHA1 is used to digest the signed data.
Multiple signatures
Original
version
signature 1
%%EOF
signature 1
applies to
these bytes
signature 2
applies to
these bytes
Changes for
version 2
signature 2
1
%%EOF
Changes for
version 3
signature 3
applies to
these bytes
signature 3
%%EOF
View Signed Version: Display the document as it existed at the time that the signature was applied
by right-clicking on a signature and choosing View Signed Version. It can be mimicked manually
by removing any bytes in the PDF file after the EOF corresponding to the signature.
Compare Signed Version to Current Version: Compare a documents current version with the
signed version by right-clicking on a signature and choosing Compare Signed Version to Current
Version.
Whether form fields can be filled in without invalidating the approval or certification signature.
That after a specific recipient has signed the document, any modifications to specific form fields
shall invalidate that recipients signature. In this case, a separate signature field is designated for
each recipient
The FieldMDP transform method is used detects changes to the values of a documents form fields
(Figure 1).
No changes
A document can contain only one signature field that contains a DocMDP transform method, and it
must be the first signed field in the document. That signature is called a certification signature. This
feature enables the author to specify what changes are permitted and what changes invalidate the
authors signature. However, most users will perceive the effect of DocMDP as specifying what they can
do to a document.
Acrobat Family of Products
A certification signature should have a legal attestation dictionary that specifies all content that might
result in unexpected rendering of the document contents, along with the authors attestation to such
content. This dictionary may be used to establish an authors intent if the integrity of the document is
questioned.
Acrobat allows the first signer to certify a document with a certification signature and set the
permissions and legal attestations on the fly during signing.
When a certified document is opened, the signature is validated as usual, except that the document as it
existed at the time it was certified is opened and compared to the document in memory which is
currently being viewed, including all incremental changes. A modification analysis is done and any
modifications that were prohibited by the author are reported. Permission violations result in an invalid
signature.
10
Timestamp information
REM6HHGYDOXHGLFWLRQDU\
)7ILHOGW\SHHJ6LJ
7\SH69
/RFN
)I6SHFLI\UHTXLUHGHQWULHV
69RSWLRQDOVHHGYDOXH
)LOWHU6LJQDWXUHKDQGOHU
6LJ)ODJVRSWLRQDORU
6XE)LOWHU6LJQDWXUHHQFRGLQJ
85/85/WR76VHUYHU
9LIVLJQHGDVLJGLFWREM,'
7LPH6WDPS76GLFWLRQDU\
)I6SHFLI\LIUHTXLUHG
REM7LPHVWDPSGLFWLRQDU\
969SDUVHUFDSDELOLW\
5HDVRQV6LJQLQJUHDVRQVOLVW
0'3)RUFHFHUWLILFDWLRQVLJ
'LJHVW0HWKRG$OJRULWKP
/HJDO$WWHVWDWLRQ$WWHVWDWLRQV
$GG5HY,QIR(PEHGUHYVWDWXV
&HUW&HUWLILFDWH69GLFWLRQDU\
REM&HUWLILFDWH69GLFWLRQDU\
7\SH69&HUW
)I6SHFLI\UHTXLUHGHQWULHV
6XEMHFW,GHQWLI\FHUWLILFDWHV
6XEMHFW'16SHFLI\FHUW'1V
.H\8VDJH5HTXLUHXVDJHH[W
,VVXHU6SHFLI\FHUWLVVXHU
2,'5HTXLUHSROLFLHV
85/85/
85/7\SH8VDJHRI85/
11
'RFXPHQWWRVLJQ
'HIDXOW$GREH33./LWH
5HJLVWU\NH\VD3ULY.H\
9DOXHV&XVWRPVHFXULW\KDQGOHUV
,QYRNHVLJQDWXUHKDQGOHU
*HW
DSSHDUDQFH
&UHDWHVLJQDWXUHDSSHDUDQFHVZLWK
WKH8,RUSURJUDPPDWLFDOO\&RQWHQWV
DUHGHILQHGE\WKH6LJ$3GLFWLRQDU\
LQFOXGHGLQWKHIRUPILHOG
6LJQDWXUH
DSSUHDUDQFH
'RFXPHQW
DSSHDUDQFH
'LJHVWGRFXPHQW
7KHVLJQDWXUHDSSHDUDQFHLVLQFOXGHG
LQWKHPHVVDJHGLJHVW
7KHGHIDXOWLVQRQH8VHUVFDQ
FUHDWHDSSHDUDQFHVRQWKHIO\RU
DGPLQVFDQGHSOR\DSSHDUDQFHV
ZLWKWKHDSSOLFDWLRQ
'RFXPHQWGLJHVW
*HW
VLJQDWXUH
DOJRULWKP
7KH'6$56$DOJRULWKPLVVSHFLILHG
E\WKHVLJQHUVGLJLWDO,'SULYDWHNH\
LQD33);ILOHVPDUWFDUGWRNHQ
URDPLQJ,'VHUYHU0DF.H\&KDLQ
RU:LQGRZVVWRUH
(QFU\SWGLJHVW
'LJLWDO
,'
'HIDXOW$OO
5HJLVWU\NH\VF&UHG3URYLGHU
9DOXHV)LOH&UHGHQWLDO3URYLGHU
06&UHGHQWLDO3URYLGHU
3&UHGHQWLDO3URYLGHU
,Q0HPRU\&UHGHQWLDO3URYLGHU
(QFU\SWHGGLJHVW
5HYRFDWLRQFKHFNLQJLVFRQILJXUDEOH
IRUDQ\FHUWLILFDWHLQWKHFKDLQ
LQFOXGLQJWKHVLJQHUVWKH,&$DQ\
WLPHVWDPS&$HWF
7LPHVWDPS"
,IQRWWLPHVWDPSHGRUWLPHVWDPSLQJ
IDLOVXVHWKHORFDOWLPH
<HV
'HIDXOWQRQH
1R
7LPHVWDPS 5HJLVWU\NH\VW6HUYHUW1DPHHWF
GDWD
9DOXHV6HUYHUVSHFLILF
REM
7KHVLJQDWXUHREMHFWLVEXLOWLQ
PHPRU\XQWLODOOWKHUHYRFDWLRQ
FKHFNLQJWLPHVWDPSDQGFHUWLILFDWH
GDWDLVUHWULHYHG
7KHVLJQDWXUHREMHFWLVHQFRGHG
XVLQJWKH'LVWLQJXLVKHG(QFRGLQJ
5XOHV'(57KH'(5REMHFWLVKH[
HQFRGHGDQGSDGGHGZLWK]HURVWR
PDNHWKHVLJQHGE\WHUDQJHPDWFK
WKHVL]HWKDWZDVVHWDVLGHZKHQWKH
VLJQLQJSURFHVVEHJDQ
'LFWLRQDU\FRQWHQWVDUHFXVWRPL]DEOH
WKURXJK8,DQGUHJLVWU\VHWWLQJVVXFK
DVF5HDVRQVF&RQWDFW,QIRHWF
%XLOGVLJQDWXUHREMHFW
,QVSHFLILHGIRUPDW
'HIDXOWDGEHSNFVGHWDFKHG
5HJLVWU\NH\VD6LJQ)RUPDW
9DOXHVDGEHSNFVGHWDFKHG
DGEHSNFVVKD
DGEH[UVDBVKD
3.&6RU[REMHFW
(76,&$G(6GHWDFKHG
:ULWHWKHVLJQDWXUHREMHFW
GDWDLQWRWKHGLFWLRQDU\
)LOWHU$GREH33./LWH
6XE)LOWHUDGEHSNFVGHWDFKHG
0'
1DPH56$6+$
%\WH5DQJH>@
&RQWHQWV>61,3@!
3URSB%XLOG
)LOWHU
1DPH$GREH33./LWH
6LJQDWXUHGLFWLRQDU\
5
'DWH2FW
2WKHUHQWULHV
5()(5(1&(6
3')5HIHUHQFH
'LJLWDO6LJQDWXUH%XLOG'LFWLRQDU\6SHFLILFDWLRQ
'LJLWDO6LJQDWXUHV$FUREDW
'LJLWDO6LJQDWXUH$SSHDUDQFHVLQWKH6'.
5HDVRQ0\ERVVPDGHPHVLJQ
7\SH6LJ
&RQWDFW,QIREHQ#H[DPSOHFRP
/RFDWLRQ6DQ-RVH&$
!!HQGREM
12
Supported standards
Reference
Feature
http://www.ietf.org
http://www.ietf.org
Attribute certificates.
http://www.ietf.org
http://www.ietf.org
Password security.
http://www.ietf.org
RFC 2315, PKCS #7: Cryptographic Message Syntax, Version 1.5.
http://www.ietf.org
Digital signatures.
http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf
FIPS PUB 197, Advanced Encryption Standard (AES).
Certificate security.
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
ISIS-MTT Specification v.1.1 March 2004.
Attribute certificates.
http://www.isis-mtt.org/index.php?id=460&L=1
NIST PKITS Public Key Interoperability Public Key Interoperability Test
Suite Certification Path Validation, Draft Version 0.7 June 30, 2003
OIDS. ASN.1
All.
http://www.ietf.org
RFC 2595, Using TLS with IMAP, POP3 and ACAP.
http://www.ietf.org
RFC 3778, The application/pdf Media Type. Adobe Systems Incorporated.
13
Additional resources
Digital Signatures in Acrobat: Implementation details describing how the Acrobat family of products
uses digital signature capabilities of PDF.
Digital Signatures and Rights Management in Acrobat and Adobe Reader: Configuration, usage, and
technical details of interest to administrators.
14