> On 16 Apr 2015, at 01:52, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: > > Hi, > >> Am 16.04.2015 um 01:03 schrieb Thomas Chojecki <i...@rayman2200.de>: >> >> Hello, >> I've startet creating a crypto engine for pdfbox. The aim is to provide >> a highlevel api for signing and verifying pdf documents. > > great - this is a very important use case for PDFBox. > >> >> The engine is called cryptobox and is splited into a 1.8.x and >> main branch. After the basic functions are ready in the 1.8.x, I will >> do a pdfbox 2.0.x port and clean up the signature interface. >> >> The goal is to do a pdfbox reference implementation for PAdES [1] up to >> part 4 of the specification or I will go straight to the Europen Union >> Commision Decision [2]. I hope with the help of the community, we have a >> chance to reach the goal. >> >> At the moment the code is hosted on github [3] but I will move it to the >> apache repository after the codebase reached a usable level. It is >> easier for me to prepare the code and play with it on github (less >> restrictions). >> >> 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? > >> >> >> >> 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.
Well spotted. > 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); I see where you're coming from but we already have SignatureInterface and PDSignature which allow pluggable signing and provide a cleaner API than this. They can be enhanced to serve any further needs. It's fine for PDDocument to delegate the signing process (as it already does via SignatureInterface) but it would be a mistake to delegate the saving process too, as happens in your example above. In other words, any API like PDDocument::sign(SignatureInterface) will work nicely, but one like SignatureService:save(PDDocument) won't, because it has the delegation of responsibilities backwards. > 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). My experience has been that "services" are background processes or remote processes. What you're describing is simply an interface, which is often called a "provider" in Java. Either way, there's no need to include it in the package name, org.apache.pdfbox.crypto does the job nicely. > 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. I agree, especially as the code is specific to PDF and not general crypto. > 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: dev-unsubscr...@pdfbox.apache.org >> For additional commands, e-mail: dev-h...@pdfbox.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
