Impacts if I assemble many documents in one signature?

Question

I am familiar with PKI and signing one document (for instance XML content) using PKCS7 or XAdES and we provide this functionality to our customer. Works fine. I now wonder how to facilitate the signing of a set of documents, that is signing the whole folder (set of documents) with one signature. The set can be viewed as a main document and some attachments.

My idea is to build an XML file including references to each document. The reference could be the hash of the document (value and algorithm). The customer will sign this XML file (like before with our RSA PKI).

Questions are:

• What do I break in my new mechanism where I add this level of indirection (we sign in fact something like a manifest and not the data)
• What is the legal value of this? Maybe we lost the integrity of the signature, and we break the non repudiation.
• Shall we validate (certify) our process (XML generation and keep the links of references) to a third party to guarantee the non repudiation?
• How can I exploit the signature? I think I can't show to the customer that he/she has signed only one attachment. I always need to show the whole folder.
• Shall I be aware of some points I forgot here? What do you think of my new mechanism?

Answer 1

Do you want the ability to prove (in court) that Signer A really did sign the collection of documents at some point in time, and that the current version of the documents is the exact same as what were signed?

It sounds like it. Eg you talk about non-reputability.

But if the above is the case, then you need to be very careful about how the signature validation would work in practice. If your software is the only software available to verify the signature against the documents, then you are not in a good place since the opposing party can claim that your software is faulty.

The above is why it is a good idea to ensure that your signed documents can be verified by a neutral third party's sw (eg Adobe Reader for PDFs), MS Word for signed Word files, etc.

A signed XML file that includes multiple documents as sub elements sounds like a poor plan to me if you want to prove the signature(s) in court.

The "easy" issue is to ensure that the current documents can be exactly re-assembled for verification as someone commented.

The hard issue is show the verification process in a very easy and understandable way to a completely non-technical person in court.

If you're just signing the XML as an internal control/audit mechanism, then your idea is fine. But if any of the signers are potentially hostile adversaries (or if someone might try to forge their signatures), then I suggest using very straight forward signing techniques whose signatures can be easily verified with PDF Reader or similar.

If what you want is signed data structures (eg an XML file), you should either verify with commercial off the shelf software, or make a PDF copy of the data and get both the XML and PDF files signed.

Answer 2

There are many ways to do this, you could create an archive and then sign the whole archive, for example with gpg-zip (which despite the name, actually creates a tar file).

Another way is to create a manifest file, which is a file containing the hashes of the files in the archive, then sign the manifest. This is used, for example in signed jar and deb packages.

There are pros and cons with both while file signature and manifest signature.

A whole file signature is much easier for the recipient to verify. However, it's also much less flexible than manifest-based signature. A manifest based signing allows you to implement policy specification in the manifest file, or to face multiple manifests for different classes of users.

A whole file signature may also be vulnerable to length extension attack if you use a signature algorithm that are vulnerable to length extension attack like sha1 or md5. A manifest signing on the other hand, would limit such length extension attacks to individual files.

Users of manifest-signed packages have to be aware what exactly is signed and not signed in the package. If the package can contain both signed and unsigned packages, it's possible for a buggy implementation to say that the package signature looks fine, but doesn't verify or indicate to the user that some extracted files are not verified if they lack entries in the manifest. This makes verification more tricky.