approved sign incorrect certified pdf

[lisicky]

Hi

I use JPdfSign based on iText library.

Now I have problem with certified pdf.

When I add approved signature on certified pdf, which I found in
archive
(http://thread.gmane.org/gmane.comp.java.lib.itext.general/55538/focus=55541)
all is right.

But I got pdf, which is not possible correctly sign. Adobe Reader
write, that original certificate is incorrect.

Where is the mistake?

thanks

PS: sorry for my english

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[mkl]

lisicky,

lisicky wrote

I use JPdfSign based on iText library.

If you mean the "commandline application for signing PDF documents" jPdfSign available from http://private.sit.fraunhofer.de/~stotz/software/jpdfsign/, please be aware that according to that web site the application uses version 1.4 of iText. This version is more than 6 years out of date and a whole lot of changes have been applied to iText since then.

lisicky wrote

But I got pdf, which is not possible correctly sign. Adobe Reader write, that original certificate is incorrect.

Where is the mistake?

If you really want someone to look into that issue, you had better also supply a sample PDF signed by you exhibiting that problem. Or does already the attempt to sign fail?

Regards,   Michael

[lisicky]

----- PŮVODNÍ ZPRÁVA -----
Od: "mkl" <[hidden email]>
Komu: [hidden email]
Předmět: [iText-questions] [SPAM] Re: approved sign incorrect
Datum: 24.7.2012 - 11:10:54

> lisicky,
>
> lisicky wrote
> > I use JPdfSign based on iText library.
>
> If you mean the "commandline application for signing PDF
> documents" jPdfSign
> > available from
> http://private.sit.fraunhofer.de/~stotz/software/jpdfsign/,
> > please be aware that according to that web site the application
> uses version
> > 1.4 of iText. This version is more than 6 years out of date and a
> whole lot
> > of changes have been applied to iText since then.

Sorry. My mistake. I mean JSignPdf http://jsignpdf.sourceforge.net/

> lisicky wrote
> > But I got pdf, which is not possible correctly sign. Adobe
> > Reader write,
> > > > that original certificate is incorrect.
> >
> > Where is the mistake?
>
> If you really want someone to look into that issue, you had better
> also
> > supply a sample PDF signed by you exhibiting that problem. Or does
> already
> > the attempt to sign fail?
>
> Regards,   Michael

OK, I attach pdf signed by me.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[iText Software]

On 24/07/2012 12:37, [hidden email] wrote:
> Sorry. My mistake. I mean JSignPdf http://jsignpdf.sourceforge.net/

You're using a product that is NOT affiliated with iText.
If you have problems with that product, ask the owner of that product.

Also, when looking at the project site, the licensing is all wrong.
Looking at the code base, it's as if the Producer line is adapted,
making it unclear which version is used.
Looking at the PDF you've sent us, it's as if iText 5.0.6 is used.
iText 5.0.6 was released under the AGPL; JSignPdf is released under the
MPL / LGPL.
This is NOT legal! You can NOT use an AGPL library inside an MPL/LGPL
product!
See http://www.dwheeler.com/essays/floss-license-slide.html
We'll forward this to our sales department and have them contact mr. Cacek.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[TvT]

He is using an adapted version of iText 2.1.7 which is licensed under LGPL/MPL and so he is able to license his software under the same license. Since he is supplying the source code (thus his changes) he obeyed the LGPL license.

sourceforge.net/projects/jsignpdf/files/stable/JSignPdf 1.3.0/jsignpdf-itxt-1.3.0-sources.jar

Note, also the package starts with "com.lowagie" thus can't be any 5.X iText version...
Seems perfectly fine ...

Regards,
ToM

2012/7/24 1T3XT BVBA <[hidden email]>

ou're using a product that is NOT affiliated with iText.
If you have problems with that product, ask the owner of that product.

Also, when looking at the project site, the licensing is all wrong.
Looking at the code base, it's as if the Producer line is adapted,
making it unclear which version is used.
Looking at the PDF you've sent us, it's as if iText 5.0.6 is used.
iText 5.0.6 was released under the AGPL; JSignPdf is released under the
MPL / LGPL.
This is NOT legal! You can NOT use an AGPL library inside an MPL/LGPL
product!
See http://www.dwheeler.com/essays/floss-license-slide.html
We'll forward this to our sales department and have them contact mr. Cacek.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[iText Software]

Op 24/07/2012 13:58, TvT schreef:

Seems perfectly fine ...

What worries me is the 'modified using JSignPdf 1.3.0'.
Looking at the code, it looks like the lines referring to iText and its version number are changed:
http://jsignpdf.cvs.sourceforge.net/viewvc/jsignpdf/jsignpdf-itxt/src/core/com/lowagie/text/Document.java

04	/**
105	* Name
106	*
107	* @since 2.1.6
108	*/
109	private static final String PRODUCT = "@PRODUCT_NAME@";
110	/**
111	* Release Nr
112	*
113	* @since 2.1.6
114	*/
115	private static final String RELEASE = "@RELEASENUMBER@";

If PRODUCT gets the value JSignPdf and RELEASE gets the value 1.3.0,
you are changing the producer line. As documented, you are not
allowed to do that without formal permission of the owners of iText.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[mkl]

Bruno, lisicky,

1T3XT BVBA wrote

Also, when looking at the project site, the licensing is all wrong.
Looking at the code base, it's as if the Producer line is adapted, making it unclear which version is used.
Looking at the PDF you've sent us, it's as if iText 5.0.6 is used.

I think that is not the case:

The original file attached to the initial post of this thread included the "iText 5.0.6_SNAPSHOT" producer information while JSignPdf attached "modified using JSignPdf 1.3.0" to it during signing.

Looking at the SF project sources they contain an iText fork based on iText 2.1.7.

Thus, most likely there is no AGPL <-> MPL/LGPL conflict.

The JSignPdf developer did not respect, though, the condition "This constant may only be changed by Paulo Soares and/or Bruno Lowagie" (refering to com.lowagie.text.Document constants ITEXT, RELEASE, and ITEXT_VERSION) which is still present in their initial check-in

http://jsignpdf.cvs.sourceforge.net/viewvc/jsignpdf/jsignpdf-itxt/src/core/com/lowagie/text/Document.java?revision=1.1&view=markup

but not anymore in the next check-in

http://jsignpdf.cvs.sourceforge.net/viewvc/jsignpdf/jsignpdf-itxt/src/core/com/lowagie/text/Document.java?revision=1.2&view=markup

in which he incidentally also changed the ITEXT and RELEASE constants.

Regards,   Michael

[TvT]

Regarding those two lines I am not quite sure whether it is possible to confine the lgpl/mpl license.
Kind of "if you licensed something under lgpl/mpl and it applies to every line of code no exceptions". No exceptions except you give that class a different license - which isn't the case - thus those two comments are invalid.

But this is just a theory since I am no FOS expert/lawyer and could be wrong....

On the other side he could easily change some other parts of the code (and thus change the producer) while leaving those lines perfectly intact. And since it states not to change those constants and not the producer in the resulting pdf it would comply...
/** This constant may only be changed by Paulo Soares and/or Bruno Lowagie. */

Regards,
ToM

2012/7/24 iText Info <[hidden email]>

Op 24/07/2012 13:58, TvT schreef:

Seems perfectly fine ...

What worries me is the 'modified using JSignPdf 1.3.0'.
Looking at the code, it looks like the lines referring to iText and its version number are changed:
http://jsignpdf.cvs.sourceforge.net/viewvc/jsignpdf/jsignpdf-itxt/src/core/com/lowagie/text/Document.java

04	/**
105	* Name
106	*
107	* @since 2.1.6
108	*/
109	private static final String PRODUCT = "@PRODUCT_NAME@";
110	/**
111	* Release Nr
112	*
113	* @since 2.1.6
114	*/
115	private static final String RELEASE = "@RELEASENUMBER@";

If PRODUCT gets the value JSignPdf and RELEASE gets the value 1.3.0,
you are changing the producer line. As documented, you are not
allowed to do that without formal permission of the owners of iText.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[iText Software]

Op 24/07/2012 14:48, TvT schreef:
> But this is just a theory since I am no FOS expert/lawyer and could be
> wrong...

If source code contains different rules regarding the IP, then you
should always assume the strictest rule applies. For example: a major
company used to release examples with a liberal "example license", but
the source code contained old references saying "This code is
confidential". As a result, one could not use that code under the
liberal license until the company removed those lines they had forgotten
to remove when they 'open sourced' the code.

Working around a rule that has a specific goal (keeping the producer
line intact) is generally not accepted in a court of law. Of course,
that always depends on the specific court and the specific jurisdiction.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[mkl]

lisicky,

lisicky wrote

Sorry. My mistake. I mean JSignPdf http://jsignpdf.sourceforge.net/

As has been discussed in-depth in this mail thread now, JSignPdf uses an iText fork based on version 2.1.7. That version is only half as ancient as the version 1.4 used by jPdfSign. It still is three years old, though, and many bug fixes and enhancements have been applied to iText since then.

In case of your sample file, though, updating iText does not suffice, even signing with the trunk version of iText gives the same result.

There is something in original2certified.pdf which in the course of iText signing is changed in the eyes of Adobe Acrobat and Reader but is not allowed to change. Unfortunately is very unspecific about what actually changed, the change list announces but one "sonstige Änderung" ('other change').

It may have something to do with the fact that that file does not only contain a DocMDP but also a FieldMDP transformation and some FieldLock information...

Regards,   Michael.

[lisicky]

> lisicky wrote
> > Sorry. My mistake. I mean JSignPdf
> > http://jsignpdf.sourceforge.net/
> > > >
> As has been discussed in-depth in this mail thread now, JSignPdf
> uses an
> > iText fork based on version 2.1.7. That version is only half as
> ancient as
> > the version 1.4 used by jPdfSign. It still is three years old,
> though, and
> > many bug fixes and enhancements have been applied to iText since
> then.
> >
> In case of your sample file, though, updating iText does not
> suffice, even
> > signing with the trunk version of iText gives the same result.
>
> There is something in original2certified.pdf which in the course
> of iText
> > signing is changed in the eyes of Adobe Acrobat and Reader but is
> not
> > allowed to change. Unfortunately is very unspecific about what
> actually
> > changed, the change list announces but one "sonstige Änderung"
> ('other
> > change').
>
> It may have something to do with the fact that that file does not
> only
> > contain a DocMDP but also a FieldMDP transformation and some
> FieldLock
> > information...
>
> Regards,   Michael.

Thanks Michael for your work.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
iText-questions mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/itext-questions

iText(R) is a registered trademark of 1T3XT BVBA.
Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/
Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php

[mkl]

lisicky,

mkl wrote

It may have something to do with the fact that that file does not only contain a DocMDP but also a FieldMDP transformation and some FieldLock information...

Just a postscript:

When opening your original2certified.pdf in Adobe Acrobat (version 9.5.1 here), all options to add another signature are disabled and shown grayed out. I would take that as a hint that the signature transformation information in that document in the eyes of Acrobat means that adding new signatures is per se not allowed by the certification.

Additionally the /Data entries of both the DocMDP and the FieldMDP, i.e. the respective "reference to the object in the document upon which the object modification analysis should be performed", point to the document catalog; maybe this implies that no structural change to the set of fields in the document is allowed?

Unfortunately the section "Validating Signatures That Use the DocMDP Transform Method" in the spec is very unspecific and gives ample scope to validators in their implementation. The FieldMDP section is even less specific and merely requires validation "in a similar manner to DocMDP signatures".

Regards,   Michael.