How can we check whether our Digital Signature on PDF is according to 'PAdES' standard?
The OP uses third-party software (iText 5.4.2 in the case at hand) for creating PAdES signatures and now wants to check whether the resulting signatures indeed satisfy the PAdES specification. Here some ideas for that:
First of all you have to define what you mean by "PAdES signature":
Do you mean that term as defined in the upcoming PDF 2.0 specification:
The PDF signatures using the Subfilter value ETSI.CAdES.detached are referred to as PAdES signatures and they follow one of two CMS profiles created to be compatible with the corresponding CAdES profiles defined in ETSI EN 319 122.
(ISO 32000-2 FDIS section 12.8.3.4 - CAdES signatures as used in PDF)
Do you mean more specifically a signature following one of the PAdES baseline signature profiles as specified in ETSI EN 319 142-1?
Clause 6 defines four levels of PAdES baseline signatures, intended to facilitate interoperability and to encompass the life cycle of PAdES signature, namely:
a) B-B level provides requirements for the incorporation of signed and some unsigned attributes when the signature is generated.
b) B-T level provides requirements for the generation and inclusion, for an existing signature, of a trusted token proving that the signature itself actually existed at a certain date and time.
c) B-LT level provides requirements for the incorporation of all the material required for validating the signature in the signature document. This level aims to tackle the long term availability of the validation material.
d) B-LTA level provides requirements for the incorporation of electronic time-stamps that allow validation of the signature long time after its generation. This level aims to tackle the long term availability and integrity of the validation material.
(ETSI EN 319 142-1 V1.1.1 section 6 - PAdES baseline signatures)
Or would one of the additional PAdES signatures profiles from ETSI EN 319 142-2 also qualify?
The present document contains a profile for the use of PDF signatures, as described in ISO 32000-1 [1] and based on CMS digital signatures [i.6], that enables greater interoperability for PDF signatures by providing additional restrictions beyond those of ISO 32000-1 [1]. This first profile is not related to ETSI EN 319 142-1 [4].
The present document also contains a second set of profiles that extend the scope of the profile in PAdES part 1 [5], while keeping some features that enhance interoperability of PAdES signatures. These profiles define three levels of PAdES extended signatures addressing incremental requirements to maintain the validity of the signatures over the long term, in a way that a certain level always addresses all the requirements addressed at levels that are below it. These PAdES extended signatures offer a higher degree of optionality than the PAdES baseline signatures specified in ETSI EN 319 142-1 [4].
The present document also defines a third profile for usage of an arbitrary XML document signed with XAdES signatures that is embedded within a PDF file.
(ETSI EN 319 142-2 V1.1.1 section 1 - Scope)
In particular you have to know whether you are also considering the additional PAdES signatures profiles "for CMS digital signatures in PDF" or "for XAdES Signatures signing XML content in PDF" from ETSI EN 319 142-2 or not because these two profiles differ very much from the remaining ones.
I assume you don't consider these two profiles because the former more or less is the good old ISO 32000-1 CMS signature with a few restriction most signers follow anyways, and the latter are XML signatures which are a completely different animal altogether.
All the remaining profiles differ mostly in the amount and type of validation related information and time stamps added to the document to make the validation less and less dependent on data one has to retrieve online.
Manually: You take a PDF browser (like iText RUPS or the PDFBox PDF Debugger), a hex viewer, an ASN.1 Dump utility, the applicable base specification from the list above and the additional specifications referenced from the base specification and check all the criteria.
This requires quite some time for a single signature but in the end you can know everything there is to know about the tested signature. I only recommend this if you have some experience using those tools and working with specifications, or if you really have much time to learn.
Programmatically: You take a general purpose PDF library (if you take a different one than the one you create you signatures with, the credibility of the result might increase), a security functions library (e.g. BouncyCastle), the base specification and the additional ones, and start implementing a program testing the criteria in the specification.
This requires quite some time to develop but then can be re-used, e.g. for quality assurance and regression prevention. I only recommend this if you have some experience using those libraries and working with specifications, or if you really have much time to learn.
You use an existing software or service that evaluates the signature for you, e.g. the ETSI Signature Conformance Checker (http://signatures-conformance-checker.etsi.org/pub/index.shtml), a free online tool that performs numerous checkings in order to verify the conformity of the ETSI Advanced Electronic Signatures.
This obviously is the quickest option but you generally cannot be sure how reliable the tests were executed. Thus, it is good as a first opinion but depending on how much is at stake, I would want more security.
You can hire experts to analyse and assess the validity of your signature according to the desired profile.
This may be expensive but at least you have someone to resort to if later you get into trouble due to some non-compliance.