Support of Digital Signatures (PKCS#7) + TSA timestamp #48
Conversation
This will make possible the implementation of document signature, because we need to exclude this specific byte range from the hash digest.
allows to sign pdf document using PKCS#7 detached format, digest algorithm should be SHA1 (only one supported in PDF 1.4)
as recommened by PDF specs. + renamings + use PdfSharp internal Hex conversion
|
Signature computation is working well, ` Signature contains incorrect, unrecognized, corrupted or suspicious data. I don't get to know what is causing the issue. Btw I tried to sign with an auto-signed certificate. |
so that PDF readers can properly detect the signature
Signature feature is now working
With commit 80cdf02 I fixed the issue: the signature field was not properly added to the AcroForm array. Now that it is in the AcroForm, Adobe properly detects it and display a more explicit message about my signature issue. There may be a bug on AcroForm.Fields@ThomasHoevel @PDFsharp-Team I had to make PdfAcroField.PdfAcroFieldCollection's constructor internal instead of private in order to instanciate it. Indeed when accessing document.Catalog.AcroForm.Fields, _fields is null and it tries to create an instance via VCF.CreateIndirect parameter, but Reflection then fails to find a constructor. |
|
Last thing to handle now is the signature's appearance that seems to not be displayed properly. |
Hi, I tried with a trusted certificate but get the same error |
julienrffr
changed the title
Does the certificate has a root certificate (+ intermediate certificate) + end user certificate? |
Yes the root is part of the Adobe AATL, the certificate was created using sectigo |
in DEBUG, a space delimiter is added between entry key and entry value, but not in RELEASE
Did you try in DEBUG or RELEASE build? |
Was using DEBUG, below is the adobe errors.
|
sign with SHA256 instead
Hi @ibrahimAliTecman, I fixed the issue on the byte range computation that was caused by extra spaces added in DEBUG mode due to Verbose writer layout. Please test again and let me know, signature should be fine now. Only thing remaining to do is the signature appearance to take care of. I'll do that in the next days. |
Hi, Awesome! it is working now. Verifies signature correctly. Thank you! |
|
I've just pushed 496c553 that allows to define a custom appearance for the signature field. Since everything is working fine now, I'm setting the pr as ready for review. I'm totally willingful to adjust code so it could fit better in PDFsharp lib, if any chances that something would be merged some day. Note: known limitation is that currently it can only sign unsigned documents. |
The signature is appearing blank still with the latest commit, is there anything that needs to be changed in the calling method? |
Please provide your code and the generated pdf. Here is a working Program for me, with bith default appearance and custom appearance: |
|
Hey, would it be hard to implement : a) multiple signatures on a file (with only one open/save) I've tried do make it work for several hours without success. Do you have anything almost working so I can try to help ? |
Hi, a) applying multiple signatures on a file in a single open/save seems at least complicated, not sure if it's feasable. NB: signature feature is now available in PDFsharp-extended nuget package |
julienrffr
changed the title
|
Hi, |
Update on the 'signing an already signed document' question: |
|
Julien, thank you for your work! |
|
Maybe I'm doing something wrong, but I got the PR using Does anybody have some useful tips for me?
|
Hi @ThomasHoevel , Indeed, I've just synchronized this pull request with your new release 6.1.0 (which now includes netstandard support) and I started to work on the compatibility because the last feature I introduced recently (signature timestamp) is not compatible yet. To compile, for now you could just comment the method AddTimestampFromTSAAsync and its call in \src\foundation\src\PDFsharp\src\PdfSharp\Pdf.Signatures\DefaultSigner.cs (and removing the not-compatible usings of course). I'm working on this compatibility for this recent feature but it's not my top priority right now. I'll try to push something that compiles out-of-the-box ASAP. In the meantime feel free to contact me for any support (here, via mail or Teams or Zoom). |
|
Thanks for the feedback. I already figured out that TSA is the problem and used "#if NET6_0_OR_GREATER" to exclude that. Now I get a warning I cannot yet resolve: It's a company policy that projects compile without warnings. Sooner or later I will also have to address the following compile-time warnings: |
I'll try to take a look on that also when I have some time. By the way, do you have an idea of how you'll introduce signatures feature? |
|
I have no idea yet. I will try to resolve the compile-time warnings, so there is no need for you to work on that, too. |
|
I fixed the build by making the timestamp feature only available on net6+. There would be 2 things to handle to make it available for netfx/netstandard2 too:
For the basic 'how it works': |
Regarding design of the signature feature, |
|
This has become an increasingly hot topic for us as well. Expanding on my initial proposal for incremental updates (#112) and building upon the excellent work by @julienrffr it was surprisingly straightforward to support multiple signatures. Opening such a document in Acrobat Reader: Because signing a document is always applied as an incremental update, a 2-step process is required for every signature:
This is a POC that demonstrates how signing could look like in PDFSharp. Side-Note: |
|
Thank you @packdat that's awesome! |
Any chance this could be merged into KDS:signature-feature or made available in a separate KDS branch? Would really like to experiment with this! |
@packdat could you create a PR to https://github.com/KDS/PDFsharp/tree/signature-feature with your work? |
|
@CrunchTech @julienrffr |
Much appreciated! |
@ThomasHoevel |
|
We have now also successfully modified PDFSharp 6.2preview1 using @julienrffr 's and @packdat 's features to support external device digital signatures. The changes can be seen here: KDS#6 |
|
There was one problem we found in @packdat 's incremental save where the PdfSharp uses reflection to construct some objects, and then some of the fields gets lost and it breaks the logic |
Can you explain this? Is it related to trimming? The trimming issue is resolved in another PR. |
|
In In Migradoc security tests i.e. "Test_Read_UserAndOwnerPassword_User_Import" Another problem was that PdfItem implements ICloneable interface which requires parameterless Clone method and the clone method sets Owner document null, then when it starts cloning the fields it needs the owner doc. Without the null check this path crashes, but having the null check is a bit dangerous because then those need to be tracked manually on the callsite ( recursively ? ) |
Adding:
I tried to do minimal changes in existing classes (only PdfDocument class has been modified to add BeforeSave/AfterSave events, and PdfString in order to track position in stream).
PdfString could have not been modified if it was not sealed.
This is a port from empira/PDFsharp-1.5#11 but with way smaller footprint.
Usage example (files in demo-signature.zip):
demo-signature.zip
Let me know any suggestions.
NB: this feature is available in PDFsharp-extended nuget package