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.pdf#nameddest=G11.2054251 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.pdf#search=ByteRange): 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 ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net ___________________________________________________________________________________
