Signing PDF with rsa_sha1

1.6k Views Asked by At

I'm trying to sign PDF with rsa_sha1(Adobe.PPKLite > adbe.x509.rsa_sha1), and I have two problems/questions:

  1. Don't know if actual PDF content specified by ByteRange should be signed, or digest value of that content?
  2. Is there a difference if certificate is placed before Signature field, or after?
1

There are 1 best solutions below

0
On

I'm trying to sign PDF with rsa_sha1(Adobe.PPKLite > adbe.x509.rsa_sha1)

Are you sure you want to use this subfilter? All further development concerning integrated PDF signatures makes use of integrated CMS containers, not the naked PKCS#1 signatures...

Don't know if actual PDF content specified by ByteRange should be signed, or digest value of that content?

In contrast to adobe.pkcs7.sha1 style signatures and just like adobe.pkcs7.detached style signatures, the whole byte range is signed in adobe.x509.rsa_sha1 style signatures, not merely a digest value of that content. In this respect adobe.x509.rsa_sha1 are preferable to adobe.pkcs7.sha1 because (despite the appearance of sha1 in the name) it does not force you to use SHA1 but you can use better digest algorithms.

(This being said, the signing process of course does include creating a digest value of the signed data, but that's a different matter altogether...)

Is there a difference if certificate is placed before Signature field, or after?

Both the certificates and the signature are elements in a PDF dictionary object, and by definition the order of elements in such a dictionary does not matter. Obviously, though, the order must remain fixed (actually not merely the order but the exact position and contents) once the signature is created.

The entries in a dictionary represent an associative table and as such shall be unordered even though an arbitrary order may be imposed upon them when written in a file. That ordering shall be ignored.

(section 7.3.7 in ISO 32000-1)

PS: The specification says that the signature

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.

(section 12.8.1 in ISO 32000-1)

This seems to allow other byte ranges than the recommended one (everything but the actual signature bytes), too. Actually, though, you'll also find

For byte range signatures, Contents shall be a hexadecimal string with “<” and “>” delimiters. It shall fit precisely in the space between the ranges specified by ByteRange.

(section 12.8.3.3.2 in ISO 32000-1)

which makes the should in the citation before an actual shall if interoperability is desired. E.g. the Adobe Reader requires this kind of range definition.

Newer standards, e.g. the ETSI PAdES technical specification documents, even more explicitly require it.