Support multiple signatures #5
Conversation
|
|
||
| private int GetContentLength() | ||
| { | ||
| return signer.GetSignedCms(new MemoryStream(new byte[] { 0 }), document).Length + 10; |
There was a problem hiding this comment.
This method causes the encryption to be called twice, I think that is not good solution, especially if the encryption requires external actions then those are called twice...
There was a problem hiding this comment.
in lopdf this was handled by creating placeholder values which would be changed later: https://github.com/ralpha/pdf_signing/blob/master/src/signature_info.rs#L117-L124
There was a problem hiding this comment.
The content length is used to reserve space in the PDF, where the real signature is stored in a later step.
The current approach was used to get a fairly safe estimate of the length, without the risk of reserving too few or too much space.
You could certainly skip this step, but then you have to reserve space for the largest possible content length of any signer that may be used.
Another approach may be to let the user provide a value (e.g. an EstimatedContentLength - property in the signature-options)
There was a problem hiding this comment.
I at least recommend putting it behind an interface so it can be overriden in the client application. In my use case the digital signature is entered by external card reader and the user needs to enter PIN to the card reader software, asking the PIN twice would be real bad, much worse than causing the pdf size to grow a bit more than necessary
There was a problem hiding this comment.
@Havunen Yeah, that's one use case i didn't had in mind when creating the PR, my bad.
Would be nice if we would know more about how users might apply signatures; when knowing the use cases, we could design better interface to handle these...
| inputStream = documentStream; | ||
| // apply signature as an incremental update | ||
| document = PdfReader.Open(documentStream, PdfDocumentOpenMode.Append); | ||
| signer = new DefaultSigner(signatureOptions); |
There was a problem hiding this comment.
Is there some particular reason why ISigner cannot be given in constructor? Now it always uses DefaultSIgner?
There was a problem hiding this comment.
As stated in the PR, these changes are experimental.
There's no real reason other than that it was the fastest way to come up with a working PoC.
Feel free to adapt to your needs.
| var content = Enumerable.Repeat<byte>(0, contentLength).ToArray(); | ||
| signatureDict.Contents = content; | ||
| signatureDict.Filter = "/Adobe.PPKLite"; | ||
| signatureDict.SubFilter = "/adbe.pkcs7.detached"; |
There was a problem hiding this comment.
For my implementation I had to move these filter types public, because I had to change the subfilter to "ETSI.CAdES.detached"
PR as requested.
Adds support for incremental updates and multiple signatures.
Please consider these changes as highly experimental !