Hi, > Am 16.04.2015 um 12:59 schrieb Thomas Chojecki <i...@rayman2200.de>: > > > Zitat von Maruan Sahyoun <sahy...@fileaffairs.de>: > >> 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.
OK > >> >> 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. Don't know yet - but I'm also looking at doing form flattening - of course that could live inside interactive.forms - so that was only an initial thought. > >> 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. Again something worth discussing. If there are more subproject IMHO the current naming won't scale. > >> >> >> 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
