Multiple signatures - why don't they work ?

View: New views
2 Messages — Rating Filter:   Alert me  

Multiple signatures - why don't they work ?

by ABU-7 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

It's more than one week I'm thinking about multiple signatures.
Bruno Lowagie demonstrated in an ample tutorial
  [http://itext.ugent.be/articles/eid-pdf/index.php]
how to add signatures :
  "approval" signatures and "certification" signatures.
Unfortunately, that tutorial ended showing the inability to add an
approval-signature to a certified document


I think there's a bit of confusion about these two kinds of
signatures,
and moreover I believe there's an error in the current iText library
(1.4.5) preventing to move forward.

---- concept section ----------
Just to provide a sound basis to the following discussion, here is a
short recall  to terms and concepts ...

* [from "Digital Signatures in the PDF Language" - Adobe Dev.Tech.
Note]
Certification-signatures are almost identical to approval-signatures.
The difference include:
* a cert-signature is always the first signature applied to a doc.
* an entry is made into a root dictionary that indicates that the
signature is a cert-signature.
When the originator (the author) makes a certification-signature, he
also must specify what changes are allowed, choosing one of three
levels of modification permitted:
1) no changes
2) form fill-in only
3) form fill-in and commenting

--- end of concept section ----

Now, let's take back to the discussion ...

As demonstrated by Bruno in its above cited tutorial,
we know we can add many approval-signature to a document.
These signatures are progressively appended within the PDF structure,
and the resulting document is made of incremental revisions that can
be examined separately.
Since a new approval-signature is not "merged" with the originally
signed-document but it is simply "appended", it means that a new
approval-signature does not "invalidate" the previous ones !
  A new signature "extends" the original document plus the previous
signatures.

So, at this time we can ask:
"why the hell, in practice, a new signature invalidates a
  certification-signature" ???

Well, the answer is that a new signature does not invalidate a
certification-signature, i.e. it does not "break" that signature but,
it "breaks" the intentional limitations the author set for that
document.
(Here you can go back reading the "three levels of modification
permitted").

I think we should pay attention (and respect) to the author's
intentions:
...
If you add a paragraph, some text or graphics over a "certified"
document (..you know how to do it with iText ...), you could
(even maliciously) deeply change the original 'meaning' of the
document;
the resulting doc could be very different from the author's
intentions.
  In this case, should the author's certification (the cert-signature)
  be still valid ??
  NO. This is not what the author provided.


Therefore, when an author certifies a document,
he/she also enforces some limitations to subsequent changes.


Now we should restart from those "three level of modification
permitted"
if we want to add multiple signatures

It is obvious that a certification-signature (level 1) does not allow
ANY further signature; it prohibits ANY change!
On the other hand, with a certification-signature (level 2/3) we
"could"
make next approval-signature but, be careful ! You are not allowed to
ADD
a signature, you are only allowed to FILL an existing signature field.

To conclude, if the author provides a "certified" document with some
blanc signature fields, then you are allowed to FILL-IN those sign-
fields
without invalidating the author's intentions.

-----
Just to go back to the current state of the iText library (1.4.5),
 you can verify that there are two problems ...
 
The first one is with the  "addDocMDP" method
 (within the "PdfSignatureAppearance.java" file)
 "addDocMDP" allows certification-signatures with "level 1" permission
only !
There should be a way to specify level 2 or 3, too.
This is not difficult to fix, but there is the second problem ...

The second (BIG) problem in "PdfSignatureAppearance.java" is that when
you
add an approval-signature over an existing blanc signature field, you
*apparently* fill that field, but actually the following steps are
performed:
  * create a duplicate of the signature field
  * fill it with the 'appearance' stuff
  * delete the original field
  * add the new field
  *   ....
  * sign the document
 
 You can get a quick confirm of this behaviour by opening a signed
document
 with AcrobatReader:
   [ http://itext.ugent.be/articles/eid-pdf/pdf/EIDFormInvalid.pdf ]
 Look at the "Signature Property" related to the first signature
 (it is a certification-signature), go to the "Document" tab and press
 the "Show changes" button.
 Now you can read details (this is a rough translation from Italian):
   *  added "Signature2" field at page 1
   * deleted "Signature2" field at page 1
   * field "Signature2" at page 1 filled-in
   * 2 changes  (????)
   
   ======================
   
Just to resume:

**1**
If we want to add multiple-signatures to Certificated-documents, we
need
the original certificated-doc were created with a "permission-level"
equal
to 2 or 3( level 1 means "NO change allowed" ).
Note that the next signatures should FILL the originally provided
(blanc)
signature fields (i.e. No one is allowed to ADD a new (signature)
field,
you are only allowed to FILL those fields the author's provided )

This is easy to do with just a little internal patch in
"PdfSignatureAppearance.java"

**2**
The actual implementation of "PdfSignatureAppearance", does not FILL
an existing signature-field; it ADDS a clone (hiding the original).

Although the "apparent" result is valid (i.e. ALL the signatures are
valid), this operation (so implemented) breaks the special meaning
of the certification-signature (remind the 3 "permission-levels" )
set by the author.

   ======================

I hope my arguments may help to find a solutions.

Aldo Buratti


Naviga e telefona senza limiti con Tiscali    
Scopri le promozioni Tiscali adsl: navighi e telefoni senza canone Telecom

http://abbonati.tiscali.it/adsl/


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
iText-questions mailing list
iText-questions@...
https://lists.sourceforge.net/lists/listinfo/itext-questions

Parent Message unknown Re: Multiple signatures - why don't they work ?

by Paulo Soares :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

 

> -----Original Message-----
> From: itext-questions-bounces@...
> [mailto:itext-questions-bounces@...] On
> Behalf Of aldo.buratti@...
> Sent: Friday, October 27, 2006 1:32 PM
> To: itext-questions@...
> Subject: [iText-questions] Multiple signatures - why don't they work ?
>
...(skipped introdution)

> Just to go back to the current state of the iText library (1.4.5),
>  you can verify that there are two problems ...
>  
> The first one is with the  "addDocMDP" method
>  (within the "PdfSignatureAppearance.java" file)
>  "addDocMDP" allows certification-signatures with "level 1"
> permission
> only !

Yes, only "level 1", no change, and it will only work in Acrobat 7.

> There should be a way to specify level 2 or 3, too.
> This is not difficult to fix, but there is the second problem ...

This is difficult to implement.

>
> The second (BIG) problem in "PdfSignatureAppearance.java" is
> that when
> you
> add an approval-signature over an existing blanc signature field, you
> *apparently* fill that field, but actually the following steps are
> performed:
>   * create a duplicate of the signature field
>   * fill it with the 'appearance' stuff
>   * delete the original field
>   * add the new field
>   *   ....
>   * sign the document
>  
>  You can get a quick confirm of this behaviour by opening a signed
> document
>  with AcrobatReader:
>    [ http://itext.ugent.be/articles/eid-pdf/pdf/EIDFormInvalid.pdf ]
>  Look at the "Signature Property" related to the first signature
>  (it is a certification-signature), go to the "Document" tab and press
>  the "Show changes" button.
>  Now you can read details (this is a rough translation from Italian):
>    *  added "Signature2" field at page 1
>    * deleted "Signature2" field at page 1
>    * field "Signature2" at page 1 filled-in
>    * 2 changes  (????)
>    
>    ======================
>    
> Just to resume:
>
> **1**
> If we want to add multiple-signatures to Certificated-documents, we
> need
> the original certificated-doc were created with a "permission-level"
> equal
> to 2 or 3( level 1 means "NO change allowed" ).
> Note that the next signatures should FILL the originally provided
> (blanc)
> signature fields (i.e. No one is allowed to ADD a new (signature)
> field,
> you are only allowed to FILL those fields the author's provided )
>
> This is easy to do with just a little internal patch in
> "PdfSignatureAppearance.java"
>
> **2**
> The actual implementation of "PdfSignatureAppearance", does not FILL
> an existing signature-field; it ADDS a clone (hiding the original).
>
The certified doc can't be changed, it doesn't matter how the field is
changed.

> Although the "apparent" result is valid (i.e. ALL the signatures are
> valid), this operation (so implemented) breaks the special meaning
> of the certification-signature (remind the 3 "permission-levels" )
> set by the author.
>
>    ======================
>
> I hope my arguments may help to find a solutions.
>

The solution is someone implementing the missing parts.

Paulo


Aviso Legal:
Esta mensagem é destinada exclusivamente ao destinatário. Pode conter informação confidencial ou legalmente protegida. A incorrecta transmissão desta mensagem não significa a perca de confidencialidade. Se esta mensagem for recebida por engano, por favor envie-a de volta para o remetente e apague-a do seu sistema de imediato. É proibido a qualquer pessoa que não o destinatário de usar, revelar ou distribuir qualquer parte desta mensagem.

Disclaimer:
This message is destined exclusively to the intended receiver. It may contain confidential or legally protected information. The incorrect transmission of this message does not mean the loss of its confidentiality. If this message is received by mistake, please send it back to the sender and delete it from your system immediately. It is forbidden to any person who is not the intended receiver to use, distribute or copy any part of this message.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
iText-questions mailing list
iText-questions@...
https://lists.sourceforge.net/lists/listinfo/itext-questions