Zitat von Maruan Sahyoun <[email protected]>:
Hi,
Hi Maruan,
From 4 to 29 May 2015 ETSI is making a PAdES PlugTest [4], I'm already
a participant and will try to test the cryptobox. So I first try to go
through the specification and later port stuff like visual signatures.
Maybe we can participant as Apache at such plugtests, so we can gain
more publicity.
good idea - what would we need to participate as Apache PDFBox?
The first registration should be done by the apache office. There is
also a NDA that need to be signed. This means that all data from the
plugtest are not public and the test would run in a kind of blackbox.
Then the office need to register the participating members, so each
member will get access to the plugtest and can use there infra. That's
all.
This plugtest is free of charge, but this wasn't always the case.
The registration deadline is the end of april.
I don't made much planing, but I think this roadmap could be a good
start:
- Implement pdf signatures and verification for the ISO 32000-1:2008
specification.
- Implement the ETSI signature specification PAdES
(deadline is the PlugTest)
- Basic signature service, maybe webservice or gui application.
- Port the visual signature stuff that already exist and maybe start a
table based visualisation (without the need to create pictures)
- Port it to pdfbox 2.0.x with NonSeqParser
- Cleanup the existing pdfbox signature code
other parts that need to be done are:
- refactor signature interface and coswriter
- make pdf signature streamable without the dirty hooks that are needed now.
- there where already plans to move the pdf encryption from pdfbox
to a new module. Maybe we can move it into the cryptobox.
I don't want promise anything, so I try mainly get through the plugtest
and show how the feedback is.
If you have some ideas how the cryptobox can be improved or maybe how
the architecture may look like to provide best usability, then
please give me some suggestions.
I quickly scanned through the code - there are some features from
Java 1.7 such as Objects.requireNonNull in CoreHelper.copy. As
PDFBox is currently on 1.6 this might be an issue when bringing it
over.
Here are some of my initial thoughts
API wise maybe there could be a class SignatureService with sign(),
certify() and verify() methods loading a PDDocument.
so the signing process would look something like
PDDocument doc = PDDocument.load
SignatureService sigservice = SignatureService.newInstance(doc);
sigservice.sign(SignatureOptions, OutputStream);
Yes such a service with PDDocument as base would be great, but we need
to refactor first the signature part in the pdfbox. At the moment we
are bound to files. So the 1.8.x and the first 2.0.x release will be
file and stream-based. But I have this in mind.
So at the moment we need to live with the fact that the
SignatureService creates the PDDocument itself.
As for the packaging maybe it could live in
org.apache.pdfbox.services.crypto as this would allow for additional
services to be added at a later stage wo. having so many top level
packages (services being a sample we'd need to decide on).
What services are planed? I thought putting all stuff in crypto and do
there the additional packages like sign, encrypt, verify would be ok.
But if we plan more services that aren't covert by crypto, I would
understand this step.
As for the general naming maybe this could be renamed to
pdfbox-crypto to utilize the PDFBox name fully and not only the box
part.
Are you sure? As it will be a submodule of the pdfbox, I thought it
should match the other module names such fontbox, jempbox, xmpbox and
so on. Naming the github project pdfbox-crypto will be indeed ok, but
I think later we does not need the additional pdfbox- in the name.
BR
Maruan
Best regards
Thomas
[1]
http://www.etsi.org/news-events/news/324-news-release-14th-september-2009
[2] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0130
[3] https://github.com/Rayman2200/cryptobox/tree/1.8
[4] http://xades-portal.etsi.org/pub/index.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
