I'm trying to sign PDF with rsa_sha1(Adobe.PPKLite > adbe.x509.rsa_sha1), and I have two problems/questions:
- Don't know if actual PDF content specified by ByteRange should be signed, or digest value of that content?
- Is there a difference if certificate is placed before Signature field, or after?
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...
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...)
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.
PS: The specification says that the signature
This seems to allow other byte ranges than the recommended one (everything but the actual signature bytes), too. Actually, though, you'll also find
which makes the
should
in the citation before an actualshall
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.