1

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?
5
  • What do you think of my new mechanism? Don't do it. What is the legal value of this? Where?
    – deviantfan
    Nov 2, 2016 at 17:34
  • If you generate a manifest and produce signature of it and keep the signature and throw away the manifest, and later when verifying the signature you generate the manifest again but files are in different order or any other change in encoding, the signature won't match. So keep the manifest. Also be sure to use good hash, maybe multiple good hashes. e.g. rsa+sha256 sig, manifest has name + sha256 + blake2b of every file.
    – Z.T.
    Nov 2, 2016 at 19:03
  • @Z.T. : Ok to keep the manifest. Interesting point : why shall I use multiple hash ? I assume it is to avoid a collision in one hash, so that the second hash may still valuable.
    – Séb N.
    Nov 4, 2016 at 8:31
  • @deviantfan : it is related to the non reputability of the mechanism with a manifest.
    – Séb N.
    Nov 4, 2016 at 8:31
  • @SébN. Ok, but why are you telling me this?
    – deviantfan
    Nov 4, 2016 at 8:32

2 Answers 2

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.

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .