Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BDOC signatures with same <xades:SigningTime> after serialization #4
Dear friends of open-eid, I hope you are fine.
I am signing a BDOC container several times using the following steps:
Create the container:
Sign the container (two steps signing):
After applying three signatures to the container, these signatures have the same property
Could anyone give me a hint to find out what I am doing wrong please?.
If you wish to view the container it is available here.
One more question:
but I got the following exception:
It appears that it is not possible to save a container after deserializing it. Is this an invalid use of serialize and deserialize functions? I tried to follow this example. Any comment?
Hi Antonio, hope you are well too.
The reason for having the same SigningTime values in different signatures in your case is that when the signature's XML structure is created then the contents of the SigningTime XML element are taken from a signingDate variable (BdocContainer.dssSignatureParameters.bLevelParams.signingDate), the variable is initialized only once. Initialization is done when a new BDocContainer object is created (via the org.digidoc4j.impl.BDocContainer.initASiC() method).
We are working on improving the design of the library, but currently, the solution for you could be to use different Container objects for each signature, e.g. write the container to an output stream, read in again and then add the next signature.
I understand the problem I have with BDOC signatures with same xades:SigningTime. Your recommendation is writing the container to an output stream, reading in again and then adding the next signature.
Could you please give me a basic example of this?
On the other hand, I could test the sample application SerializeExample and it worked fine.
This example creates a new container, adds a DataFile, signs the container and
I did a couple of tests:
i) saving the container without signing it. This throws an exception:
So it is not possible to save a BDOC container with a DataFile but without signing it
ii) In the SerializeExample the BDocContainer.save() function calls InMemoryDocument.save() internally because of the container was created previously, so it can save the file correctly.
However, when I deserialize a BDocContainer (
The code throws this exception:
Could you please let me know how to avoid this?. I really appreciate your comments.
i) The solution could be to use two slightly different deserialization methods during the signature creation process.
When you do the two-step signing:
ii) I couldn't reproduce the error situation. In my case, an InMemoryDocument is always used and exceptions do not occur. I tried with different DataFile sizes, enabled/disabled big file support, etc.
The deserialization method you proposed worked fine in the two-steps signing process. A container now keeps the signing time for each signature.
In ii) the serialized container was this. I have to say that I was using digidoc4j-0.2.9 version. After downloading the new version, digidoc4j-1.0, I could deserialize a BDOCContainer and then save it to disk successfully. InMemoryDocument is always used when I try to deserialize and save the container.
In spite of our work is documented in spanish, you could see our project here. We hope to use a basic service to create and sign BDOCs containers.
Thanks again and I really appreciate your help.