[NTG-context] Re: digital signing in ConTeXt

[Hans Hagen via ntg-context <ntg-context@ntg.nl>]

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.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.

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.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.

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
-----------------------------------------------------------------

___________________________________________________________________________________
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
___________________________________________________________________________________