3 ms·

The core problem seems to be: For instance, overwriting content on a page of the document is not allowed and thus leads to invalid signature verification. N

by xtacy 6y ago

The core problem seems to be: For instance, overwriting content on a page of the document is not allowed and thus leads to invalid signature verification. Nevertheless, some changes are considered harmless by the PDF applications and do not throw any warnings I am trying to understand if there is any design consideration behind not signing the entire PDF, but only some sections?

josephcsible 6y ago
One obvious need is other signature blocks that haven't yet been signed. When you sign a PDF, your name and the date end up in the signature block that's part of the PDF and, e.g., prints with it. If you had to sign the entire PDF, then a second person adding their signature would invalidate the first one.
- Bootvis 6y ago
  Surely there must be a way to have an order of signing so that additional signing doesn’t invalidate previous signatures.
- sarakayakomzin 6y ago
  >If you had to sign the entire PDF, then a second person adding their signature would invalidate the first one. ...no, you would just sign the entire thing with the previous signature included. This means you couldn't have signed before them and order is preserved.
layer8 6y ago
That is not quite what is happening. PDF has a feature called "incremental update", where changes to the document are not done in-place in the PDF object structure, but instead are appended as an incremental update to the existing PDF file. PDF files are interpreted starting at the end, where there is a root node linking to the rest of the PDF object structure. Such an incremental update replaces the root node, and thereby can replace parts (or all) of the previous document revision. Basically this works like a persistent (immutable) data structure. To enable multiple signatures, each signature is appended as an incremental update (and so does not break any preceding signatures), and each signature only signs the document revision where it was added. Now, there are a number of updates one may want to apply to a signed PDF: adding further signatures, adding document timestamps (also a kind of signature), filling in form elements (in documents where multiple people have to fill out parts of a form and each have to sign their parts), adding annotations (comment boxes, highlighting). For that reason, signature validators have to decide, for all incremental updates that follow a given signature, whether the changes done by those incremental updates are harmless and constitute an intended use case like the ones listed above, or whether they are potentially harmful and try to give the impression that something else was signed than what was actually signed. The good thing is: Since the incremental updates preserve the revision history of the PDF, one can easily inspect what was originally signed. For example, Acrobat Reader provides a UI command "Show Signed Version" on each signature, which then opens the signed prefix of the PDF, that is, with the subsequent incremental updates removed. The problem is that many users are not aware of this and therefore can be deceived by fraudulent incremental updates if the PDF viewer doesn't indicate that there is an issue.
- thaumasiotes 6y ago
  > Now, there are a number of updates one may want to apply to a signed PDF: > [such as] filling in form elements (in documents where multiple people have to fill out parts of a form and each have to sign their parts) > For that reason, signature validators have to decide, for all incremental updates that follow a given signature, whether the changes done by those incremental updates are harmless and constitute an intended use case like the ones listed above, or whether they are potentially harmful and try to give the impression that something else was signed than what was actually signed. I don't see how filling in form elements could possibly be considered harmless? Why is that listed under intended use cases?
  - layer8 6y ago
    Imagine a form that is split into two sections, each of which has to be filled out and signed by a differemt person. The first person filling and signing will implicitly also sign the empty fields of the second person, and the second person will then change those fields to have actual values. The author of the form can specify which fields are allowed to be changed after which signature, and a validator would have to check that those constraints were observed. EDIT: You may have come across forms with fields marked with something like “don’t fill out this field, it will be filled in by the clerk processing the form”. That’s one kind of use case.
    - thaumasiotes 6y ago
      > The author of the form can specify which fields are allowed to be changed after which signature, and a validator would have to check that those constraints were observed. This can work, but it seems simpler to just have separate documents for each party to sign. It's easier to understand and much less prone to hidden failures when someone makes a mistake marking fields. If the value you put into a form is irrelevant to whether I sign it, just put that form in your document and not my document.

by xtacy 6y ago

josephcsible 6y ago

One obvious need is other signature blocks that haven't yet been signed. When you sign a PDF, your name and the date end up in the signature block that's part of the PDF and, e.g., prints with it. If you had to sign the entire PDF, then a second person adding their signature would invalidate the first one.

Bootvis 6y ago
Surely there must be a way to have an order of signing so that additional signing doesn’t invalidate previous signatures.
sarakayakomzin 6y ago
>If you had to sign the entire PDF, then a second person adding their signature would invalidate the first one. ...no, you would just sign the entire thing with the previous signature included. This means you couldn't have signed before them and order is preserved.

layer8 6y ago

That is not quite what is happening. PDF has a feature called "incremental update", where changes to the document are not done in-place in the PDF object structure, but instead are appended as an incremental update to the existing PDF file. PDF files are interpreted starting at the end, where there is a root node linking to the rest of the PDF object structure. Such an incremental update replaces the root node, and thereby can replace parts (or all) of the previous document revision. Basically this works like a persistent (immutable) data structure. To enable multiple signatures, each signature is appended as an incremental update (and so does not break any preceding signatures), and each signature only signs the document revision where it was added. Now, there are a number of updates one may want to apply to a signed PDF: adding further signatures, adding document timestamps (also a kind of signature), filling in form elements (in documents where multiple people have to fill out parts of a form and each have to sign their parts), adding annotations (comment boxes, highlighting). For that reason, signature validators have to decide, for all incremental updates that follow a given signature, whether the changes done by those incremental updates are harmless and constitute an intended use case like the ones listed above, or whether they are potentially harmful and try to give the impression that something else was signed than what was actually signed. The good thing is: Since the incremental updates preserve the revision history of the PDF, one can easily inspect what was originally signed. For example, Acrobat Reader provides a UI command "Show Signed Version" on each signature, which then opens the signed prefix of the PDF, that is, with the subsequent incremental updates removed. The problem is that many users are not aware of this and therefore can be deceived by fraudulent incremental updates if the PDF viewer doesn't indicate that there is an issue.

thaumasiotes 6y ago
> Now, there are a number of updates one may want to apply to a signed PDF: > [such as] filling in form elements (in documents where multiple people have to fill out parts of a form and each have to sign their parts) > For that reason, signature validators have to decide, for all incremental updates that follow a given signature, whether the changes done by those incremental updates are harmless and constitute an intended use case like the ones listed above, or whether they are potentially harmful and try to give the impression that something else was signed than what was actually signed. I don't see how filling in form elements could possibly be considered harmless? Why is that listed under intended use cases?
- layer8 6y ago
  Imagine a form that is split into two sections, each of which has to be filled out and signed by a differemt person. The first person filling and signing will implicitly also sign the empty fields of the second person, and the second person will then change those fields to have actual values. The author of the form can specify which fields are allowed to be changed after which signature, and a validator would have to check that those constraints were observed. EDIT: You may have come across forms with fields marked with something like “don’t fill out this field, it will be filled in by the clerk processing the form”. That’s one kind of use case.
  - thaumasiotes 6y ago
    > The author of the form can specify which fields are allowed to be changed after which signature, and a validator would have to check that those constraints were observed. This can work, but it seems simpler to just have separate documents for each party to sign. It's easier to understand and much less prone to hidden failures when someone makes a mistake marking fields. If the value you put into a form is irrelevant to whether I sign it, just put that form in your document and not my document.