> Am 23.04.2015 um 10:51 schrieb John Hewson <[email protected]>: > > >> On 16 Apr 2015, at 01:52, Maruan Sahyoun <[email protected]> wrote: >> >> Hi, >> >>> Am 16.04.2015 um 01:03 schrieb Thomas Chojecki <[email protected]>: >>> >>> 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.
OK - thought to have it for convenience as signing means that you also have to save. > >> 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. there is no need for it - and services was only an example - but as we might add new capabilities 'above' PD a consistent package might provide some additional structure to keep these together. Again technically that's not needed. > >> 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: [email protected] >>> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
