Bug 56836 - XML signature support
Summary: XML signature support
Status: RESOLVED LATER
Alias: None
Product: POI
Classification: Unclassified
Component: POIFS (show other bugs)
Version: 3.11-dev
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-10 11:33 UTC by Andreas Beeker
Modified: 2014-10-16 23:56 UTC (History)
0 users



Attachments
XML signature support version 1 (360.40 KB, application/octet-stream)
2014-08-10 11:33 UTC, Andreas Beeker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Beeker 2014-08-10 11:33:13 UTC
Created attachment 31892 [details]
XML signature support version 1

This patch adds xml signature support. [1]

My aim was to workaround, the limitation of the first implementation try [2],
so basically, to compile it, there's no further library neccessary (-> see HorribleProxy),
at runtime the bouncy castle jar needs to be in the context class loader.
The bc provider is not included in the patch and the (e.g.) bcprov-ext-jdk15on-1.49.jar needs
to be placed in test-data/xmldsign.

The work on this patch hasn't been finished yet, as the following issues still exist:
- the license issues with the eid applet project for non-aslv2-licensed files need be clarified
- not all tests (e.g. timestamp service and XAdESXL facets haven't been tested at all ...)
  have been migrated
- I'd like to have feedback if the HorribleProxy-approach is ok
- it uses code of #56814, which hasn't been committed yet
- documentation left for later ...

Implementation notes:
- Originally I thought I can use the SignatureDocument xmlbean as a baking store, which works with JDK 6.
  ... but in the end didn't with JDK 7, as it calls the unsupported DOM3 setIdAttribue method
- The HorribleProxy references classes in the bouncy castle and sun/oracle jdk namespace.
  I haven't tested it with other JDKs than oracle JDK 6/7. the clean way would be the usage of
  Apache Santuario or similar
- I haven't yet understood the canonization process fully. Basically you need to make sure that the
  input for the digesting is binary equal to what you write to the sig1.xml with the xmlbean.
  To the check the input/output, my solution was to provide my own implementation of
  UnsyncBufferedOutputStream and preload it via -Xbootclasspath/p jvm option
- The logging of the jdk classes is of course JUL-based, so you might want to include the usual suspects
  i.e. logback-classic/slf4j/jul-to-slf4j/jcl-over-slf4j jars for debugging and use the jvm options
  -Dorg.apache.poi.util.POILogger=org.apache.poi.util.CommonsLogger
  -Djava.util.logging.config.file=<path>/logging.properties

[1] http://apache-poi.1045710.n5.nabble.com/Digital-signature-on-MS-Office-documents-td5715238.html
[2] http://apache-poi.1045710.n5.nabble.com/Recent-additions-to-POI-quot-Added-implementation-of-Digital-Signature-support-quot-td2339353.html
Comment 1 Nick Burch 2014-08-10 11:36:48 UTC
For a patch like this, it might be worth you creating a branch in svn, and working on that. We can merge that into trunk when it's ready, but may make it easier to track and review
Comment 2 Andreas Beeker 2014-08-10 18:29:30 UTC
I've created a branch for this - r1617141
Comment 3 Andreas Beeker 2014-09-30 01:29:08 UTC
Branch merged with r1628348

The license thread can be found under https://groups.google.com/d/msg/eid-applet/Mnnl2KpdTXE/9fJrHUOl1SMJ
Comment 4 Andreas Beeker 2014-10-16 23:56:05 UTC
For the time being, I'm resolving this issues now with a bit more documentation - r1632447

Feel free to reopen it, when integration issues arise ... ibm jdk, timestamp or ocsp integration for instance ...