Dear list, the latest version of LMTX can digitally sign PDF documents. It requires OpenSSL installed (since it does the crypto part). I have two issues that I would like to be tested by others. A sample certificate may be found at https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/message/ECSXLVMT3TMQ... (I sent it myself). Here is a sample document (actually provided by Hans): \setupinteraction[state=start] \definefield[signature][signed] \defineoverlay[signature][my signature] \starttext \startTEXpage[offset=1ts,frame=on,framecolor=darkblue] sign: \inframed[background=signature,framecolor=darkred] {\fieldbody[signature][width=3cm,option=hidden]} \stopTEXpage \stoptext After compiling the sample, you need to run: mtxrun --script pdf --sign --certificate=c.pfx --password=ABCabc doc.pdf Password will be prompted again ("ABCabc"), since it is an encrypted certificate (also for the public part). Could anyone confirm the following issues? 1. The signature I get is wrong, unless I apply this patch (https://mailman.ntg.nl/archives/list/dev-context@ntg.nl/message/T3OCKVZWTUTI... [sent by myself to the devel list]). 2. I cannot get any signature display in Acrobat. Does any PDF viewer (I have tested this with pdfsig from poppler and MuPDF-GL) display the digital signature at all? Many thanks for your help, Pablo
Am 17.06.24 um 19:51 schrieb Pablo Rodriguez via ntg-context:
Dear list,
the latest version of LMTX can digitally sign PDF documents. It requires OpenSSL installed (since it does the crypto part).
Could anyone confirm the following issues?
1. The signature I get is wrong, unless I apply this patch (https://mailman.ntg.nl/archives/list/dev-context@ntg.nl/message/T3OCKVZWTUTI... [sent by myself to the devel list]).
Can confirm. Before patching, I checked with … – Acrobat Reader: doesn’t recognize a signature – Foxit Reader: "a signature is invalid"
2. I cannot get any signature display in Acrobat. Does any PDF viewer (I have tested this with pdfsig from poppler and MuPDF-GL) display the digital signature at all?
After patching, I checked with … – Acrobat Reader: doesn’t recognize a signature – Foxit Reader: "there’s something wrong with a signature" (i.e. different message) – Apple Preview: doesn’t handle signatures at all – PDF Studio Pro 2023: shows signature, "don’t know if valid, issuer unknown" etc. – Master PDF Editor: can edit form fields, but doesn’t handle signatures – Skim: doesn’t handle signatures Hraban
On 6/17/24 20:21, Henning Hraban Ramm wrote:
[...] Can confirm.
Many thanks for your testing, Hraban.
Before patching, I checked with … – Acrobat Reader: doesn’t recognize a signature – Foxit Reader: "a signature is invalid"
The signature is invalid since it leaves an space outside the signing range.
After patching, I checked with … – Acrobat Reader: doesn’t recognize a signature – Foxit Reader: "there’s something wrong with a signature" (i.e. different message)
The certificate is self-signed. Its validity (not the correctness of the signature) is problematic to say the least.
– PDF Studio Pro 2023: shows signature, "don’t know if valid, issuer unknown" etc.
Again, as a certificate, this is a crappy. But this detects document modifications after being signed. Just in case Hans reads the message: It would be great that OpenSSL asks for the password directly. This is a basic security issue, not to leave plain-text passwords on the terminal. Many thanks for your help, Pablo
On 6/17/2024 7:51 PM, Pablo Rodriguez via ntg-context wrote:
Dear list,
the latest version of LMTX can digitally sign PDF documents. It requires OpenSSL installed (since it does the crypto part).
I have two issues that I would like to be tested by others.
A sample certificate may be found at https://mailman.ntg.nl/archives/list/ntg-context@ntg.nl/message/ECSXLVMT3TMQ... (I sent it myself).
Here is a sample document (actually provided by Hans):
\setupinteraction[state=start] \definefield[signature][signed] \defineoverlay[signature][my signature] \starttext \startTEXpage[offset=1ts,frame=on,framecolor=darkblue] sign: \inframed[background=signature,framecolor=darkred] {\fieldbody[signature][width=3cm,option=hidden]} \stopTEXpage \stoptext
After compiling the sample, you need to run:
mtxrun --script pdf --sign --certificate=c.pfx --password=ABCabc doc.pdf
Password will be prompted again ("ABCabc"), since it is an encrypted certificate (also for the public part).
Could anyone confirm the following issues?
1. The signature I get is wrong, unless I apply this patch (https://mailman.ntg.nl/archives/list/dev-context@ntg.nl/message/T3OCKVZWTUTI... [sent by myself to the devel list]).
2. I cannot get any signature display in Acrobat. Does any PDF viewer (I have tested this with pdfsig from poppler and MuPDF-GL) display the digital signature at all?
i use a pem this whole digitial signing is a bit of a scam imo ... - one has to buy a specific kind of certificate - often one is supposed to use some token - when the root cert expires one has to resign - reader has root certs built in and checking is supposed to be online - it doesn't come cheap and supporting / testing is not something one can expect for free (so i can't really test it) ... so just some business model and not really something one can do out of the box ... apart from ... - just sign with some certificate and don't expect viewers to do something - offer a service to upload the document for checking when a user is in doubt - that can be done without root cert and basically works as long as the service works concerning the suggested patches: this <....whatever....> boundary is a bit fuzzy and i found that different viewers / checkers expect either or not +/- 1 but i didn't check recently if things have improved if we know the specs and have way to test ... no big deal to fix a few offsets Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/18/24 00:52, Hans Hagen via ntg-context wrote:
[...]>> 2. I cannot get any signature display in Acrobat. Does any PDF viewer (I have tested this with pdfsig from poppler and MuPDF-GL) display the digital signature at all?
On 6/17/2024 7:51 PM, Pablo Rodriguez via ntg-context wrote: this whole digitial signing is a bit of a scam imo ...
Digital signing may be a marketing gig also, but we may only consider the pure feature as such. I mean, I’m not interested here in the legally binding value of certain digital certificates, but just in having digital signatures right.
- one has to buy a specific kind of certificate
Generating certificates with OpenSSL is basically free.
- often one is supposed to use some token
- when the root cert expires one has to resign
I think this may be avoided by adding a timestamp token (as unsigned attribute) in the PKCS#7 (as mentioned in the PDF spec).
- reader has root certs built in and checking is supposed to be online
- it doesn't come cheap and supporting / testing is not something one can expect for free (so i can't really test it)
... so just some business model and not really something one can do out of the box
This is all related to certificate (legal) validity. This is out of the scope.
... apart from ...
- just sign with some certificate and don't expect viewers to do something
Acrobat may be wrong in not detecting the signature (I’m investigating it).
concerning the suggested patches: this <....whatever....> boundary is a bit fuzzy and i found that different viewers / checkers expect either or not +/- 1 but i didn't check recently if things have improved
There are two different issues here: digest mismatch and total document signing. I’m afraid that the patch is needed since /ByteRange excludes a blank space before the value of /Contents that is in the temporary file (tmpfile). I mean, here are the contens of the temporary file from the sample (tweaked to fit a single line]): << /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents / Byte 6421 is the s (before the underscore): << /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents_ / The blank space (marked above with the underscore) is included in the hashed file (tmpfile), but it is not included in the /ByteRange. This is the reason why we can only have digest mismatch. As for total document signing, it is better only to exclude from /ByteRange the value for /Contents (from < to >). As far as I can remember, this is mandatory for PDF-2.0 (and highly recommended for previous versions [although not required]).
if we know the specs and have way to test ... no big deal to fix a few offsets
I’m happy to contribute as far as I can. Sorry for insisting, but please don’t require plaintext password in the command line (again, OpenSSL prompts for it). Many thanks for your help, Pablo
On 6/18/2024 8:44 AM, Pablo Rodriguez via ntg-context wrote:
On 6/18/24 00:52, Hans Hagen via ntg-context wrote:
[...]>> 2. I cannot get any signature display in Acrobat. Does any PDF viewer (I have tested this with pdfsig from poppler and MuPDF-GL) display the digital signature at all?
On 6/17/2024 7:51 PM, Pablo Rodriguez via ntg-context wrote: this whole digitial signing is a bit of a scam imo ...
Digital signing may be a marketing gig also, but we may only consider the pure feature as such.
I mean, I’m not interested here in the legally binding value of certain digital certificates, but just in having digital signatures right.
- one has to buy a specific kind of certificate
Generating certificates with OpenSSL is basically free.
you cannot use a 'web certificate'
- often one is supposed to use some token
- when the root cert expires one has to resign
I think this may be avoided by adding a timestamp token (as unsigned attribute) in the PKCS#7 (as mentioned in the PDF spec).
dunno, can test it
- reader has root certs built in and checking is supposed to be online
- it doesn't come cheap and supporting / testing is not something one can expect for free (so i can't really test it)
... so just some business model and not really something one can do out of the box
This is all related to certificate (legal) validity. This is out of the scope.
whatever ...
... apart from ...
- just sign with some certificate and don't expect viewers to do something
Acrobat may be wrong in not detecting the signature (I’m investigating it).
i think it only looks for 'official' onex
concerning the suggested patches: this <....whatever....> boundary is a bit fuzzy and i found that different viewers / checkers expect either or not +/- 1 but i didn't check recently if things have improved
There are two different issues here: digest mismatch and total document signing.
I’m afraid that the patch is needed since /ByteRange excludes a blank space before the value of /Contents that is in the temporary file (tmpfile).
i need to test more
I mean, here are the contens of the temporary file from the sample (tweaked to fit a single line]):
<< /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents /
Byte 6421 is the s (before the underscore):
<< /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents_ /
The blank space (marked above with the underscore) is included in the hashed file (tmpfile), but it is not included in the /ByteRange.
This is the reason why we can only have digest mismatch.
yes but that what i noticed when testing: mupdf, qpdf, acrobat, etc .. trial and error is not to add that one
As for total document signing, it is better only to exclude from /ByteRange the value for /Contents (from < to >).
As far as I can remember, this is mandatory for PDF-2.0 (and highly recommended for previous versions [although not required]).
not sure what you mean, 2.0 demanding signing?
if we know the specs and have way to test ... no big deal to fix a few offsets
I’m happy to contribute as far as I can.
Sorry for insisting, but please don’t require plaintext password in the command line (again, OpenSSL prompts for it). not if we use the library
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/18/24 10:27, Hans Hagen via ntg-context wrote:
On 6/18/2024 8:44 AM, Pablo Rodriguez via ntg-context wrote:
[...] Generating certificates with OpenSSL is basically free.
you cannot use a 'web certificate'
Self-signed certificates may be used to stamp PDF documents to set both signing time and to detect modifications after signing. In fact, I’m planning to digitally stamp documents at work to ensure they aren’t modified after submission (by people or by any automated program).
I think this may be avoided by adding a timestamp token (as unsigned attribute) in the PKCS#7 (as mentioned in the PDF spec).
dunno, can test it
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.... refers to https://www.rfc-editor.org/rfc/pdfrfc/rfc3161.txt.pdf#page=20. Not sure how to get that with OpenSSL (never tried). But I may ask how to get that at their GitHub repository.
Acrobat may be wrong in not detecting the signature (I’m investigating it).
i think it only looks for 'official' ones
I have created self-signed certificates with Acrobat Reader and signed PDF documents with both ones (cert and Acrobat) and Acrobat displayed these signatures. I have used the provided certificate to sign with pdfsig and Acrobat displayed the signature. I think Acrobat may be misbehaving here (requiring some optional content as mandatory).
I’m afraid that the patch is needed since /ByteRange excludes a blank space before the value of /Contents that is in the temporary file (tmpfile).
i need to test more
Perfectly fine for me. Of course, it should be tested more.
The blank space (marked above with the underscore) is included in the hashed file (tmpfile), but it is not included in the /ByteRange.
This is the reason why we can only have digest mismatch.
yes but that what i noticed when testing: mupdf, qpdf, acrobat, etc .. trial and error is not to add that one
Sorry, but I have to be missing your point completely. /ByteRange considers this part of the document to be written as: << /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents<3… But document is written, hashed and signed: << /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents <3… Of course, the value of the contents hasn’t been hashed, but the blank space between /Contents and is value has been hashed. As far as I know, this has to be a reason for digest mismatch (or a huge hash collision).
As far as I can remember, this is mandatory for PDF-2.0 (and highly recommended for previous versions [although not required]).
not sure what you mean, 2.0 demanding signing?
Not at all. Sorry for my poor wording. From the PDF-1.7 spec itself (https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008....): 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. Signatures in PDF-2.0 loose their possibility of other ranges than the entire file. Their use is simply not allowed.
Sorry for insisting, but please don’t require plaintext password in the command line (again, OpenSSL prompts for it). not if we use the library
Weird, on both Linux64 and Win64, the openssl runner requires the openssl binary to be installed. Many thanks for your help, Pablo
On 6/18/2024 6:26 PM, Pablo Rodriguez via ntg-context wrote:
On 6/18/24 10:27, Hans Hagen via ntg-context wrote:
On 6/18/2024 8:44 AM, Pablo Rodriguez via ntg-context wrote:
[...] Generating certificates with OpenSSL is basically free.
you cannot use a 'web certificate'
Self-signed certificates may be used to stamp PDF documents to set both signing time and to detect modifications after signing.
In fact, I’m planning to digitally stamp documents at work to ensure they aren’t modified after submission (by people or by any automated program).
well, if you can figure it out ... i'll can only spend time on it in a real project (it's notp that interesting as hobby)
I think this may be avoided by adding a timestamp token (as unsigned attribute) in the PKCS#7 (as mentioned in the PDF spec).
dunno, can test it
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.... refers to https://www.rfc-editor.org/rfc/pdfrfc/rfc3161.txt.pdf#page=20.
Not sure how to get that with OpenSSL (never tried). But I may ask how to get that at their GitHub repository.
ok
Acrobat may be wrong in not detecting the signature (I’m investigating it).
i think it only looks for 'official' ones
I have created self-signed certificates with Acrobat Reader and signed PDF documents with both ones (cert and Acrobat) and Acrobat displayed these signatures.
ok
I have used the provided certificate to sign with pdfsig and Acrobat displayed the signature.
I think Acrobat may be misbehaving here (requiring some optional content as mandatory).
dunno, if you can create examples i suppose we can reverse engineer them because the standard is fuzzy
I’m afraid that the patch is needed since /ByteRange excludes a blank space before the value of /Contents that is in the temporary file (tmpfile).
i need to test more
Perfectly fine for me. Of course, it should be tested more.
The blank space (marked above with the underscore) is included in the hashed file (tmpfile), but it is not included in the /ByteRange.
This is the reason why we can only have digest mismatch.
yes but that what i noticed when testing: mupdf, qpdf, acrobat, etc .. trial and error is not to add that one
Sorry, but I have to be missing your point completely.
/ByteRange considers this part of the document to be written as:
<< /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents<3…
But document is written, hashed and signed:
<< /ByteRange [ … 0000006421 0000010520 0000000384 ] /Contents <3…
Of course, the value of the contents hasn’t been hashed, but the blank space between /Contents and is value has been hashed.
i know but when i tested with q and m that spaces was kind of fuzzy so i stuck with what seemed to work
As far as I know, this has to be a reason for digest mismatch (or a huge hash collision).
could be (depends on checker) but it we change that we also need to change the verfy offset (so two patches)
As far as I can remember, this is mandatory for PDF-2.0 (and highly recommended for previous versions [although not required]).
not sure what you mean, 2.0 demanding signing?
Not at all. Sorry for my poor wording. From the PDF-1.7 spec itself (https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008....):
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.
Signatures in PDF-2.0 loose their possibility of other ranges than the entire file. Their use is simply not allowed.
so more limited then to basically two ranges
Sorry for insisting, but please don’t require plaintext password in the command line (again, OpenSSL prompts for it). not if we use the library
Weird, on both Linux64 and Win64, the openssl runner requires the openssl binary to be installed.
i meant the --library option
Many thanks for your help, Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/18/24 18:42, Hans Hagen via ntg-context wrote:
On 6/18/2024 6:26 PM, Pablo Rodriguez via ntg-context wrote:
[...] As far as I know, this has to be a reason for digest mismatch (or a huge hash collision).
could be (depends on checker) but it we change that we also need to change the verify offset (so two patches)
I have just discovered that verify didn’t work with the binary. Figuring out now how to testing with the library.
Signatures in PDF-2.0 loose their possibility of other ranges than the entire file. Their use is simply not allowed.
so more limited then to basically two ranges
It makes sense and it is recommended for PDF-1.x.
Sorry for insisting, but please don’t require plaintext password in the command line (again, OpenSSL prompts for it). not if we use the library
Weird, on both Linux64 and Win64, the openssl runner requires the openssl binary to be installed.
i meant the --library option
In that case, when --library is not invoked, we might avoid mandating the password in plain text. Many thanks for your help, Pablo
On 6/18/24 19:28, Pablo Rodriguez via ntg-context wrote:
[...] I have just discovered that verify didn’t work with the binary.
Figuring out now how to do the testing with the library.
For some strange reason, I cannot get --library verification. I only get: sign pdf | verifying with the binary is not yet implemented sign pdf | signature in file 'a.pdf' doesn't match the content I‘m afraid I don’t know what I’m missing. Many thanks for your help, Pablo
On 6/18/24 19:28, Pablo Rodriguez via ntg-context wrote:
[...] I have just discovered that verify didn’t work with the binary.
Figuring out now how to do the testing with the library.
For some strange reason, I cannot get --library verification.
I only get:
sign pdf | verifying with the binary is not yet implemented sign pdf | signature in file 'a.pdf' doesn't match the content
I‘m afraid I don’t know what I’m missing.
On 6/18/2024 7:42 PM, Pablo Rodriguez via ntg-context wrote: probably a couple of libraries ... local libfiles = os.name == "windows" and { "libcrypto-3-x64", "libssl-3-x64" } or { "libcrypto", "libssl" } ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 6/19/24 09:28, Hans Hagen via ntg-context wrote:
[...] I‘m afraid I don’t know what I’m missing. probably a couple of libraries ...
local libfiles = os.name == "windows" and { "libcrypto-3-x64", "libssl-3-x64" }
On MSYS2 (Win10), I have both libs even on the bin directory.
or { "libcrypto", "libssl" }
On Linux, I have both (from openssl-libs.x86_64 and openssl-libs.i686): /usr/lib64/libcrypto.so.3 /usr/lib64/libcrypto.so.3.2.1 /usr/lib64/libssl.so.3 /usr/lib64/libssl.so.3.2.1 /usr/lib/libcrypto.so.3 /usr/lib/libcrypto.so.3.2.1 /usr/lib/libssl.so.3 /usr/lib/libssl.so.3.2.1 This might be causing the issue, but I’m afraid Wine needs 32bit libs. I need to check this further. Pablo
participants (3)
-
Hans Hagen -
Henning Hraban Ramm -
Pablo Rodriguez