I want to implement "parallel" signing process of PDF, so that users can digitally sign document not "one by one", but simultaniously. To implement this, I decided to create separate copies of initial document for all users and get signatures on them. Eventually, all signatures should be concatenated into single PDF.
Let's assume, that PDF is not changing during signing process, except signature field creation (all acroForms, signatureContainers, visual signatures, etc. are created before and similar for all).
.. during futher investigation, I readed this article and understood, that each previous digital signature (even detached) is included into SignedContent of the next signature. So there is no way to put digital signature which will be completely separated from the contents. This leads to a problem, that next signature, can't be calculated, before previous is finished.
Please tell if there is any option to get around this? Or putting signatures "one by one" is the only solution?
P.S. I'm using Apache PDFBox to work with PDF.
Please tell if there is any option to get around this?
If you want your signatures to be interoperable, there is no way around that.
I readed this article and understood, that each previous digital signature (even detached) is included into SignedContent of the next signature
That answer still represents the current situation. If anything, it has been confirmed by newer specifications, e.g. the PAdES specifications referenced in that answer merely were 'technical specifications' (ETSI TS 102 778) and there now are actual norms (ETSI EN 319 142) which also require a pdf signature to sign everything in its revision except its own signature container. Also ISO 32000-2 has been published, still having that requirement for its interoperable signatures and additionally including a shortened copy of the PAdES specification.
You stress "even detached" here. The "detached" in the context at hand only refers to the structure of the CMS container which is embedded in the PDF; it in particular does not refer to the signature being more separated from the PDF or anything like that.
If you don't need to be interoperable, though, there are some options, here two of them which still are quite near to the interoperable signatures:
You can ignore the requirement that a pdf signature must sign everything in its revision except its own signature container.
For example you can prepare multiple signature fields and dictionaries in a single new revision of the document and set each signature's signed byte range to exclude the placeholders of all these signatures.
you can ignore the requirement that there is only a single SignerInfo in the CMS signature container and put SignerInfos from different signing parties into a single signature container in a single signature field.
Common PDF signature validators will,
in case of signatures created as described in the former option, not positively validate, at least most of them,
either because their code is programmed for only two ranges of signed bytes (i.e. a single gap) and so only uses the first two ranges resulting in a wrong document hash;
or because they explicitly require that a signature covers its whole revision minus the single placeholder for the signature container of the signature field being validated; the number of validators of this kind surely has risen since the publication of the "Security of PDF Signatures" master thesis by Karsten Meyer zu Selhausen at the Ruhr-Universität Bochum, see this question.
in case of signatures created as described in the latter option, appear to positively validate, at least many of them, until you look at the validation result in detail and realize that they have validated only one of the SignerInfos and ignored the others.
For example in case of two SignerInfos Adobe Reader validates the second one (I assume it always validates the last one) and eSig DSS validates the first one, and neither one of them currently indicates in the validation result that there may be another SignerInfo present.
A large Swedish security company, for example, implements the second option in its software; in its home brew format PDF/CAdES-A it inserts CAdES-A containers as CMS container in PDFs and allows multiple SignerInfos therein. Obviously, therefore, its own software will recognize and validate all SignerInfos. Nonetheless, this is a home brew solution and not interoperable.
You could use existing software that supports signature workflows - like e.g. we offer at https://www.esignanywhere.net - this software allows to define signature workflows (via API or web user interface). Input can be a PDF document with signature fields as acro form fields, or text placeholders within the PDF. The meta informations defined in eSignAnyWhere allow to assign it to a specific signer. The workflow capabilities allow to define sequential, parallel, or mixed sequential+parallel, signing workflows.
For example, when you perform an call from summary api of wikipedia, there is this header in the request
accept:application/json; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/Summary/1.3.7"
What is the purpose of this particular bit. I would like to understand since the value changes when you, for example, use the VisualEditor or access the api with different mean.
profile="https://www.mediawiki.org/wiki/Specs/Summary/1.3.7"
This specifies the response format and provides convenient access to a human-readable documentation.
The URL in your header leads to nowhere, but https://www.mediawiki.org/wiki/Specs/Summary/1.3.0 does exist and is probably valid for 1.3.7 as well.
I've already found some ways how to generate SHA3 in netcore 2.1. (e.g. SHA3.Net). Is there a way how to generate HMAC using SHA3-512 hash function. AFAIK it should be only some combination of SHA3(secret + content), but I can't find any working solution for HMAC based on SHA3-512. It's requested by 3rd party API I need to use, so there's no other option.
Result must be the same as result provided by this online tool (hash type sha3-512): https://wtools.io/generate-hmac-hash
Does anybody know how to generate HMAC properly for SHA3-512 under .netcore 2.1?
Thanks
I am new to echo sign. I want to implement echo sign using REST API. my question is how could i send a document for signature based on rest calls. is there any sample code for sending documents via rest.
There's not much documentation available but you can start from here:
https://secure.echosign.com/public/docs/restapi/v4#!/agreements/
SOAP documentation seems to be better, giving you a better understanding about the required fields, classes, etc. You can take a look at it here but you'll need to be logged in:
https://secure.echosign.com/public/docs/EchoSignDocumentService21
You can also take a look at these implementations:
https://github.com/nsbucky/echosignv3
https://github.com/nsbucky/echosign
I wanted to generate digital signature in my asp.net application based on some value
like date of birth. what is the way to do that ? i am using vb.net
If you decide that you really do want what that Wikipedia article talks about, then see the SignedXml class in the System.Security.Cryptography.Xml namespace.
Note that this isn't the only way to work with Digital Signature in .NET - it's just the part I've worked with before.