Xojo Conferences

DynaPDF Manual - Page 190

Previous Page 189   Index   Next Page 191

Function Reference
Page 190 of 770
The member HashType specifies whether the function should return the SHA1 hash or the byte
ranges of the PDF file. In the latter case the signature handler must create a detached signature.
However, when using programming languages like Visual Basic, VB. Net, or C# it is recommended
to sign a SHA1 hash because it is not required to copy the PDF buffer in this case.
The hash algorithm that is used to sign the hash or byte ranges can be MD2, MD5, SHA1, SHA256,
SHA384, SHA512, or RIPEMD160. MD2 and MD5 are not documented in the PDF Reference but
work very well too.
Detached signatures require no data to be encapsulated in the PKCS#7 SignedData field. When
signing a SHA1 hash the signature handler must store the hash in the SignedData field of the
PKCS#7 object.
Supported PKCS#7 Format
PKCS #7 objects are ASN1 encoded binary objects. The ASN1 standard defines a set of Basic
Encoding Rules (BER) which describe how ASN1 objects must be encoded. This Standard defines
also a set of Distinguished Encoding Rules (DER) and a set of Canonical Encoding Rules (CER) both
of which provide constraints on the Basic Encoding Rules (BER). The key difference between them is
that DER uses the definite length form of encoding while CER uses the indefinite length form.
PDF compatible PKCS#7 objects must be DER encoded because Adobe's Acrobat or Reader does not
support indefinite length encoding. However, not all cryptographic providers support definite
length encoding. Whether this is the case or not is also often not documented.
The Windows CryptAPI creates DER encoded PKCS#7 objects which are fully PDF compatible.
However, when using another cryptographic library and if Adobe's Acrobat or Reader reports an
error like "Error reading BER encoded object" when trying to validate the signature, the library does
probably not create definite length encoded PKCS#7 objects.
Hardware Certificates
Signing a PDF file with a hardware certificate works exactly in the same way as with a software
certificate as long as the certificate was installed in the certificate store of the operating system.
Hardware certificates like smart cards, USB sticks, or something similar are normally delivered with
software that is able to install the certificate on the operating system. Once a certificate was installed
in the certificate store it can be used like any other certificate.
The Windows CryptAPI for example, hides the certificate type fully for the developer. Whether the
user selects a software or hardware certificate is simply not of interest because nothing special must
be done in either case. You still call CryptSignMessage(), that's all. If a password is required the
CryptAPI displays automatically a dialog to enter the password. The communication with the
hardware is done in background.

Previous topic: Possible function errors, CloseAndSignFileExt

Next topic: CloseFile, CloseFileEx